[arin-ppml] Draft Policy 2010-10 (Global Proposal): Global Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text revised)
Leo Bicknell
bicknell at ufp.org
Fri Oct 29 14:42:52 EDT 2010
In a message written on Fri, Oct 29, 2010 at 01:39:53PM -0400, Sweeting, John wrote:
> Eligible address space includes addresses that are not designated as "special use" by an IETF RFC.
> Address space may only be returned by the issuing RIR. Legacy address
> holders may return address space directly to the IANA if they so choose.
I don't believe this matches what has happened for the few blocks
that have been returned. I believe the /8's returned so far went
to ARIN and then to IANA.
Also, I believe this requires IANA to provide a customer service
function they don't provide today. IANA has "outsourced" all address
space interactions to the RIR's. For instance it is my understanding
part of the legacy space transfer project of a few years ago was
to get any supporting documentation also transferred. Thus the
party in a position to verify that the space in question can be
returned by the person returning it is the RIR, who holds the
paperwork.
Long story short, I'm really baffled by legacy needs to be treated
any differently for this policy. While I am a strong proponent of
legacy space going back into the global free pool it seems to me
it should be returned to the RIR currently managing it, just like
any other returned block. Said RIR should then return it to the
IANA free pool, just as has happened in the past.
The only way in which Legacy space should be treated differently
in my opinion is that the RIR should be required to return it to
IANA, rather than returning it to its own free pool.
Why are we creating two different processes?
--
Leo Bicknell - bicknell at ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101029/5ac6600a/attachment.sig>
More information about the ARIN-PPML
mailing list