[address-policy-wg] The final /8 policy proposals, part 3.2

On 05/09/2009 15:09, Sander Steffann wrote:
> Hello again,
>
> After my last questions I have only received concrete answers from
> Michael. He suggested the following:
> - Use a minimum allocation size of /24
> - Determine the maximum allocation size for every LIR based on their run
> rate
> - Make no exceptions for cases where it is hard or impossible to downscale

Sander,

The issue of the last /8 is simply a question of determining the shape of 
the depletion curve.  We know our where we are on this curve right now, and 
we know how fast we're slipping down it.  We also know that after the curve 
hits zero, life will muddle on.

The issue that we're tying ourselves up in knots about is how to find some 
way of allocating the last iana-assigned address blocks in a way which is 
more "fair" than it's currently allocated.

As a recap, the RIPE NCC currently allocates / assigns space on the basis 
of stated requirement over a specific time period.  I think it's reasonable 
to say that most LIRs and most members of the RIPE community find this to 
be a "fair" mechanism.  It's not perfect - no resource allocation mechanism 
of any form is - but with 20 years hindsight, we still haven't come up with 
a "fairer" system.

There have been some suggestions about increasing "fairness" by giving 
preferential treatment for certain types of applicants.  E.g. new LIRs 
might get certain preferential entitlements, while existing LIRs might get 
less than they request.  This sort of policy strikes right to the heart of 
"fairness", as what's very fair and right for the organisations receiving 
preferential treatment is going to be very unfair and quite wrong for the 
organisations which are discriminated against.  If RIPE and the RIPE NCC 
are looking for a quick and easy way of attracting nasty and sustained 
criticism (and lawsuits), this is a damn good way to do it.

Balanced against this is a necessity to ensure that address-block hogging 
is minimised in the last days of easily available ipv4 address space (let's 
not kid ourselves into believing that it can be eliminated).  To this end, 
Policy Proposal 2009-03 provides a remarkably succinct tweak to the current 
allocation mechanism which looks like it will hinder address block hogging 
in a manner which is completely open, completely non-discriminatory and 
entirely reasonable under the circumstances.

It doesn't attempt to redefine the current assignment mechanism - which is 
a good thing of itself.  It doesn't create a rampantly unfair new mechanism 
which is untried and untested.  It doesn't start some new assignment policy 
based on a rather arbitrary basis (why /8?  why not /7 or /9?)  It changes 
very little, except for smoothing out some bumps on the tail end of the 
allocation curve.

And although I dislike the title of the policy very much (I can volunteer 
to act as neutral third party to count votes for the colour of this 
particular bikeshed, if people are interested?), I would like to propose 
that we simply drop all current policy proposals about changing allocation 
mechanisms for the last /8 and work on 2009-03 instead.

By "work on" I mean that the proposal as it stands may need very minor 
tweaking (e.g. considering whether to change the time-scales which are 
currently hard-coded in the proposal into time-scales which are based on 
historical run rates).  But the policy proposal as it stands is good and I 
like it very much indeed.

I would also like to propose that we consider at this stage whether it 
would be useful to reserve small quantities of virgin address space for 
specific _temporary_ assignment / allocation purposes.  Things like the 
current experimental assignment system, and maybe conferences and that sort 
of thing.  But the critical criterion here is that the assignments / 
allocations are strictly temporary, and that there is a well-defined upper 
bound on the maximum time limit for the assignment / allocation.  Other 
than temporary assignments, I don't realistically see a means of 
non-contentiously reserving other address blocks for permanent assignment / 
allocation.

In summary, I propose we drop 2008-06 and 2009-04, that we adopt 2009-03 
and that we come to realise that these endless discussions on the 
assignment of the last iana /8 are not going anywhere.

Nick