[arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

[Scott Leibrand]

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 <
David.Huberman at microsoft.com> 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:SRyerse at eclipse-networks.com]
> Sent: Monday, November 25, 2013 1:18 PM
> To: David Huberman; 'arin-ppml at arin.net'
> 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: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Huberman
> Sent: Monday, November 25, 2013 3:46 PM
> To: 'arin-ppml at arin.net'
> 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 (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/c275e69a/attachment.htm>