<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Hi Scott,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>OK, I understand how that can be relevant in concert with the lack of needs test for the minimum. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>So is there no needs test for the minimum?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Regards,<br>Mike<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Scott Leibrand [mailto:scottleibrand@gmail.com] <br><b>Sent:</b> Wednesday, June 22, 2016 12:16 PM<br><b>To:</b> Mike Burns <mike@iptrading.com><br><b>Cc:</b> Andrew Dul <andrew.dul@quark.net>; ARIN-PPML List <arin-ppml@arin.net><br><b>Subject:</b> Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns <<a href="mailto:mike@iptrading.com" target="_blank">mike@iptrading.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal>Hi Andrew,<br><br>I have a couple of questions about the policy proposal.<br><br> On Section 8.5.2 Operational Use.<br><br>First, why is this section even in there, does it serve some particular purpose?<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It prevents financial speculators, who have no operational use for the addresses, from acquiring them for speculative purposes.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal><br>Second, why does it refer to assignments and allocations in a section devoted to transfers?<br><br>Overall, do we still need the verbiage about "Specified" recipients, why not just recipients?<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>ARIN allocates or assigns blocks of IP addresses to organizations via transfer. An organization cannot receive a transfer directly: ARIN must update the registration of the allocation or assignment to reflect the specified recipient as the new holder. This simply reflects existing policy language and operational practice: nothing is changing here.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal><br>And lastly for now, does this mean that new buyers will automatically qualify for the minimum without any needs test?<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There is still a needs test, but it is now much simpler: recipients without any previous allocations or assignments (directly or via transfer) simply have to attest to the fact that the addresses are needed for use on an operational network. That is effectively the same as "without any needs test" for entities operating a network that will actually use the addresses, while completely locking out speculators who are unwilling to engage in fraud and risk losing the addresses they acquired.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-Scott<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal><br><br>My initial impression is positive.<br><br>Regards,<br>Mike<o:p></o:p></p><div><div><p class=MsoNormal><br><br><br><br><br><br><br>-----Original Message-----<br>From: <a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a> [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>] On Behalf Of Andrew Dul<br>Sent: Wednesday, June 22, 2016 11:46 AM<br>To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy<br><br>As the primary author of this draft policy, I respectfully disagree with my AC colleague.<br><br>Now that the free pool has been depleted, it is time to look toward what future IPv4 (primarily transfer) policy should do. While this policy looks complicated, its intention is to create a very simple transfer policy which allows businesses to predictably and efficiently transfer<br>IPv4 resources to meet their requirements.<br><br>I share with you here a redline which shows the changes that would be made to section 8.<br><br>Andrew<br><br>On 6/21/2016 9:16 AM, Owen DeLong wrote:<br>> I am opposed to this policy proposal.<br>><br>> Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process.<br>><br>> The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered.<br>><br>> If we want to change IPv4 policy, then let’s change IPv4 policy in section 4.<br>><br>> If we want to change transfer policy for all resources, we can do that cleanly in section 8.<br>><br>> While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse.<br>><br>> Owen<br>><br>>> On Jun 21, 2016, at 09:01 , ARIN <<a href="mailto:info@arin.net">info@arin.net</a>> wrote:<br>>><br>>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:<br>>><br>>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy<br>>><br>>> This Draft Policy has been numbered and titled:<br>>><br>>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer<br>>> Policy<br>>><br>>> Draft Policy ARIN-2016-5 is below and can be found at:<br>>> <a href="https://www.arin.net/policy/proposals/2016_5.html" target="_blank">https://www.arin.net/policy/proposals/2016_5.html</a><br>>><br>>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are:<br>>><br>>> > Enabling Fair and Impartial Number Resource Administration<br>>> > Technically Sound<br>>> > Supported by the Community<br>>><br>>> The PDP can be found at:<br>>> <a href="https://www.arin.net/policy/pdp.html" target="_blank">https://www.arin.net/policy/pdp.html</a><br>>><br>>> Draft Policies and Proposals under discussion can be found at:<br>>> <a href="https://www.arin.net/policy/proposals/index.html" target="_blank">https://www.arin.net/policy/proposals/index.html</a><br>>><br>>> Regards,<br>>><br>>> Communications and Member Services<br>>> American Registry for Internet Numbers (ARIN)<br>>><br>>> ##########<br>>><br>>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer<br>>> Policy<br>>><br>>> Date: 21 June 2016<br>>><br>>> Problem Statement<br>>><br>>> Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN's inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.<br>>><br>>> Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.<br>>><br>>> Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.<br>>><br>>> The goals of this rewrite are as follows:<br>>><br>>>> Separate the criteria that is found in section 4 of the NRPM from the transfer process.<br>>>> Provide a clear set of criteria that should be applied across all IPv4 transfers.<br>>>> Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.<br>>>> Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.<br>>> Policy statement:<br>>><br>>> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.<br>>><br>>> ######<br>>><br>>> 8.2. Mergers, Acquisitions, and Reorganizations<br>>><br>>> ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:<br>>><br>>>> The current registrant must not be involved in any dispute as to the status of the resources to be transferred.<br>>>> The new entity must sign an RSA covering all resources to be transferred.<br>>>> The resources to be transferred will be subject to ARIN policies.<br>>>> The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.<br>>>> For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.<br>>> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.<br>>><br>>> 8.3. Transfers between Specified Recipients within the ARIN Region<br>>><br>>> In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.<br>>><br>>> Conditions on source of the transfer:<br>>><br>>>> The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.<br>>>> The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.<br>>> Conditions on recipient of the transfer:<br>>><br>>>> The recipients must meet the transfer requirements as defined in section 8.5.<br>>>> The resources transferred will be subject to current ARIN policies.<br>>> 8.4. Inter-RIR Transfers to Specified Recipients<br>>><br>>> Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.<br>>><br>>> Conditions on source of the transfer:<br>>><br>>>> The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.<br>>>> Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.<br>>>> Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.<br>>> Conditions on recipient of the transfer:<br>>><br>>>> The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.<br>>>> Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.<br>>>> Recipients within the ARIN region will be subject to current ARIN policies.<br>>> 8.5. Specified Transfer Recipient Requirements<br>>><br>>> 8.5.1. Registration Services Agreement<br>>><br>>> Transfer recipients must sign an RSA for the resources being received.<br>>><br>>> 8.5.2. Operational Use<br>>><br>>> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.<br>>><br>>> 8.5.3. Minimum transfer size<br>>><br>>> ARIN's minimum transfer size is a /24.<br>>><br>>> 8.5.4. Initial block<br>>><br>>> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN's minimum transfer size.<br>>><br>>> 8.5.5. Block size<br>>><br>>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.<br>>><br>>> 8.5.6. Efficient utilization of previous blocks<br>>><br>>> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.<br>>><br>>> Comments:<br>>><br>>> Timetable for implementation: immediately<br>>><br>>> Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.<br>>> _______________________________________________<br>>> PPML<br>>> You are receiving this message because you are subscribed to the ARIN<br>>> Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>>> Unsubscribe or manage your mailing list subscription at:<br>>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>> _______________________________________________<br>> PPML<br>> You are receiving this message because you are subscribed to the ARIN<br>> Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>> Unsubscribe or manage your mailing list subscription at:<br>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br><br><br><br>_______________________________________________<br>PPML<br>You are receiving this message because you are subscribed to<br>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>Unsubscribe or manage your mailing list subscription at:<br><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<o:p></o:p></p></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>