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.
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? 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? > On Dec 7, 2017, at 11:47 PM, Andrew Dul <[email protected]> wrote: > > 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. > > 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 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. > > > >> On 12/4/2017 1:30 PM, Andrew Dul 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.
