<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">In general, I agree with your point. Perhaps “Customer must originate prefix(es) and announce them via a border routing protocol (e.g. BGP-4) to each of their upstreams."</div><div class=""><br class=""></div>In specific, I think it’s extremely unlikely that there will be any significant advances or changes in IPv4 routing protocols as the IETF has pretty thoroughly expressed a<div class="">desire to stop working on IPv4 except in furtherance of transition to IPv6.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 16, 2020, at 11:06 , John Santos <<a href="mailto:john@egh.com" class="">john@egh.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
  
  <div class="">
    <div class="moz-cite-prefix">On 7/16/2020 11:39 AM, Kat Hunter
      wrote:</div>
    <div class="moz-cite-prefix">[...]<br class="">
    </div>
    <blockquote type="cite" cite="mid:CAC=UcieNzk9knpV0pmR-2PC8+p+t+rfsgHhx0XYNBjUuRDxpoA@mail.gmail.com" class="">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
      <div dir="ltr" class="">4.2.3.6 Original Text:<br class="">
        <div class="">Under normal circumstances an ISP is required to determine
          the prefix size of their reassignment to a downstream customer
          according to the guidelines set forth in RFC 2050.
          Specifically, a downstream customer justifies their
          reassignment by demonstrating they have an immediate
          requirement for 25% of the IP addresses being assigned, and
          that they have a plan to utilize 50% of their assignment
          within one year of its receipt. This policy allows a
          downstream customer’s multihoming requirement to serve as
          justification for a /24 reassignment from their upstream ISP,
          regardless of host requirements. Downstream customers must
          provide contact information for all of their upstream
          providers to the ISP from whom they are requesting a /24. The
          ISP will then verify the customer’s multihoming requirement
          and may assign the customer a /24, based on this policy.
          Customers may receive a /24 from only one of their upstream
          providers under this policy without providing additional
          justification. ISPs may demonstrate they have made an
          assignment to a downstream customer under this policy by
          supplying ARIN with the information they collected from the
          customer, as described above, or by identifying the AS number
          of the customer. This information may be requested by ARIN
          staff when reviewing an ISP’s utilization during their request
          for additional IP addresses space.<br class="">
          <br class="">
        </div>
      </div>
    </blockquote><p class="">New version of proposed 4.2.3.6 replacement:</p>
    <blockquote type="cite" cite="mid:CAC=UcieNzk9knpV0pmR-2PC8+p+t+rfsgHhx0XYNBjUuRDxpoA@mail.gmail.com" class="">
      <div dir="ltr" class="">
        <div class="">4.3.2.6 New Text, replacing old:<br class="">
          If a downstream customer has a requirement to multihome, that
          requirement alone will serve as justification for a /24
          allocation. Downstream customers must provide contact
          information for all of their upstream providers to the ISP
          from whom they are requesting a /24, and utilize BGP as the
          routing protocol between the customer and the ISP. Customers
          may receive a /24 from only one of their upstream providers
          under this policy without providing additional justification.
          ISPs may demonstrate they have made an assignment to a
          downstream customer under this policy by supplying ARIN with
          the information they collected from the customer, as described
          above, or by identifying the AS number of the customer.<br class="">
          <div class=""><br class="">
          </div>
          <div class="">-Kat Hunter</div>
        </div>
      </div>
      [...]<br class="">
    </blockquote>
    Older version of proposed 4.2.3.6:<br class="">
    <blockquote type="cite" cite="mid:CAC=UcieNzk9knpV0pmR-2PC8+p+t+rfsgHhx0XYNBjUuRDxpoA@mail.gmail.com" class="">
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <br class="">
          4.2.3.6. Reassignments to Multihomed Downstream Customers<br class="">
          <br class="">
          If a downstream customer has a requirement to multihome, that
          <br class="">
          requirement alone will serve as justification for a /24
          allocation. <br class="">
          Downstream customers must provide contact information for all
          of their <br class="">
          upstream providers to the ISP from whom they are requesting a
          /24, and <br class="">
          utilize BGP as the routing protocol between the customer and
          the ISP. <br class="">
          Customers may receive a /24 from only one of their upstream
          providers <br class="">
          under this policy without providing additional justification.
          ISPs may <br class="">
          demonstrate they have made an assignment to a downstream
          customer under <br class="">
          this policy by supplying ARIN with the information they
          collected from <br class="">
          the customer, as described above, or by identifying the AS
          number of the <br class="">
          customer.<br class="">
          <br class="">
          Timetable for implementation: Immediate<br class="">
        </blockquote>
      </div>
    </blockquote><p class="">I haven't digested this proposal sufficiently to have an opinion
      one way or the other, but I do have a general and a specific
      question.  Doesn't ARIN attempt to avoid mandating particular
      network technologies in policy, so as not to impede technological
      advances?</p><p class="">I am particularly referring to BGP in both versions of the
      proposed new policy.  Would it be better to develop wording that
      would suggest BGP until something better comes along, by not
      specifically refer to it in the policy text?  Or is BGP considered
      to be as good as it's ever going to get, at least for IPv4
      routing?<br class="">
    </p><p class=""><br class="">
    </p>
    <pre class="moz-signature" cols="80">-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
</pre>
  </div>

_______________________________________________<br class="">ARIN-PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.<br class=""></div></blockquote></div><br class=""></div></body></html>