Owen, Yep, that was an editing error, it should have been;
4.2.2. Initial allocation to ISPs All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong <[email protected]> wrote: > I see no reason to move the boundary for an ISP initial allocation from > /21 to /24. > Well that seems to be staff intrupretation if you are getting an initial allocation via a transfer, how would you reslove this then? Thanks. > I certainly see no reason for “up to a /24” as there’s nothing smaller > available and even if it were, it wouldn’t be useful in any foreseeable > environment. > > Owen > > On Jan 18, 2018, at 2:21 PM, David Farmer <[email protected]> wrote: > > David, > > The resolution you suggest below seems like a different policy proposal to > me, one with a significantly broader scope than this draft policy has. But > I think it is a valid question for the community to consider, it's just not > really the problem statement in question for this Draft Policy. > > So, back within the scope of this Draft Policy as the shepherd, I plan to > push forward Andrew's updated Problem Statement with a Policy Statement > that harmonizes and simplifies the text in section 4.2.2 as an official > update to this Draft Policy to get the conversation moving again. > > The current text of 4.2.2 is; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /21, subject to ARIN's minimum > allocation size. Organizations may qualify for a larger initial allocation > by documenting how the requested allocation will be utilized within 24 > months. ISPs renumbering out of their previous address space will be given > a reasonable amount of time to do so, and any blocks they are returning > will not count against their utilization. > > The text "subject to ARIN's minimum allocation size" seems extraneous. > And, post runout renumbering and returning any address space > seems unlikely, so let's just eliminate that whole sentence. > > I propose we simplify that to the following; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /24. Organizations may qualify > for a larger initial allocation by documenting how the requested allocation > will be utilized within 24 months. > > Below is the policy update that results; > > Thanks > > -------- > > Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP > Transfers > > Problem Statement: > > It was noted in 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 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. > > Policy Statement: > > Change section 4.2.2 as follows; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /24. Organizations may qualify > for a larger initial allocation by documenting how the requested allocation > will be utilized within 24 months. > > Comments: > > Timetable for implementation: Immediate > > > On Thu, Dec 7, 2017 at 11: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]> 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. >> >> > > > -- > =============================================== > David Farmer Email:[email protected] > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > _______________________________________________ > 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. > > > -- =============================================== David Farmer Email:[email protected] Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
_______________________________________________ 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.
