[arin-ppml] Policy Proposal: IPv4 Recovery Fund

[Robert Bonomi]

> Date: Sun, 23 Nov 2008 20:44:05 -0500
> From: Leo Bicknell <bicknell at ufp.org>
>
> In a message written on Sun, Nov 23, 2008 at 06:05:05PM -0600, Robert Bonom=
> i wrote:
> > > In a message written on Fri, Nov 21, 2008 at 04:35:21PM -0700, Hawkes, =
> Dave=3D
> > >  wrote:
>
> > 2) The allocation methodology specified/required by the language at the e=
> nd of
> >    the section named "Distribution of Recovered Space" has a major, if no=
> t=20
> >    fatal, flaw.  To wit:
>
> You can see why we went for simple in the policy language. :)

<grin>

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

Agreed.  As I see it, once one is over the 'needs' hurdle, the next major
criteria should be 'urgency of need', which is effectively equivalent to
place in line (basis the assumption that requests/'needs' look are based
on a expectations for a common time-frame forward from application date).

On price, the present proposal for "declared bid, plus a 'line-position' 
based right of refusal for a higher price" seems to cover things adequately.
I favor price be given _low_ priority -- I don't think it's fair for someone
to get priority "just because" they advertized they were willing to pay
'top dollar';  OTOH if the 'cost' is more than they're willing to pay, 
and there -is- someone else willing to pay that cost, it should go to the
party 'willing to pay'.

Deaggregation -is- a touchy issue, but without a good model of return and
reallocation policies, including multiple repeat returns of the same block,
I don't see any strong rationale for favoring one solution over another 
on -that- basis.



> > 4) The 'recovery fund' needs to be self-supporting and self-sustaining. T=
> his
> >    necessitates that the incentive that ARIN pays out to 'facilitate' the=
> =20
> >    return of under-utilized space is "something less" than what the reque=
> sters=20
> >    are willing to pay for 'expedited' resource availability.
> >=20
> >    I have no idea what an appropriate "discount" from the requester's 'bi=
> d'
> >    price is -- this is something that staff should be able to derive, bas=
> ed
> >    on time/effort requirements for _just_ the "paid recovery"-related=20
> >    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.

Agreed.  I think, however, it needs to be explicit, either in the policy
itself, or at a minimum in the rationale, that there _will_ be a 'price
difference' in the two transactions, 'to cover overhead'.  'How much' that
is,  does -not- belong in the policy -- it is definitely 'operational 
housekeeping', as I see it.
>
> > 5) ARIN should _not_ need to provide "significant" seed money, as describ=
> ed=20
> >    in the "Cost Recovery" section.  The 'return' side can be treated as a=
> =20
> >    'solicitation of offers', where the current holder makes an 'offer' to=
> =20
> >    return the resource for a price, and that offer is binding for some=20
> >    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.

"yeahbut" applies.  How do you know what a 'fair price' is to offer for
that /8, when you have no idea what the buyers will be willing to pay, over
the next year forward?

Get a blip of people with 'extremely urgent' need, willing to pay top-
dollar early, and you could grossly overestimate what you can recoup for
the rest of the block.  Pay the returner based on the short-term anomolous
top-dollar bids you have, and you may have real problems moving the rest
of the space.