Hi David, 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.
-C > On Dec 7, 2017, at 9:37 PM, David Huberman <[email protected]> wrote: > > 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] > <mailto:[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] >>>> <mailto:[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] >>>>> <mailto:[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] >>>>>> <mailto:[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 >>>>>> <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 >>>>>> <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 >>>>>> <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] >>>>>> <mailto:[email protected]>). >>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>> <http://lists.arin.net/mailman/listinfo/arin-ppml> >>>>>> Please contact [email protected] <mailto:[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] >>>>>> <mailto:[email protected]>). >>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>> <http://lists.arin.net/mailman/listinfo/arin-ppml> >>>>>> Please contact [email protected] <mailto:[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] >> <mailto:[email protected]>). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> <http://lists.arin.net/mailman/listinfo/arin-ppml> >> Please contact [email protected] <mailto:[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.
