My opinion absolutely does not change just because organizations have been made
to jump thru unnecessary hoops for 16 years. I strongly think that needs to be
corrected. Obviously I'm not alone in that opinion given that other's in other
regions have made similar proposals.
As I said I agree with and support what Scott is trying to accomplish as it is
a slight improvement to the status quo.
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: David Huberman [mailto:[email protected]]
Sent: Monday, November 25, 2013 4:23 PM
To: Steven Ryerse; '[email protected]'
Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
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.
