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

Owen DeLong owen at delong.com
Mon Aug 17 16:57:12 EDT 2009

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


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

More information about the ARIN-PPML mailing list