[arin-ppml] Policy Proposal: IPv4 Recovery Fund

[Leo Bicknell]

In a message written on Sun, Nov 23, 2008 at 06:05:05PM -0600, Robert Bonomi wrote:
> > 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.

Yes.  To use ARIN terms we have "policy" and "operational issues",
the former is decided via the policy process, the later via the
ARIN Suggestion and Consultation Process (ASCP).  I was imprecise,
it is not policy, it would be something for the ASCP were this to
be adopted, IMHO.

> 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."`

An absolutely excellent suggestion, were this policy to be adopted.

> 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.

I've specifically set this feedback aside for potential inclusion
in future revisions of the policy.

> A few other comments:
> 
> 1) There are _two_ sections numbered as 4.10.2.  Fixing this will affect the
>    numbering of all subsequent sections.

Doh, and artifact of the editing.  Will fix.  Note that staff will
always renumber when they insert in the policy manual, these are
placeholders for discussion only.

> 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:

You can see why we went for simple in the policy language. :)

Effectively there are three variables that can be prioritized:

1) Deaggregation.
2) Price.
3) Order in line.

You method is an interesting hybrid, and I'm not particular for it or
opposed.  What I am very interested in doing is trying to reach some
consensus on how the community whats them priorized; we can always
design an system that does what the community wants.

> 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.

Also noted for future revisions.

> 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.

The original language had various references to ARIN overhead, but
it quickly got so complicated all of the people I talked to said
dump it from policy.  The key here to me comes back to the fact
that the policy is supposed to be generally cost recovery, and so
to me overhead would count, but most of that to me is operational
housekeeping by ARIN.

> 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

I'm not quite sure how much money is needed here.  One of the things
this enables is somewhat decoupling supply from demand.  That is,
let's say ARIN burns a /14 per week, and someone comes along with
a /8 they want to release.  Rather than wait for 64 weeks for enough
/14's to pile up ARIN could go get the /8 and then provide it over
the next 64 weeks.

At the end of the day I'm not so concerend if "seed money" is $10,000
or $1,000,000, rather I'm concerned that the program is basically
cost recovery and that money goes back to the ARIN general fund at
some point.  I see no reason for ARIN to make or lose money on this
operation.

-- 
       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/20081123/f6a15785/attachment.sig>