[address-policy-wg] Re: The emacs, X windows and Linux approach to policy making

Well, allow me to step back a couple of <whatever is your favourite choice
for measuring distance> and look back what happened...

First of all, imho there has been a fundamental flaw in this proposal,
from the very beginning (and this has only become apparent in retrospct,
so no criticism here! If I would have noticed in time I would be much
happier now): this proposal tried to combine a global policy - which by
def. is meant to direct IANA'S operation! - with a "humanitarian" or
"political" resource-re-distributio aspect for recovered address space
(if any) to apply equally in all regions.

So, actually, it combined a global policicy with regional policies.

The latter aspect failed. I don't want to get into details, or what my
personal opinion is, just stick to the facts and the process.

>From what has happened already, wearing my hat as a member of the Address
Council, I consider the current approach as doomed. Which is a Goog Thing,
imho, because it makes the reasoning of "backing up" the position of *one*
region or of *three* regions, by having RIPE accept a) or b), irrelevant.

Because whatever the "result" is, either 4:1 or 3:2, it does not help in
solving the basic problem:

Give IANA a (global) policy how to re-distribute address space which happens
to be returned. For whatever reason...

So, my proposal would be to withdraw 2009-01 unconditionally, as being o.b.e.

At the same time we c|should explore the possibility to start the process for
a re-distribution policy for IANA.

Taking off my AC hat now...

Everything else should be left where I think it belongs: within the regions,
to decide how to manage recovered/returned *legacy* resources, that have been
"tagged" as being managed in one of the five regions by the ERX process.

Wilfried

Nigel Titley wrote:

> On Wed, 2010-04-14 at 11:26 +0100, Jim Reid wrote:
> 
>>It's tempting to consider tweaking our policy for the IPv4 dregs to  
>>show our displeasure at the path ARIN has adopted. However I hope we  
>>can rise above that.
> 
> 
> We would not be tweaking the policy to show displeasure. Option 1 (which
> "shows displeasure with ARIN") is actually the original proposal. Option
> 2 which doesn't, tweaks the policy. Sorry to be pedantic. 
> 
> 
>>I'm also beginning to wonder if policy-making is being unconsciously  
>>shaped by the Linux/emacs/X-windows approach to software design. If  
>>that can be called "design". [The only thing wrong with these bits of  
>>code is they don't have enough options or configuration variables to  
>>tweak. :-)] I would like to see fewer options on what to do about  
>>2009-01. Ideally it should be reduced to a binary choice.
> 
> 
> I'm happy with that.
> 
> 
>>With that in mind and Nigel's comments that the proposal is dead and  
>>starting to have a bad smell, I suggest we reduce the discussion of  
>>2009-01 to a simple choice of whether to withdraw it or not.
> 
> 
> In my original terms we decide either to adopt option #1 (go with the
> existing proposal) or option #4. I'm very happy with offering just these
> choices.
> 
> 
>>IMO, withdrawing this proposal makes the most sense. Continuing with  
>>it would only be worthwhile if the same approach to recovered space  
>>was being followed by the other RIRs. Since that's no longer possible,  
>>I think we should just stop flogging this dead horse.
> 
> 
> This is a fair point... and I'm happy to accept it if the community
> decides this is the consensus position.
> 
> 
>>If there's support for keeping 2009-01 alive, I'd like to suggest we  
>>focus the discussion to a choice between two mutually exclusive  
>>positions:
>>
>>1) recovered space goes back to IANA for it to redistribute somehow
> 
> 
> This is 2009-01 in essence.
> 
> 
>>2) recovered space stays with the NCC for redistribution according to  
>>RIPE policy
> 
> 
> This is a new policy and outside scope for the present discussion.
> 
> Nigel