I see no reason to move the boundary for an ISP initial allocation from /21 to /24.
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] > <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 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]). > 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.
