[ppml] Policy Proposal: 2007-12 IPv4 Countdown Policy Proposal
rich at nic.umass.edu
Wed Mar 21 16:44:09 EDT 2007
I'm jotting this off quickly.
My first reading of the proposal before it was re-petitioned, was that it's
adaption would be more likely to cause a run on the bank right after
adoption, speeding exhaustion, not holding it up.
Driving a car off a tall cliff is general a bad idea; not doing is the alternative.
I might investigate voluntary recovery of unused numbers as a better first
step. Email postage is still cheap, and most people probably haven't been
ARIN maintains a registry of unique numbers for those who require
uniqueness; there is no requirement the numbers show up in the routing table.
For those that gloom about the size of the global routing table, this could
be construed to be a good thing.
I have a list of 10 /8's which are not seen in the global tables. I might
ask those folks first, what they'd be willing to do. Larger, order /16's
might be the next order of business. ARIN records not updated in 10 or 12 years.
As I understand it, there some action taking towards cleaning out the swamp
at one point, by trading for address space. /8 holders (ala Stanford) might
be able to trade down.
I'd not force the issue until I'd see what asking did.
Renumbering consumes the resources (time, money, etc) of the enitity. It
might be worth offering up some IPv6 space in lieu of, and outside of the
current allocation minimums -- Any size of IPv4 smaller than what you have +
an IPv6 block, might be a not unreasonable offer. Some people might be able
to take advantage of this, others won't be able to.
A co-worker & his wife ran around the house one day checking the seat
cushions and change jars, and came up with $600 in loose change. Maybe
there's no loose change out there in IPv4 Land, but has any one asked anyone
to check under the cushions.
Or maybe we're unwilling to try and use a collaborative approach, and should
instead adopt the Atilia the Hun method. But I'd rather not.
If we're heading for a disaster, we shouldn't be waiting for "A-Date" or
"D-Date" whatever the psuedo-math formula was. If the exhaustion models
are accurate, rewrite the policy around specific dates, since the models
already predict them.
Gimme a specific date, if you want me to move staff and management, not some
arbitrary future trigger event that can be ignored.
Even with that, I'd still oppose it on the basis of a belief, it will have the opposite behavior.
Note 1: RFC1925 Controls, especially 2(4).
Note 2: IPv4 Exhaustion assumptions are using the wrong smoothed curve. It'll be a logistic ("S") curve, not exponential.
On Wed, 21 Mar 2007, Ted Mittelstaedt wrote:
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>> Rich Emmings
>> Sent: Wednesday, March 21, 2007 7:35 AM
>> To: ppml at arin.net
>> Subject: Re: [ppml] Policy Proposal: 2007-12 IPv4 Countdown Policy
>> I can't add to the discussion, without repeating points raised,
>> other than to say "opposed" as written.
> If you are going to go on record opposing, then what exactly is the
> alternative that you do support?
More information about the ARIN-PPML