[arin-ppml] Update on 2009-3: Global Policy for the Allocationof IPv4 Blocks to RIRs

[Owen DeLong]

>
> If we are going to leave it up to the discretion of the RIR whether  
> or not
> or how they do it then the entire clause is meaningless and should be
> omitted.
>
Not entirely.

Without policy (globally coordinated policy), I'm not sure IANA has a
way to accept and/or re-issue space returned by RIRs, at least not
in chunks smaller than /8.

> Are we going to tell everyone they have to return the space or are  
> we just
> going to suggest it would be nice?  If it is the latter then it has  
> no place
> in policy.  There is no point in telling young Johnnie that he has  
> to be
> home no later than 10:00 unless he decides he wants to stay out  
> later.  I
> see no carrot, stick, or even enforceable limit emplaced here.
>
That's the big question.  I, for one, feel that it is inappropriate  
for an RIR to
return space to IANA if there is a justified need for that space to be  
issued
to other organizations within the RIR's region.  However, I do feel that
it is good for excess space in any region to be returned to IANA to be
redistributed to other regions.

> If we make this conditional on local policy then the RIR can do an  
> end run
> with a simple policy change.  With that in place the entire exercise  
> is
> meaningless.
>
Well... Said RIR can, essentially opt-out of returning the space to  
IANA,
but, the rest of the policy would still stand.  However, with a simple
policy change, an RIR can make it impossible to return space to the
RIR, so, I'm not sure there's much of a difference there.

I think it is reasonable to make enabling policy without necessarily
making it a forced issue. RIRs certainly should be able to return excess
space to IANA and certainly should be encouraged to do so. However,
I have an issue with RIRs being forced to return space which may not
be excess within their region, so much as in need of redistribution
within the region.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090817/03fe74e1/attachment.htm>