<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="">Hi David,</div><div class=""><br class=""></div><div class="">Section 4 requests are still relevant for the waiting list and critical infrastructure, but little else. That said, there have been efforts in the past to obliterate Section 4 wholesale and replace it with a much more concise text, but those never had much support. I’d be happy to try again in the name of simplification, but that would be an entirely separate proposal.</div><div class=""><br class=""></div><div class="">-C</div><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 7, 2017, at 9:37 PM, David Huberman <<a href="mailto:daveid@panix.com" class="">daveid@panix.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">Thank you for the clarification.  I think the staff practice is a reasonable approach and I don’t think change is needed in policy for this.<div class=""><br class=""></div><div class="">The updated Problem Statement reveals the real issue here - the one we need to figure out as a community.   What to do about all the requests each month for IPv4 addresses under section 4? </div><div class=""><br class=""></div><div class="">Is it time to pass a policy to direct staff to no longer accept section 4 requests (except the ones they still fill like critical infrastructure)? I wonder what the downside of such a policy would be - anyone know?<br class=""><br class=""><br class=""><div class=""></div><div class=""><br class="">On Dec 7, 2017, at 11:47 PM, Andrew Dul <<a href="mailto:andrew.dul@quark.net" class="">andrew.dul@quark.net</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
  
  
    <div class="moz-cite-prefix">It was noted to me by ARIN staff, that
      this updated problem statement doesn't accurately reflect ARIN's
      current practice.  Below I suggest another updated problem
      statement.<br class="">
      <br class=""><p class=""><strong class="">Problem Statement: </strong></p>
      It was noted at the ARIN 40 Policy Experience Report, that there
      is an inconsistency in the initial block size for ISPs. Section
      4.2.2 notes that the initial ISP block size should be /21 whereas
      the initial block size in 8.5.4 is noted as "minimum transfer
      size" which is effectively a /24. This causes ISP organizations to
      be approved for different initial block size depending on if they
      first apply apply for a transfer directly under section 8 or if
      they apply for a block under section 4.  This policy is intended
      to clarify this issue, by setting a consistent ISP initial IPv4
      block size. It was noted that ARIN staff current operational
      practice is to allow qualified ISPs an initial /21 for Section 8
      transfers when they first apply and are approved under section 4. 
      If an organization applies under section 8 first they are
      initially qualified for a /24, larger allocations require
      additional documentation as noted in 8.5.5.<br class="">
      <br class="">
      <br class="">
      <br class="">
      On 12/4/2017 1:30 PM, Andrew Dul wrote:<br class="">
    </div>
    <blockquote type="cite" cite="mid:7a704972-c75b-2423-9212-30a65c3605b1@quark.net" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
      <div class="moz-cite-prefix">Scott,  how would you feel about this
        proposed updated problem statement which focuses on the current
        issue rather than the past.<br class="">
        <br class="">
        Andrew<br class="">
        <br class=""><p class=""><strong class="">Problem Statement: </strong></p><p class="">It was noted at the ARIN 40 Policy Experience Report, that
          there is an inconsistency in the initial block size for ISPs.
          Section 4.2.2 notes that the initial ISP block size should be
          /21 whereas the initial block size in 8.5.4 is noted as
          "minimum transfer size" which is effectively a /24. This
          causes ISP organizations to be approved for different initial
          block size depending on if they first apply apply for a
          transfer directly under section 8 or if they apply for a block
          under section 4.  This policy is intended to clarify this
          issue, by setting a consistent ISP initial IPv4 block size. It
          was noted that ARIN staff current operational practice is to
          allow all ISPs an initial /21 for Section 8 transfers. <br class="">
        </p>
        <br class="">
        <br class="">
        On 11/21/2017 9:19 PM, Scott Leibrand wrote:<br class="">
      </div>
      <blockquote type="cite" cite="mid:053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com" class="">
        <meta http-equiv="content-type" content="text/html;
          charset=utf-8" class="">
        I’d be ok with a /21, but there’s nothing magical about that
        size in a post-exhaustion world. I’d rather base a loosening on
        actual transfer statistics, and consider doing so for both
        allocations and assignments. <br class="">
        <br class="">
        <div class="">
          <div class="">Scott</div>
        </div>
        <div class=""><br class="">
          On Nov 21, 2017, at 7:28 PM, Andrew Dul <<a href="mailto:andrew.dul@quark.net" moz-do-not-send="true" class="">andrew.dul@quark.net</a>>
          wrote:<br class="">
          <br class="">
        </div>
        <blockquote type="cite" class="">
          <div class="">
            <meta http-equiv="content-type" content="text/html;
              charset=utf-8" class="">
            <div class="">It sounds like our recollections of what we intended
              for ISP initial allocations have diverged. I will admit
              when I drafted the problem statement I did not go back
              through email to see if there was anything about this
              issue.</div>
            <div class=""><br class="">
            </div>
            <div class="">Assuming we harmonize the
              problem statement, would you prefer the /24 as initial no
              questions asked size or a /21?</div>
            <div class=""><br class="">
            </div>
            <div class="">What do others prefer?</div>
            <div class=""><br class="">
              .Andrew</div>
            <div class=""><br class="">
              On Nov 21, 2017, at 2:52 PM, Scott Leibrand <<a href="mailto:scottleibrand@gmail.com" moz-do-not-send="true" class="">scottleibrand@gmail.com</a>>
              wrote:<br class="">
              <br class="">
            </div>
            <blockquote type="cite" class="">
              <div class="">
                <div dir="ltr" class="">I believe this problem statement is
                  incorrect, and therefore oppose the policy proposal
                  as-is.
                  <div class=""><br class="">
                  </div>
                  <div class="">8.5.4 was intended (by me, as one of the authors,
                    and in PPML discussions I just pulled up) to allow
                    ISPs to transfer a /24 without justification.  It
                    was *not* intended to "match the previous policy" in
                    4.2.2.</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">8.5.5 reads "8.5.5. Block size</div>
                  <div class="">Organizations may qualify for the transfer of a
                    larger initial block, or an additional block, by
                    providing documentation to ARIN which details the
                    use of at least 50% of the requested IPv4 block size
                    within 24 months. An officer of the organization
                    shall attest to the documentation provided to ARIN."</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">The intention was that any ISP needing a /21
                    would need to "provide documentation to ARIN which
                    details the use of at least 50% of the requested
                    IPv4 block size within 24 months", with officer
                    attestation to same.</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">If that policy is deemed insufficient, and we
                    believe it's better to allow transfers of up to /21
                    without providing documentation to ARIN and officer
                    attestation of such, then this proposal would need
                    to be re-written with a new problem statement
                    justifying that.</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">-Scott</div>
                </div>
                <div class="gmail_extra"><br class="">
                  <div class="gmail_quote">On Tue, Nov 21, 2017 at 2:40
                    PM, ARIN <span dir="ltr" class=""><<a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true" class="">info@arin.net</a>></span>
                    wrote:<br class="">
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">On
                      16 November 2017, the ARIN Advisory Council (AC)
                      advanced "ARIN-prop-244: Clarification of Initial
                      Block Size for IPv4 ISP Transfers" to Draft Policy
                      status.<br class="">
                      <br class="">
                      Draft Policy ARIN-2017-9 is below and can be found
                      at:<br class="">
                      <a href="https://www.arin.net/policy/proposals/2017_9.html" rel="noreferrer" target="_blank" moz-do-not-send="true" class="">https://www.arin.net/policy/pr<wbr class="">oposals/2017_9.html</a><br class="">
                      <br class="">
                      You are encouraged to discuss all Draft Policies
                      on PPML. The AC will evaluate the discussion in
                      order to assess the conformance of this draft
                      policy with ARIN's Principles of Internet number
                      resource policy as stated in the Policy
                      Development Process (PDP). Specifically, these
                      principles are:<br class="">
                      <br class="">
                      * Enabling Fair and Impartial Number Resource
                      Administration<br class="">
                      * Technically Sound<br class="">
                      * Supported by the Community<br class="">
                      <br class="">
                      The PDP can be found at:<br class="">
                      <a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank" moz-do-not-send="true" class="">https://www.arin.net/policy/pd<wbr class="">p.html</a><br class="">
                      <br class="">
                      Draft Policies and Proposals under discussion can
                      be found at:<br class="">
                      <a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank" moz-do-not-send="true" class="">https://www.arin.net/policy/pr<wbr class="">oposals/index.html</a><br class="">
                      <br class="">
                      Regards,<br class="">
                      <br class="">
                      Sean Hopkins<br class="">
                      Policy Analyst<br class="">
                      American Registry for Internet Numbers (ARIN)<br class="">
                      <br class="">
                      <br class="">
                      <br class="">
                      Draft Policy ARIN-2017-9: Clarification of Initial
                      Block Size for IPv4 ISP Transfers<br class="">
                      <br class="">
                      Problem Statement:<br class="">
                      <br class="">
                      It was noted at the ARIN 40 Policy Experience
                      Report, that there is an inconsistency in the
                      initial block size for ISPs. Section 4.2.2 notes
                      that the initial ISP block size should be /21
                      whereas the initial block size in 8.5.4 is noted
                      as "minimum transfer size" which is effectively a
                      /24. The intent of the new 8.5.4 was to match the
                      previous policy. This policy is intended to
                      clarify this issue. It was noted that ARIN staff
                      current operational practice is to allow ISPs an
                      initial /21 for Section 8 transfers.<br class="">
                      <br class="">
                      Policy statement:<br class="">
                      <br class="">
                      Add the following to 8.5.4<br class="">
                      <br class="">
                      ISP organizations without direct assignments or
                      allocations from ARIN qualify for an initial
                      allocation of up to a /21.<br class="">
                      <br class="">
                      Comments:<br class="">
                      <br class="">
                      a. Timetable for implementation: Immediate<br class="">
                      ______________________________<wbr class="">_________________<br class="">
                      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" target="_blank" moz-do-not-send="true" class="">ARIN-PPML@arin.net</a>).<br class="">
                      Unsubscribe or manage your mailing list
                      subscription at:<br class="">
                      <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" moz-do-not-send="true" class="">http://lists.arin.net/mailman/<wbr class="">listinfo/arin-ppml</a><br class="">
                      Please contact <a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true" class="">info@arin.net</a>
                      if you experience any issues.<br class="">
                    </blockquote>
                  </div>
                  <br class="">
                </div>
              </div>
            </blockquote>
            <blockquote type="cite" class="">
              <div class=""><span class="">_______________________________________________</span><br class="">
                <span class="">PPML</span><br class="">
                <span class="">You are receiving this message because you are
                  subscribed to</span><br class="">
                <span class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true" class="">ARIN-PPML@arin.net</a>).</span><br class="">
                <span class="">Unsubscribe or manage your mailing list
                  subscription at:</span><br class="">
                <span class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" moz-do-not-send="true" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br class="">
                <span class="">Please contact <a href="mailto:info@arin.net" moz-do-not-send="true" class="">info@arin.net</a> if you
                  experience any issues.</span></div>
            </blockquote>
          </div>
        </blockquote>
      </blockquote><p class=""><br class="">
      </p>
    </blockquote><p class=""><br class="">
    </p>
  

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