Andrew, 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.
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. Happy to hear and be swayed by data or other arguments. David Sent from my iPhone > On Dec 4, 2017, at 4:30 PM, Andrew Dul <[email protected]> wrote: > > Scott, how would you feel about this proposed updated problem statement > which focuses on the current issue rather than the past. > > Andrew > > Problem Statement: > > 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. > > >> On 11/21/2017 9:19 PM, Scott Leibrand wrote: >> 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. >> >> Scott >> >> On Nov 21, 2017, at 7:28 PM, Andrew Dul <[email protected]> wrote: >> >>> 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. >>> >>> Assuming we harmonize the problem statement, would you prefer the /24 as >>> initial no questions asked size or a /21? >>> >>> What do others prefer? >>> >>> .Andrew >>> >>> On Nov 21, 2017, at 2:52 PM, Scott Leibrand <[email protected]> wrote: >>> >>>> I believe this problem statement is incorrect, and therefore oppose the >>>> policy proposal as-is. >>>> >>>> 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. >>>> >>>> 8.5.5 reads "8.5.5. Block size >>>> 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." >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> -Scott >>>> >>>>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN <[email protected]> wrote: >>>>> 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. >>>>> >>>>> Draft Policy ARIN-2017-9 is below and can be found at: >>>>> https://www.arin.net/policy/proposals/2017_9.html >>>>> >>>>> 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: >>>>> >>>>> * Enabling Fair and Impartial Number Resource Administration >>>>> * Technically Sound >>>>> * Supported by the Community >>>>> >>>>> The PDP can be found at: >>>>> https://www.arin.net/policy/pdp.html >>>>> >>>>> Draft Policies and Proposals under discussion can be found at: >>>>> https://www.arin.net/policy/proposals/index.html >>>>> >>>>> Regards, >>>>> >>>>> Sean Hopkins >>>>> Policy Analyst >>>>> American Registry for Internet Numbers (ARIN) >>>>> >>>>> >>>>> >>>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >>>>> ISP Transfers >>>>> >>>>> Problem Statement: >>>>> >>>>> 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. >>>>> >>>>> Policy statement: >>>>> >>>>> Add the following to 8.5.4 >>>>> >>>>> ISP organizations without direct assignments or allocations from ARIN >>>>> qualify for an initial allocation of up to a /21. >>>>> >>>>> Comments: >>>>> >>>>> a. Timetable for implementation: Immediate >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List ([email protected]). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact [email protected] if you experience any issues. >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List ([email protected]). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact [email protected] if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
