[arin-ppml] Policy Proposal: IPv4 Recovery Fund

[Robert Bonomi]

> Date: Fri, 21 Nov 2008 19:11:34 -0500
> From: Leo Bicknell <bicknell at ufp.org>
>
>
>
> In a message written on Fri, Nov 21, 2008 at 04:35:21PM -0700, Hawkes, Dave=
>  wrote:
>
> Not as written, and such a thing may be outside the policy area.

"Bookkeeping nuances"  -- which is all this amounts to -- would not seem
to _me_, to be an appropriate part of the "number resources management" policy.

"Administrative" (or something along those lines) policy, yes.


> I suspect most companies would rather have the money back than extend an
> interest free loan to ARIN. 

It would probably depend on the relative size of the amounts, and the
proximity of a payment due-date.   <wry grin>

>                              I wouldn't be opposed to such an idea
> provided that we maintained yearly contact, so perhaps the money could
> pay all but $1 of forward yearly fees so there is still a bill and a
> check written to keep the two-way touch in place yearly.

This is trivially accomplished by making the application of the credit
_not_ automatic.    The invoice goes out saying (paraphrased):
   "You owe $xx,xxx, you have a credit on record of $yy.yyy  If you wish 
    the credit applied against this invoice, you must expressly notify us
    of that intent at this time, and we will generate a revised invoice 
    showing the net amount due, if any."`

> But, let me stress, as written the policy would not enable this concept.

A _one_word_ change ("monetary" to "financial") -- in the two places in the 
first 2 sections, where 'monetary' is used -- in the draft language of the 
proposed policy addition *would* allow staff the flexibility to do that, at 
their discretion.


***  [[ going off on my own tangent(s) now ]]

A few other comments:

1) There are _two_ sections numbered as 4.10.2.  Fixing this will affect the
   numbering of all subsequent sections.

2) The allocation methodology specified/required by the language at the end of
   the section named "Distribution of Recovered Space" has a major, if not 
   fatal, flaw.  To wit:

     IF, for example, while nothing of a /21 or larger is available, two ORGs 
	   are each approved for a /21 on May 15, two more are approved (for 
	   /21s) on June 1, AND an ORG is approved for a /20 on July 1,
     THEN, when a /19 becomes available on July 15, under the 'best prefix 
	   match' rule, the "July 1" ORG would get a /20, and each "May 15" 
	   ORG would get a /21, with the two "June 1" ORGs being left out.

   I  believe that the 'desirable' outcome in that situation is that all 4 of
   the /21 requesters should get space, and that the /20 requester should have
   to wait for the -next- free block.

   The 'desirable' logic is fairly straightforward, although a bit messy in
   implementation (to wit, involves the "knapsack problem") --  select the 
   requests in descending order by size, and by ascending date of approval if 
   the same size, *except* that if there is a combination of pending smaller 
   block requests, all with _earlier_ approval dates than a selected larger 
   request, =and= where the sum of the sizes of those smaller requests 
   =exactly= matches the larger request, *then* the group of smaller requests 
   is satisfied, instead of the larger one.

3) Some "minor" language changes are required.  Notably in "Distribution of
   Recovered Space".  As proposed it asks what the requester will "pay for 
   a block of the specified size".  That _can_ be construed as the "offering
   for sale" of an asset that can be "purchased".  *NOT* what is intended, 
   I'm sure.

   A change to "willing to pay for 'expedited allocation' of a block.." would,
   I believe, more clearly represent what the money goes for, _without_ giving
   any toe-hold for a possible 'purchase' claim.

4) The 'recovery fund' needs to be self-supporting and self-sustaining. This
   necessitates that the incentive that ARIN pays out to 'facilitate' the 
   return of under-utilized space is "something less" than what the requesters 
   are willing to pay for 'expedited' resource availability.

   I have no idea what an appropriate "discount" from the requester's 'bid'
   price is -- this is something that staff should be able to derive, based
   on time/effort requirements for _just_ the "paid recovery"-related 
   operations.
 
5) ARIN should _not_ need to provide "significant" seed money, as described 
   in the "Cost Recovery" section.  The 'return' side can be treated as a 
   'solicitation of offers', where the current holder makes an 'offer' to 
   return the resource for a price, and that offer is binding for some 
   agreed-upon period of time

   Then, when (and *only* when) ARIN has 'bids' from requesters, covering 
   'most' (exact proportion intentionally left unspecified here) of the 
   _cost_ of the block offered for return, does ARIN 'accept' the offer.

   Also, obviously, if there are  no current offers, but are (FSVO) recently 
   'expired' offers to return, those are obvious points of contact to see if
   they have interest in doing so, at the current bid valuation.

   At most, ARIN will be (temporarily) picking up the tab for whatever portion
   of the recovered block is -not- use in filling pre-existing requests.

   For blocks that are acquired/stockpiled on such basis, one can price them
   at the 'average' acquisition cost.  This is the fair way to price things,
   and the process minimizes any discontinuities in price between successive 
   allocations from the stockpile, as well as minimizing the pricing recalc-
   ulations that have to be done (i.e., only when a new block is added to the
   stockpile.)