<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Section 8 as discussed on PPML and as written gives anyone the ability to transfer a /24 without justification and requires officer-attested justification for anything larger. <div><br></div><div>If there are organizations transferring blocks larger than a /24 for whom <span style="background-color: rgba(255, 255, 255, 0);">officer-attested justification is burdensome (to them or to ARIN) I’d like to understand what is burdensome, so we can figure out how to reduce that burden. If not, then implementing section 8 as written seems appropriate until we identify a reason to change it. </span><br><br><div id="AppleMailSignature"><div>Scott</div></div><div><br>On Dec 5, 2017, at 8:40 AM, Andrew Dul <<a href="mailto:andrew.dul@quark.net">andrew.dul@quark.net</a>> wrote:<br><br></div><blockquote type="cite"><div>
  
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  
  
    <div class="moz-cite-prefix">I would agree there is nothing special
      about /21, that is just where we ended up at exhaustion.  <br>
      <br>
      It is possible this draft policy doesn't do what the community
      wants us to do.  I wrote this draft as a followup to the policy
      experience report to continue the conversation about the issue and
      to correct the inconsistency.  (Normally, I think of
      inconsistencies as a "bad" thing in policy)  <br>
      <br>
      Perhaps what we really do want is a more strict interpretation of
      the new section 8 transfer policy?  If so we need a way to signal
      that to staff.  I'd think that could happen here on this list or
      at a meeting and thus no policy change is needed.  <br>
      <br>
      Andrew<br>
      <br>
      On 12/4/2017 2:47 PM, David Huberman wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:E25B4A36-FD4E-44DB-AF08-E24BEC062358@panix.com">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      Andrew,
      <div><br>
      </div>
      <div>It’s unclear to me that /21 is the correct boundary,
        especially (as Scott Leibrand asked for) absent statistics from
        the staff (if any such stats make sense).  With section 8 policy
        now wholly separated from section 4 policy, I sort of think that
        it’s the staff who should change their practices, and follow
        section 8 policy as written.  </div>
      <div><br>
      </div>
      <div>Further to your problem statement, ISPs should NOT be
        applying under section 4 anymore. We know, however, from staff
        reports at the recent ARIN meeting that they still are applying.
         That’s a definite problem, but it feels to me to be a different
        problem than what you are tackling in this draft policy
        proposal. </div>
      <div><br>
      </div>
      <div>Happy to hear and be swayed by data or other arguments.</div>
      <div><br>
      </div>
      <div>David <br>
        <br>
        <div id="AppleMailSignature">Sent from my iPhone</div>
        <div><br>
          On Dec 4, 2017, at 4:30 PM, Andrew Dul <<a href="mailto:andrew.dul@quark.net" moz-do-not-send="true">andrew.dul@quark.net</a>>
          wrote:<br>
          <br>
        </div>
        <blockquote type="cite">
          <div>
            <meta http-equiv="Content-Type" content="text/html;
              charset=utf-8">
            <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>
              <br>
              Andrew<br>
              <br>
              <p><strong>Problem Statement: </strong></p>
              <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 all ISPs an initial /21 for Section 8 transfers. <br>
              </p>
              <br>
              <br>
              On 11/21/2017 9:19 PM, Scott Leibrand wrote:<br>
            </div>
            <blockquote type="cite" cite="mid:053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com">
              <meta http-equiv="content-type" content="text/html;
                charset=utf-8">
              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>
              <br>
              <div id="AppleMailSignature">
                <div>Scott</div>
              </div>
              <div><br>
                On Nov 21, 2017, at 7:28 PM, Andrew Dul <<a href="mailto:andrew.dul@quark.net" moz-do-not-send="true">andrew.dul@quark.net</a>>
                wrote:<br>
                <br>
              </div>
              <blockquote type="cite">
                <div>
                  <meta http-equiv="content-type" content="text/html;
                    charset=utf-8">
                  <div>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 id="AppleMailSignature"><br>
                  </div>
                  <div id="AppleMailSignature">Assuming we harmonize the
                    problem statement, would you prefer the /24 as
                    initial no questions asked size or a /21?</div>
                  <div id="AppleMailSignature"><br>
                  </div>
                  <div id="AppleMailSignature">What do others prefer?</div>
                  <div id="AppleMailSignature"><br>
                    .Andrew</div>
                  <div><br>
                    On Nov 21, 2017, at 2:52 PM, Scott Leibrand <<a href="mailto:scottleibrand@gmail.com" moz-do-not-send="true">scottleibrand@gmail.com</a>>
                    wrote:<br>
                    <br>
                  </div>
                  <blockquote type="cite">
                    <div>
                      <div dir="ltr">I believe this problem statement is
                        incorrect, and therefore oppose the policy
                        proposal as-is.
                        <div><br>
                        </div>
                        <div>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><br>
                        </div>
                        <div>8.5.5 reads "8.5.5. Block size</div>
                        <div>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><br>
                        </div>
                        <div>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><br>
                        </div>
                        <div>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><br>
                        </div>
                        <div>-Scott</div>
                      </div>
                      <div class="gmail_extra"><br>
                        <div class="gmail_quote">On Tue, Nov 21, 2017 at
                          2:40 PM, ARIN <span dir="ltr"><<a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true">info@arin.net</a>></span>
                          wrote:<br>
                          <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>
                            <br>
                            Draft Policy ARIN-2017-9 is below and can be
                            found at:<br>
                            <a href="https://www.arin.net/policy/proposals/2017_9.html" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.arin.net/policy/pr<wbr>oposals/2017_9.html</a><br>
                            <br>
                            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>
                            <br>
                            * Enabling Fair and Impartial Number
                            Resource Administration<br>
                            * Technically Sound<br>
                            * Supported by the Community<br>
                            <br>
                            The PDP can be found at:<br>
                            <a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.arin.net/policy/pd<wbr>p.html</a><br>
                            <br>
                            Draft Policies and Proposals under
                            discussion can be found at:<br>
                            <a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.arin.net/policy/pr<wbr>oposals/index.html</a><br>
                            <br>
                            Regards,<br>
                            <br>
                            Sean Hopkins<br>
                            Policy Analyst<br>
                            American Registry for Internet Numbers
                            (ARIN)<br>
                            <br>
                            <br>
                            <br>
                            Draft Policy ARIN-2017-9: Clarification of
                            Initial Block Size for IPv4 ISP Transfers<br>
                            <br>
                            Problem Statement:<br>
                            <br>
                            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>
                            <br>
                            Policy statement:<br>
                            <br>
                            Add the following to 8.5.4<br>
                            <br>
                            ISP organizations without direct assignments
                            or allocations from ARIN qualify for an
                            initial allocation of up to a /21.<br>
                            <br>
                            Comments:<br>
                            <br>
                            a. Timetable for implementation: Immediate<br>
                            ______________________________<wbr>_________________<br>
                            PPML<br>
                            You are receiving this message because you
                            are subscribed to<br>
                            the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
                            Unsubscribe or manage your mailing list
                            subscription at:<br>
                            <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
                            Please contact <a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true">info@arin.net</a>
                            if you experience any issues.<br>
                          </blockquote>
                        </div>
                        <br>
                      </div>
                    </div>
                  </blockquote>
                  <blockquote type="cite">
                    <div><span>_______________________________________________</span><br>
                      <span>PPML</span><br>
                      <span>You are receiving this message because you
                        are subscribed to</span><br>
                      <span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">ARIN-PPML@arin.net</a>).</span><br>
                      <span>Unsubscribe or manage your mailing list
                        subscription at:</span><br>
                      <span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" moz-do-not-send="true">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br>
                      <span>Please contact <a href="mailto:info@arin.net" moz-do-not-send="true">info@arin.net</a> if
                        you experience any issues.</span></div>
                  </blockquote>
                </div>
              </blockquote>
            </blockquote>
            <p><br>
            </p>
          </div>
        </blockquote>
        <blockquote type="cite">
          <div><span>_______________________________________________</span><br>
            <span>PPML</span><br>
            <span>You are receiving this message because you are
              subscribed to</span><br>
            <span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">ARIN-PPML@arin.net</a>).</span><br>
            <span>Unsubscribe or manage your mailing list subscription
              at:</span><br>
            <span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" moz-do-not-send="true">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br>
            <span>Please contact <a href="mailto:info@arin.net" moz-do-not-send="true">info@arin.net</a> if you
              experience any issues.</span></div>
        </blockquote>
      </div>
    </blockquote>
    <p><br>
    </p>
  

</div></blockquote></div></body></html>