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

Hello Nick,

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

Preferential treatment will indeed cause problems. The existing LIRs  
using up all remaining IPv4 addresses in a short time will also cause  
problems. I agree that we need a policy that is the same for everybody.

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

The problem with dropping all final /8 proposals except 2009-03 is  
that with 2009-03 the addresses will be used up as quickly as with the  
current policy. The addresses are requested in smaller blocks but  
there is no downscaling of the request size. Instead of requesting  
enough addresses for one year once per year organizations will request  
enough addresses for 6 months twice per year. The cumulative run rate  
will remain the same. That means that the existing LIRs will use up  
all remaining IPv4 addresses in a few months, which is a very bad  
situation (IMHO/IANAL/etc).

2009-03 is meant to prevent that a few very big requests use up all  
remaining addresses, which is important. It doesn't solve the problems  
that 2008-06 and 2009-04 try to solve. 2009-03 explicitly mentions  
this: "The proposal is independent of other proposals to reserve  
address space for transition purposes and/or new entrants."

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

Exactly.

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

I fully agree with working on 2009-03, but I'm not yet convinced that  
we should abandon the other final /8 proposals.

> 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 agree. I like it too, but not for the purpose you want to use it  
for :)

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

Reserving address space for temporary assignments sounds like a good  
plan.

Thanks,
Sander