<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">I am in support of the proposal too, just a few observations:-<br><br>>Pool will be divided on CIDR boundaries and distributed evenly to all<br>> eligible RIRs<br><br>I find this directly contradictory to reference to base allocations on "need" or do i have my definition of "even" wrong?<br><br>>> Upon the exhaustion of an RIR's free space pool and after receiving<br>> their final /8 from the IANA[3]<br><br>This can be construed to mean they don't have to exhaust their last /8....is this the intention?<br><br>>Any RIR that is formed after the<br>> ICANN Board of Directors has ratified this policy is not eligible to<br>> utilize this policy to obtain IPv4 address space from the IANA.<br><br>What is the rationale here? me thinks that if an RIR is formed at this point, they will  need these resources the most. From the policy, there

 will be no other v4 resource as the main pool and probably the /8 pool (depending on response to my query 2), will both be depleted. meaning this RIR will not have v4 at all.<br><br><br>Regards,<br>Douglas Onyango +256(0712)981329<br>

Life is the educators practical joke in which you spend the first half learning, and the second half learning that everything you learned in the first was wrong.<br><br>--- On <b>Sat, 8/28/10, McTim <i><dogwallah@gmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: McTim <dogwallah@gmail.com><br>Subject: Re: [AfriNIC-rpd] Proposal: Global Policy for IPv4 Allocations by the IANA Post Exhaustion now online<br>To: "AfriNIC Resource Policy Discussion List" <rpd@afrinic.net><br>Date: Saturday, August 28, 2010, 4:21 PM<br><br><div class="plainMail">Am happy to support this proposal.<br><br>-- <br>Cheers,<br><br>McTim<br>"A name indicates what we seek. An address indicates where it is. A<br>route indicates how we get there."  Jon Postel<br><br><br>On Fri, Aug 27, 2010 at 4:20 PM, Mukom Akong T. <<a ymailto="mailto:tamon@afrinic.net"

 href="/mc/compose?to=tamon@afrinic.net">tamon@afrinic.net</a>> wrote:<br>><br>> Hello all,<br>><br>> The proposal is now up on the website and can be assessed at<br>> <a href="http://www.afrinic.net/docs/policies/AFPUB-2010-v4-003.htm" target="_blank">http://www.afrinic.net/docs/policies/AFPUB-2010-v4-003.htm</a><br>><br>> Thanks<br>><br>> On 8/25/10 10:16 PM, Steve Bertrand wrote:<br>>> 8<---------------------------------->8<br>>><br>>>     Your Name:<br>>>               Steve Bertrand<br>>>               Chris Grundemann<br>>>               Martin Hannigan<br>>>               Aaron Hughes<br>>>               Louie Lee<br>>>               Matt

 Pounsett<br>>>               Jason Schiller<br>>>     Your Organisation:<br>>>     Policy Afected:<br>>>     Date: 2010-08-25<br>>>     Proposal:Global Policy for IPv4 Allocations by the IANA Post<br>>>     Exhaustion<br>>>     Incentive: Allow all IPV4 inventory regardless of prefix size to be<br>>>                returned to, and subsequently reallocated fairly and<br>>>                equitably by the IANA post-runout.<br>>><br>>> 8<--------------------------------->8<br>>><br>>> Global Policy for IPv4 Allocations by the IANA Post Exhaustion<br>>><br>>> Rationale:<br>>><br>>> This policy defines the process for the allocation of IPv4 addresses<br>>> post "Exhaustion

 Phase"[1]. A global policy is required in order for the<br>>> IANA to be able to transparently continue to be able to allocate IPv4<br>>> addresses beyond exhaustion. In order to fulfill the requirements of<br>>> this policy, the IANA must set up a reclamation pool to hold addresses<br>>> in and distribute from in compliance with this policy. This policy<br>>> establishes the process by which IPv4 addresses can be returned to and<br>>> re-issued from the IANA post Exhaustion Phase.<br>>><br>>> This document does not stipulate performance requirements in the<br>>> provision of services by the IANA to an RIR in accordance with this<br>>> policy. Such requirements should be specified by appropriate agreements<br>>> among the RIRs and ICANN.<br>>><br>>> The intent of this policy is as follows:<br>>><br>>> * To include all post Exhaustion Phase IPv4 address space

