[arin-ppml] Policy Proposal: IPv4 Recovery Fund

[Leo Bicknell]

In a message written on Sat, Nov 22, 2008 at 11:12:56AM -0500, Milton L Mueller wrote:
> Whatever your opinion of auctions, etc. you really, really need to get
> used to the fact that you _cannot_ maintain the old system of first
> come, first served needs-based allocations in a regime of ipv4 scarcity.
> Once the free pool is depleted (and even now, when its depletion is in
> sight) v4 allocations are about _relative_ value among competing
> applicants, not some absolute measure of technical justification. 

There are two points of rebuttle, and to take the easier one first....

At some point, perhaps 50 years from now, IPv4 will be on the
decline.  At that point we will likely return to a simple needs
based system for those who still need it.  It would be nice if
whatever system we put in place does not make that transition back
difficult.

But more importantly, you seem to be putting an emphasis on both
first-come first-served and on needs based that is over and above
what I intended.  They are in fact separate features that solve
separate problems in this case.  Needs based maintains a way to get
in the door.  This is no different than a Lloyds of London checking
your bank account to make sure you have the minimum bid in cash
before letting you in.  A brokerage is not going to be able to
justify need to hold your position in line, need is not "I have a
lot of money" or "I can dream up a big network".  Rather, ARIN today
asks for things like signed contracts with transit and transport
providers to prove you have a network that needs IP's.  Needs based
should in fact keep most brokerages and speculators out.  I emphasize
most, someone will always try to game the system, and no solution
is 100%.

Once you've passed the threshold to be inside the tent and bid
there's another potential problem.  Unlike Lloyd's where there is
a single real Mona Lisa to auction ARIN may have hundreds or even
thousands of identical blocks.  Consider if ARIN recovers a /8 and
everyone in line wants /19's, that's 2,048 people who can be serviced.
Holding a 2048 way bidding war would be a logistical disaster, the
last bidder would have had to participate in 2046 previous auctions.
This proposal side-steps that completely; rather tha ARIN hold a
bid they set a price based on what it cost to recover the space and
simply give it out to the 2048 people in line.

I had discussed an idea with others while writing this proposal to
distribute the space via dutch auction.  That is, still needs based
to be able to bid, but then everyone in line (potentially 10,000
people) bid.  The bids are ranked highest to lowest, and in the case
above the 2048th bid is picked.  Bidders 1-2048 then receive space
for the bid of 2048th person.  This is also relatively simple to
implement; but it has the chance of ARIN ending up with a huge
surplus of money.  It can be argued that is good, as ARIN would
then have more money to offer to reclaim resources, or it can be
argued that is bad, ARIN should not end up making money on this
effort.  If you think some sort of bidding scheme like this (in the
generic, I'd had to get bogged down in specifics at this point) would
make you more likely to support the proposal I'd love to have that
discussion.

Lastly on this point, this problem is not limited to this proposal.
If we consider a proposal like 2008-6, and I am a /8 holder who
wants to sell my block and all of the bidders want /19's I now have
to deal with 2048 people and perform some sort of negotiation or
auction.  Under a proposal like 2008-6 every resource holder will
likely do this via different methods with different terms and
conditions.  This is absolutely the situation that will bring
brokerages into the system and create overhead.  Companies will not
be looking for IP's every day, so they will pay someone who does
it on a day to day basis to know where the best deals are and to
complete the transaction for them.  This overhead will raise prices
and reduce transparency.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081122/22a143b9/attachment.sig>