Comments on Implementing the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA
Dear IANA, The global policy for Post Exhaustion IPv4 Allocation Mechanisms calls for the IANA to administer a temporary holding registry for certain forms of IPv4 address space that has been returned to the Regional Internet Registries (RIRs) and is awaiting redistribution back to the RIRs under the terms of the global policy. What this policy does not call for is the redefinition of the IANA IPv4 address space registry (http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml). The IANA discussion paper canvasses a number of "Registry features", and notes that there are "key options" when considering modifications to the Ipv4 registry. It is noted that the global policy for Post Exhaustion IPv4 Allocation Mechanisms did not call for functional changes to the existing IPv4 registry, including the ability to apply a filter to the registry contents, the ability to search the registry, and the graphical representation of particular elements in the registry. Our comment is that irrespective of the merits or otherwise of these registry features, the consideration of the inclusion of these features into the IANA IPv4 address space registry is beyond the scope of the global policy for Post Exhaustion IPv4 Allocation Mechanisms. Accordingly, we do not agree with the proposition that such options should be considered when implementing the registry actions associated with this policy. This section of the paper also canvasses the registration of legacy registrants with /8s and appears to suggest that there are special considerations at play here that differ from the requirements of other address blocks that are described in this registry. The paper does not elucidate as to what such requirements may be, and there is no clear explanation of this assertion. The position of APNIC is one that is strongly in favour of the "multiple registries" approach. The ground for this position is that the registries are actually different registries that describe different circumstances and different actions. The existing IANA Ipv4 registry records the historical actions of the IANA in performing allocations and assignments of IPv4 address space, recording the status of the address space, the administrative controller of each block of address space, the data of allocation or assignment, and a pointer to the relevant document as appropriate. The Returns Registry is intended to function as a "parking lot": returned address space is recorded in this address space for the duration of the time it is held by the IANA, and at the time of its subsequent assignment or allocation to an RIR the entry would be erased from the Returns Registry, as it is no longer held by the IANA. The difference between the two registries is that the IPv4 address space registry records the history of IANA's allocations of /8 address blocks, while the proposed Returns Registry would describe the set of returned addresses that are currently held by the IANA prior to their redistribution. APNIC notes that the IANA IPv4 address space registry does not contain a detailed list of the current disposition of every IPv4 address, nor is it the intent of this registry to contain such information. The body of the IANA IPv4 registry records the designation status of each component /8 block in the IPv4 address space. APNIC notes that the global policy for Post Exhaustion IPv4 Allocation Mechanisms does not call for any changes to this registry management practice, and therefore concludes that a consistent implementation of this policy would leave this registry unaltered. With respect to the allocation practices canvassed in this paper APNIC notes the pros and cons of the two approaches as described in the paper and has no particular preference to either approach. Thanks, Byron Ellacott -- Byron Ellacott email: bje@xxxxxxxxx Technical Director, APNIC sip: bje@xxxxxxxxxxxxxx http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary. Attachment:
smime.p7s |