<html><head><style type="text/css">body {word-wrap: break-word; background-color:#ffffff;}</style></head><body><div style="font-family: sans-serif; font-size: 16px">Pppp<br><br>Dylan Ebner, Network Engineer<br>Consulting Radiologists, Ltd.<br><a href="geo:0,0?q=1221+Nicollet+Mall%2C+Mpls%2C+MN+55403">1221 Nicollet Mall, Mpls, MN 55403</a><br>Ph. <a href="tel:6125732236">612-573-2236</a> Fax <a href="tel:6125732250">612-573-2250</a><br><a href="mailto:dylan.ebner@crlmed.com">dylan.ebner@crlmed.com</a><br><a href="http://www.consultingradiologists.com">www.consultingradiologists.com</a></div><br><br>-----Original message-----<br><blockquote style="; border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div style="font-family: sans-serif; font-size: 14px"><b>From: </b>David Farmer <farmer@umn.edu><b><br>To: </b>Bill Darte <BillD@cait.wustl.edu>, "arin-ppml@arin.net" <arin-ppml@arin.net><b><br>Sent: </b>Mon, Aug 30, 2010 21:30:22 GMT+00:00<b><br>Subject: </b>Re: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion<br><br></div><div><meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
<div>
<font size="2"><div class="PlainText">This isn't going to fly in APNIC. APNIC will not agree to the no <br>
transfer provision. Furthermore, as currently written it sets up a <br>
winner take all race to the bottom, a maximum allocation size would be <br>
an easy to fix this without making things to complicated.<br>
<br>
During the afternoon tea break on Friday, Owen and had a conversation <br>
with, Gaurab Raj Upadhaya (the new sig-policy chair for APNIC), Philip <br>
Smith, and Filiz Yilmaz (from RIPE), and Leslie stopped by for a bit <br>
too. Leslie did not comment on policy, but it was very helpful to have <br>
someone who had actually interacted with IANA involved in the conversation.<br>
<br>
The consensus of those gathered was that a very simple policy was <br>
needed, focusing on IANA. It should allow IANA to accept returns of /24 <br>
or large blocks. (no requirements for return by RIRs or anyone else for <br>
that matter). Then allow IANA to allocate on a needs basis to the RIRs <br>
with a minimum block size /24 and no more than the equilivant of a /10 <br>
at one time.<br>
<br>
The /10 at a time limit is intended to prevent a winner takes all race <br>
to the bottom and allow some possibility that a larger block could be <br>
shared between multiple RIRs without having addresses set idle if an RIR <br>
needs them.<br>
<br>
So my question to the rest of the AC, how should we proceed, keep text <br>
that we know will not succeed as global policy or change text? What <br>
would it take to make a radical change to the Draft Policy? Otherwise, <br>
we would need to come to the next meeting with new text which likely be <br>
past IANA run-out.<br>
<br>
Comments, rotten fruit, etc...<br>
<br>
<br>
On 8/30/10 09:59 CDT, Bill Darte wrote:<br>
> PPML Participants....<br>
><br>
> Below is the most current language for PP 2010-10. The language will be<br>
> 'frozen' September 24 for the upcoming Public Policy Meeting discussion<br>
> in Atlanta...Oct 6-8 <<a href="https://www.arin.net/participate/meetings/ARIN-XXVI/" target="_BLANK">https://www.arin.net/participate/meetings/ARIN-XXVI/</a>>.<br>
><br>
> As such, your opportunity to influence language or provide formal input<br>
> to the Advisory Council which may result in wording changes, must be<br>
> received by September 23. All previous comments and suggestions from the<br>
> PPML, private correspondence, converstations, etc. have been captured.<br>
> Input from the other RIR communities where this 'Global Policy' is being<br>
> considered will similarly be captured. Those inputs plus whatever we<br>
> receive between now and the Atlanta meeting will be brought to the<br>
> meeting for discussion.<br>
><br>
> Thanks for your participation in the ARIN Policy Development Process<br>
> <<a href="https://www.arin.net/policy/pdp.html" target="_BLANK">https://www.arin.net/policy/pdp.html</a>> and in this forum.<br>
><br>
> Bill Darte<br>
> ARIN Advisory Council<br>
> Primary Shepherd for PP 2010-10<br>
><br>
> ******* begin policy language *******<br>
><br>
> Global Policy for IPv4 Allocations by the IANA Post Exhaustion<br>
> Version/Date: 20 July 2010<br>
><br>
> Policy statement:<br>
><br>
> 1. Reclamation Pool<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>
> 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>
> 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 RIR's. Any remainder not evenly divisible by the number of<br>
> eligible RIR's 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 minumum<br>
> allocation unit is set to allow allocation from existing inventory.<br>
><br>
> 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool<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>
> 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.
</div></blockquote></body></html>