[arin-ppml] Policy Proposal: IPv4 Recovery Fund
bonomi at mail.r-bonomi.com
Sun Nov 23 19:05:05 EST 2008
> 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=
> 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
*** [[ 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,
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
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
More information about the ARIN-PPML