returned to >> the IANA. >> * Allows allocations by the IANA from the Reclamation Pool once the >> Exhaustion Phase has been completed. >> * Defines "need" as the basis for further IPv4 allocations by the IANA. >> * Does not differentiate any class of IPv4 address space unless >> otherwise defined by an RFC. >> * Encourage the return of IPv4 address space by making this allocation >> process available. >> * Disallow transfers of addresses sourced from the Reclamation Pool in >> the absence of an IPv4 Global Transfer Policy to neutralize transfer >> process inequities across RIR regions. >> * Applies to legacy IPv4 Address Space initially allocated by the IANA >> to users including the allocations to RIRs. >> * Includes any length of fragments currently held by the IANA now or in >> the future. >> >> 1.

 Reclamation Pool<br>>><br>>> Upon adoption of this IPv4 address policy by the ICANN Board of<br>>> Directors, the IANA shall establish a Reclamation Pool to be utilized<br>>> post RIR IPv4 exhaustion as defined in Section 4. The reclamation pool<br>>> will initially contain any fragments that may be left over in IANA<br>>> inventory. As soon as the first RIR exhausts its inventory of IP address<br>>> space, this Reclamation Pool will be declared active. When the<br>>> Reclamation Pool is declared active, the Global Policy for the<br>>> Allocation of the Remaining IPv4 Address Space[3] and Policy for<br>>> Allocation of IPv4 Blocks to Regional Internet Registries[4] will be<br>>> formally deprecated.<br>>><br>>> 2. Returning Address Space to the IANA<br>>><br>>> The IANA will accept into the Reclamation Pool all eligible IPv4 address<br>>> space that are

 offered for return. Eligible address space includes<br>>> addresses that are not designated as "special use" by an IETF RFC or<br>>> addresses allocated to RIR's unless they are being returned by the RIR<br>>> that they were orignally allocated to. Legacy address holders may return<br>>> address space directly to the IANA if they so choose.<br>>><br>>> 3. Address Allocations from the Reclamation Pool by the IANA<br>>><br>>> Allocations from the Reclamation Pool may begin once the pool is<br>>> declared active. Addresses in the Reclamation Pool will be allocated on<br>>> a CIDR boundary equal to or shorter than the longest minimum allocation<br>>> unit of all RIRs in order to complete these allocations.The Reclamation<br>>> Pool will be divided on CIDR boundaries and distributed evenly to all<br>>> eligible RIRs. Any remainder not evenly divisible by the number of<br>>>

 eligible RIRs based on a CIDR boundary equal to or shorter than the<br>>> longest minimum allocation unit of all RIRs will remain in the<br>>> Reclamation Pool. Addresses that are left over will be held in the<br>>> Reclamation Pool until additional IP addresses can be returned to rejoin<br>>> addresses on CIDR boundaries to the Reclamation Pool or a minimum<br>>> allocation unit is set to allow allocation from existing inventory.<br>>><br>>> 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool<br>>><br>>> Upon the exhaustion of an RIR's free space pool and after receiving<br>>> their final /8 from the IANA[3], an RIR will become eligible to request<br>>> address space from the IANA Reclamation Pool when it publicly announces<br>>> via its respective global announcements email list and by posting a<br>>> notice on its website that it has exhausted its supply

 of IPv4 address<br>>> space. Exhaustion is defined as an inventory of less than the equivalent<br>>> of a single /8 and the inability to further assign address space to its<br>>> customers in units equal to or shorter than the longest of any RIR's<br>>> policy defined minimum allocation unit. Any RIR that is formed after the<br>>> ICANN Board of Directors has ratified this policy is not eligible to<br>>> utilize this policy to obtain IPv4 address space from the IANA.<br>>><br>>> 5. Reporting Requirements<br>>><br>>> The IANA shall publish on at least a weekly basis a report that is<br>>> publicly available which at a minimum details all address space that has<br>>> been received and that has been allocated. The IANA shall publish a<br>>> Returned Address Space Report which indicates what resources were<br>>> returned, by whom and when. The IANA shall publish an

 Allocations Report<br>>> on at least a weekly basis which at a minimum indicates what IPv4<br>>> address space has been allocated, which RIR received the allocation and<br>>> when. The IANA shall publish a public notice confirming RIR eligibility<br>>> subsequent to Section 4.<br>>><br>>> 6. No Transfer Rights<br>>><br>>> Address space assigned from the Reclamation Pool may be transferred if<br>>> there is either an ICANN Board ratified global policy or globally<br>>> coordinated RIR policy specifically written to deal with transfers<br>>> whether inter-RIR or from one entity to another. Transfers must meet the<br>>> requirements of such a policy. In the absence of such a policy, no<br>>> transfers of any kind related to address space allocated or assigned<br>>> from the reclamation pool is allowed.<br>>><br>>> 7. Definitions<br>>><br>>> IANA -

 Internet Assigned Numbers Authority, or its successor<br>>><br>>> ICANN - Internet Corporation for Assigned Names and Numbers, or its<br>>> successor<br>>><br>>> RIR - Regional Internet Registry as recognized by ICANN<br>>><br>>> MoU - Memorandum of Understanding between ICANN and the RIRs<br>>><br>>> IPv4 - Internet Protocol Version Four(4), the target protocol of this<br>>> Global Policy<br>>><br>>> Free Space Pool - IPv4 Addresses that are in inventory at any RIR,<br>>> and/or the IANA<br>>><br>>> 8. Contributors<br>>><br>>> The following individuals donated their time, resources and effort to<br>>> develop this proposal on behalf of the Internet Community:<br>>><br>>> Steve Bertrand <<a ymailto="mailto:steve@ipv6canada.com" href="/mc/compose?to=steve@ipv6canada.com">steve@ipv6canada.com</a>><br>>> Chris Grundemann

 <<a ymailto="mailto:cgrundemann@gmail.com" href="/mc/compose?to=cgrundemann@gmail.com">cgrundemann@gmail.com</a>><br>>> Martin Hannigan <<a ymailto="mailto:marty@akamai.com" href="/mc/compose?to=marty@akamai.com">marty@akamai.com</a>><br>>> Aaron Hughes <<a ymailto="mailto:ahughes@bind.com" href="/mc/compose?to=ahughes@bind.com">ahughes@bind.com</a>><br>>> Louie Lee <<a ymailto="mailto:louie@equinix.com" href="/mc/compose?to=louie@equinix.com">louie@equinix.com</a>><br>>> Matt Pounsett <<a ymailto="mailto:matt@conundrum.com" href="/mc/compose?to=matt@conundrum.com">matt@conundrum.com</a>><br>>> Jason Schiller <<a ymailto="mailto:schiller@uu.net" href="/mc/compose?to=schiller@uu.net">schiller@uu.net</a>><br>>><br>>> 9. References<br>>><br>>> 1. <a href="http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm"

 target="_blank">http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm</a><br>>> Global Policy for the Allocation of the Remaining IPv4 Address Space,<br>>> IANA, Retrieved 27 April 2010<br>>><br>>> 2. <a href="http://aso.icann.org/documents/memorandum-of-understanding/index.html" target="_blank">http://aso.icann.org/documents/memorandum-of-understanding/index.html</a><br>>> ICANN Address Supporting Organization (ASO) MoU , Retrieved 27 May 2010.<br>>><br>>> 3. <a href="http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm" target="_blank">http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm</a><br>>> Global Policy for the Allocation of the Remaining IPv4 Address Space<br>>><br>>> 4. <a href="http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf" target="_blank">http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf</a> Policy<br>>>

 for Allocation of IPv4 Blocks to Regional Internet Registries<br>>> _______________________________________________<br>>> rpd mailing list<br>>> <a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br>>> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>>><br>>><br>><br>> --<br>> ______________________________________________________________________<br>> Mukom Akong T.<br>> www.afrinic.net | p: +230 466 6616   |   f: +230 466 6758    | Skype: perfexcellent<br>><br>> _______________________________________________<br>> rpd mailing list<br>> <a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br>> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd"

 target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>><br>_______________________________________________<br>rpd mailing list<br><a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br></div></blockquote></td></tr></table><br>