[arin-ppml] Revised -- Policy Proposal 2009-4: IPv4 Recovery Fund

[Leo Bicknell]

In a message written on Sat, Apr 11, 2009 at 01:30:55PM -0700, Matthew Petach wrote:
> In that case, can we consider calling this an 'escrow' function
> rather than a 'recovery fund'?
> 
> I don't like the idea of sending a check for $250,000 to ARIN for
> them to put in their "recovery fund'" in the hopes they find a
> seller.

That's not quite how it works.

If you need space, you would:

1) Go through the exact same approval process as today, but rather than
   receive space you would receive a bid form.

2) Place a bid ($250,000 in your example).

At this point ARIN would go off and find space, if possible.  Let's
say they do find space, and for only $50,000.

3) ARIN asks you for the $50,000.  When the check clears, you get the
   space.

Your money is not tied up at ARIN.  We could structure the proposal the
other way around, that is you pre-deposit the $250,000 and you get back
the space plus whatever is left over.  I haven't really thought about
the pros and cons of that situation.

This is also a key point of concern from a legal/staff/Board
perspective.  Note in the example above ARIN pays the $50,000 to
the returner before they collect the $50,000 from you.  One of the
prime worries is what if you don't pay, is ARIN out the $50,000.
However, I think this is unlikely for two reasons; one is you have
a prequalified bidder who has done a significant amount of work to
get to the point where they would pull out, so that doesn't seem
likely; and would be prohibited by contract.  Also, even if you
didn't end up taking the space, there is likely to be a long line
of other people who want it.  I firmly suspect demand will be much
higher than supply.

> However, if I indicate an interest in purchasing a block of size X 
> at a cost not to exceed $250,000, and ARIN finds an entitty 
> willing to free up the space at or below that cost, I have considerably
> fewer qualms about having ARIN act as the escrow agent for the 
> funds while the transaction is proceeding.

Escrow, to me, requires a 1:1 match.  You need a /16, ARIN finds
someone with a /16, the two of you are matched.  ARIN becomes the
neutral party in the middle.  While that is possible, it precludes
all sorts of more interesting transactions, and also means the two
parties end up sharing fate, something the proposal was seeking to
avoid.

For instance, if ARIN convinces someone to give back a /8, but no
one is willing to pay the extremely high price required to get the
whole thing then it may need to be broken up into say, 16 /12's.
Having to get 17 folks into a classic escrow all at the same time
seems difficult.

That said, there's no reason this couldn't be done in some sort of
escrow fashion.  It would probably be slightly more complicated than
what is done with say, a house transaction, but it is possible.

> Can the proposal be edited to more accurately reflect the 
> function being provided as that of an escrow service, rather 
> than a recovery fund?

I think the AC would be quite open to editing the proposal if it
was a way to gain community support.  I did select the initial
title, which has stuck with the proposal, but after the first
comments back I realized it was a poor choice.  "Recovery Fund"
does not convey the correct sentiment of how this works.

At several meetings folks kept saying the same thing, "I wish there
was some alternative to a transfer policy" (referring primarily to
2008-2 the time).  I wanted to be sure we had an alternative concept to
consider, and thus I authored the original version of this proposal.
That said, we're running out of time.  IPv4 exhaustion will be here
soon, and whatever proposal we do ARIN must prepare.  The AC and the
Board need to know what the community wants.  If it's not exactly what
has been described in any of the proposals then please, describe it to
us.  We can turn it into policy.

--
       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/20090411/199d077a/attachment.sig>