Thanks to both of you for you input so far. What do other folks think? Are we better off keeping a tweaked version of the current needs justification mechanics for ISPs? Or should we move toward allowing ISPs to get a block whose size is determined by their forward-looking projections as we do for end-user organizations today?
-Scott On Mon, Nov 25, 2013 at 1:22 PM, David Huberman < [email protected]> wrote: > Ok, quick question then: > > Does your opinion change if I tell you that 4.2.0, 4.2.1, 4.3.0, and 4.3.1 > are the exact rules end-users have been subject to for 16 years? ARIN has > reviewed thousands and thousands of requests every year under the policy > framework described in 4.2.0, 4.2.1, 4.3.0, and 4.3.1. > > And a quick observation: > > Scott's proposed change isn't big at all. It just lowers the bar from /22 > to /24 (a good thing) using a mechanic that hasn't worked for newer/smaller > ISPs (yourself included, Steven, as you told this list many times when you > first joined) in a long time. > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > > -----Original Message----- > From: Steven Ryerse [mailto:[email protected]] > Sent: Monday, November 25, 2013 1:18 PM > To: David Huberman; '[email protected]' > Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion > > I'm all for eliminating the definition of what constitutes an end user vs. > ISP vs. whatever, as it doesn't really matter unless there is a technical > issue involved that ARIN needs to manage. I also agree that it might be > easier making smaller steps to fixing these kinds of issues given the > dramatic difference of opinion surrounding how blocks should be allocated. > > I would point out though that in real life the requirements set out below > in Sections 4.2.0, 4.2.1, 4.3.0, and 4.3.1 can all be manipulated and I'm > sure that in past real life requests that ARIN has received and allocated, > some organizations have done so to get a successful allocation request > filled. I don't believe ARIN goes back and checks to see if an > organization met their predicated allocations in the timeframe policies > require. The requirements based on future usage require us to be able to > predict the future and of course none of us really can do that. > > I am for what Scott is trying to accomplish. I know it would be a big > change in policy but isn't it finally time to jettison the needs tests > altogether and just allocate based on rightsizing blocks allocated to the > size of the requesting organization and the size of their existing network > and existing allocations. Requiring organizations to predict the future > and fudge their numbers just to get a block allocated is not what we want > to incent organizations to do. Regardless of the original intentions this > is just a game organizations are forced to play and why would this > community want to force anyone to do that? > > Just my two cents. > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ℠ Eclipse Networks, Inc. > Conquering Complex Networks℠ > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of David Huberman > Sent: Monday, November 25, 2013 3:46 PM > To: '[email protected]' > Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion > > Scott wrote: > > > I'm not sure it's all that helpful to ask me to re-justify the entire > > NRPM. That requirement, in a more strict form, is what is present in the > NRPM today. > > But we can't make policy for policy's sake. ARIN exists to, in part, > provide number resources to the operator community who needs them. Section > 4 of the NRPPM serves the needs of the network operator community circa > 1996, not 2014 and beyond. So how about: > > 4.2.0: > > An ISP can obtain an initial allocation of a /24 or larger by > demonstrating a need to use at least 25% of the space within 90 days, and > at least 50% of the space within one year. > > 4.2.1 > > An ISP can obtain an additional allocations by demonstrating 80% or better > utilization of existing address space. The additional allocation block size > determination uses the criterion in 4.2.0 > > 4.3.0 > > An end-user can obtain an initial assignment of a /24 or larger by > demonstrating a need to use at least 25% of the space within 90 days, and > at least 50% of the space within one year. > > 4.3.1 > > An end-user can obtain an additional assignment by demonstrating 80% or > better utilization of existing address space. The additional assignment > block size determination uses the criterion in 4.3.0 > > Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done > with section 4, and you've fixed NRPM 8.3 and you've harmonized the very > broken ISP v End-user mechanic. > > Doesn't this serve the network operator community in 2014 better than > making small changes to walls and walls of text from 1996? > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > _______________________________________________ > 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.
