The existing language “up to a /21” is consistent with staff allowing you to obtain a /24 via transfer.
Are you telling me that staff is refusing /21 transfers, but allowing /24 transfers to new ISPs without further justification? If so, I would argue that current staff practice is in error vs. policy language. Owen > On Jan 18, 2018, at 2:37 PM, David Farmer <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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] >> <mailto:[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. >>> >> >> >> >> -- >> =============================================== >> David Farmer Email:[email protected] >> <mailto: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 <tel:(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <tel:(612)%20812-9952> >> =============================================== >> _______________________________________________ >> 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. > > > > > -- > =============================================== > David Farmer Email:[email protected] > <mailto: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.
