[arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion
farmer at umn.edu
Mon Aug 30 19:01:03 EDT 2010
I want to apologize to everyone on PPML. I'm still in Australia after
the APNIC meeting, helping out the world's tourist economy a little bit,
and broke the cardinal rule of not replying to email until after having
caffeine in the morning. This email was intended for the Advisory
Council email list. However, it accurately reflects my impression on
how things went for this policy at the meeting, and my best
recommendations on how this should more forward.
I have corrected my previous mistake and I am well caffeinated now, and
had some breakfast too. Again sorry for my sleep haze induced mistake.
On 8/30/10 16:29 CDT, David Farmer wrote:
> This isn't going to fly in APNIC. APNIC will not agree to the no
> transfer provision. Furthermore, as currently written it sets up a
> winner take all race to the bottom, a maximum allocation size would be
> an easy to fix this without making things to complicated.
> During the afternoon tea break on Friday, Owen and had a conversation
> with, Gaurab Raj Upadhaya (the new sig-policy chair for APNIC), Philip
> Smith, and Filiz Yilmaz (from RIPE), and Leslie stopped by for a bit
> too. Leslie did not comment on policy, but it was very helpful to have
> someone who had actually interacted with IANA involved in the conversation.
> The consensus of those gathered was that a very simple policy was
> needed, focusing on IANA. It should allow IANA to accept returns of /24
> or large blocks. (no requirements for return by RIRs or anyone else for
> that matter). Then allow IANA to allocate on a needs basis to the RIRs
> with a minimum block size /24 and no more than the equilivant of a /10
> at one time.
> The /10 at a time limit is intended to prevent a winner takes all race
> to the bottom and allow some possibility that a larger block could be
> shared between multiple RIRs without having addresses set idle if an RIR
> needs them.
> So my question to the rest of the AC, how should we proceed, keep text
> that we know will not succeed as global policy or change text? What
> would it take to make a radical change to the Draft Policy? Otherwise,
> we would need to come to the next meeting with new text which likely be
> past IANA run-out.
> Comments, rotten fruit, etc...
> On 8/30/10 09:59 CDT, Bill Darte wrote:
>> PPML Participants....
>> Below is the most current language for PP 2010-10. The language will be
>> 'frozen' September 24 for the upcoming Public Policy Meeting discussion
>> in Atlanta...Oct 6-8
>> As such, your opportunity to influence language or provide formal input
>> to the Advisory Council which may result in wording changes, must be
>> received by September 23. All previous comments and suggestions from the
>> PPML, private correspondence, converstations, etc. have been captured.
>> Input from the other RIR communities where this 'Global Policy' is being
>> considered will similarly be captured. Those inputs plus whatever we
>> receive between now and the Atlanta meeting will be brought to the
>> meeting for discussion.
>> Thanks for your participation in the ARIN Policy Development Process
>> <https://www.arin.net/policy/pdp.html> and in this forum.
>> Bill Darte
>> ARIN Advisory Council
>> Primary Shepherd for PP 2010-10
>> ******* begin policy language *******
>> Global Policy for IPv4 Allocations by the IANA Post Exhaustion
>> Version/Date: 20 July 2010
>> Policy statement:
>> 1. Reclamation Pool
>> Upon adoption of this IPv4 address policy by the ICANN Board of
>> Directors, the IANA shall establish a Reclamation Pool to be utilized
>> post RIR IPv4 exhaustion as defined in Section 4. The reclamation pool
>> will initially contain any fragments that may be left over in IANA
>> inventory. As soon as the first RIR exhausts its inventory of IP address
>> space, this Reclamation Pool will be declared active. When the
>> Reclamation Pool is declared active, the Global Policy for the
>> Allocation of the Remaining IPv4 Address Space and Policy for
>> Allocation of IPv4 Blocks to Regional Internet Registries will be
>> formally deprecated.
>> 2. Returning Address Space to the IANA
>> The IANA will accept into the Reclamation Pool all eligible IPv4 address
>> space that are offered for return. Eligible address space includes
>> addresses that are not designated as "special use" by an IETF RFC or
>> addresses allocated to RIR's unless they are being returned by the RIR
>> that they were orignally allocated to. Legacy address holders may return
>> address space directly to the IANA if they so choose.
>> 3. Address Allocations from the Reclamation Pool by the IANA
>> Allocations from the Reclamation Pool may begin once the pool is
>> declared active. Addresses in the Reclamation Pool will be allocated on
>> a CIDR boundary equal to or shorter than the longest minimum allocation
>> unit of all RIRs in order to complete these allocations.The Reclamation
>> Pool will be divided on CIDR boundaries and distributed evenly to all
>> eligible RIR's. Any remainder not evenly divisible by the number of
>> eligible RIR's based on a CIDR boundary equal to or shorter than the
>> longest minimum allocation unit of all RIRs will remain in the
>> Reclamation Pool. Addresses that are left over will be held in the
>> Reclamation Pool until additional IP addresses can be returned to rejoin
>> addresses on CIDR boundaries to the Reclamation Pool or a minumum
>> allocation unit is set to allow allocation from existing inventory.
>> 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool
>> Upon the exhaustion of an RIR's free space pool and after receiving
>> their final /8 from the IANA, an RIR will become eligible to request
>> address space from the IANA Reclamation Pool when it publicly announces
>> via its respective global announcements email list and by posting a
>> notice on its website that it has exhausted its supply of IPv4 address
>> space. Exhaustion is defined as an inventory of less than the equivalent
>> of a single /8 and the inability to further assign address space to its
>> customers in units equal to or shorter than the longest of any RIR's
>> policy defined minimum allocation unit. Any RIR that is formed after the
>> ICANN Board of Directors has ratified this policy is not eligible to
>> utilize this policy to obtain IPv4 address space from the IANA.
>> 5. Reporting Requirements
>> The IANA shall publish on at least a weekly basis a report that is
>> publicly available which at a minimum details all address space that has
>> been received and that has been allocated. The IANA shall publish a
>> Returned Address Space Report which indicates what resources were
>> returned, by whom and when. The IANA shall publish an Allocations Report
>> on at least a weekly basis which at a minimum indicates what IPv4
>> address space has been allocated, which RIR received the allocation and
>> when. The IANA shall publish a public notice confirming RIR eligibility
>> subsequent to Section 4.
>> 6. No Transfer Rights
>> Address space assigned from the Reclamation Pool may be transferred if
>> there is either an ICANN Board ratified global policy or globally
>> coordinated RIR policy specifically written to deal with transfers
>> whether inter-RIR or from one entity to another. Transfers must meet the
>> requirements of such a policy. In the absence of such a policy, no
>> transfers of any kind related to address space allocated or assigned
>> from the reclamation pool is allowed.
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> Please contact info at arin.net if you experience any issues.
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
More information about the ARIN-PPML