[arin-ppml] Policy Proposal 112: Utilization of 10.4.2 resources only via explicit policy

Joe Maimon jmaimon at chl.com
Fri Apr 30 18:07:41 EDT 2010

George, Wes E IV [NTK] wrote:
> -----Original Message-----
> From: Joe Maimon [mailto:jmaimon at chl.com]
> Sent: Friday, April 30, 2010 4:04 PM
> This /8 is not given to ARIN based upon need. It is given based upon its
> status as the last one available from the free pool.
> [[WEG]] yes, but it would have been allocated based on need otherwise. This just ensures that one RIR doesn't get left out on the final /8 because their run rate cycle is a little different than the others. It's not like ARIN wasn't going to need another /8 around the time that the last ones are being allocated, it's just a question of when.

I dont agree. It is a behavioral departure no matter which semantics are 
brought to bear.

> [[WEG]] consideration of alternatives yes, but this last /8 shouldn't be a rainy day fund. If there are alternatives that people in the community believe are not adequately covered by existing policy that we should be reserving blocks for, make specific proposals.

I have done so in PP110. However, it is possible that the community may 
not form consensus about what they want to use it while they may form 
consensus that they want to use it for something specific. I would not 
find those two outcomes contradictory.

> Otherwise, using what is available in a manner consistent with ARIN policy is not squandering addresses. IETF/IANA already reserved 16 /8s for "future use" (RFC 1112) and then waited so long to unreserve them that it's now impossible to take advantage of that space because nearly every piece of networking kit on the planet considers it unusable, and the required code changes would take longer than we have left. I just don't see much point in trying to reserve big blocks for "someday" without some concrete sense of when "someday" might be, and why we should care.
The story of Class E is an egregious case of resource squandering and it 
is actually infuriating that real effort to rectify that keeps getting 
delayed by the self-fulfilling recursive argument of delay until there 
is no benefit worth the effort.

Had it been done the first time it was realistically suggested it could 
have has real effect. In fact, it might still. We dont know that it wont.

However it is unlikely that history would repeat itself with this last 
/8, in its worst case it might make it onto bogon lists -- with which we 
have lots of experience with.

> If there wont be enough time to work out policy for this last /8 while
> holding it in reserve, then there definitely will not be time to work
> out policy before it is consumed -- too late.
> [[WEG]] Exactly my point. As with your last policy, it is my opinion that it is too late to make any substantive difference in either the runout timeframe or its effects on the Internet and businesses.
It is either too late, in which case it doesnt matter if it is used or 
not. Or it is not too late, in which case it may very well matter how it 
is used. So it behooves us to be conservative in this much, at the least.

>   QOS doesn't manufacture bandwidth any more than carving up and reserving addresses manufactures address space.

QoS is worse than the alternative of more bandwidth. It is better than 
the alternative of critical services/needs being unusable/unavailable 
with your existing bandwidth.

In this fashion it _WORKS_.

Yes, you hate it. I hate it too.

>   All of these triggered rules simply complicate things for those of us with a plan underway for transitioning to IPv6 but a need for IPv4 until those plans are completely implemented, while offering those who don't have a plan (or worse, refuse to believe that there's a problem) a false sense of hope.
It is a real hope and it would have a real effect if it was really 
needed. If it is not really needed, than it wasnt a big deal in the 
first place.
> On the other hand, the policy process does have the ability to move quickly, such as the
> emergency pdp process.
> [[WEG]] A process which if used in this context will have lots and lots of people calling foul and unfair and non-transparent, etc. Note that I am not making commentary about the absence/presence of the Emergency PDP process nor what are justified uses of it. I am simply saying that at this point, policy changes around this area need to be carefully considered, consensus-based, open, transparent, and deterministic. Otherwise, it simply invites further scrutiny because it creates the impression that ARIN is somehow changing the rules arbitrarily to the benefit of some and the detriment of others.
Since the community has preserved the Emergency PDP, it logically 
follows that it would be responsible to preserve something to allow 
emergency policy to work with, in an emergency.
> 4.10 is possibly not enough. We do not know yet.
> [[WEG]] No disagreement there, but as I said above, we're rapidly approaching the point where it really doesn't matter either way, so if there are legitimate uses, let's have them. Otherwise, run what you brung.
> Thanks,
> Wes
If you believe it does not matter either way, then it should be done, 
simply because you may be wrong.


More information about the ARIN-PPML mailing list