<div dir="ltr">+1 to what MCTim, Owen, and Vaughn said.<div><br></div><div>In general I oppose transfers with no need.</div><div><br></div><div><div>If there are "networks in need of additional IPv4 addresses", surely they should be able to show this, in accord with long standing practice. </div><div><br></div><div>I'd rather us not move to a situation which enables/encourages speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution.</div></div><div><br></div><div>I'd also rather not encourage one competitor in a business segment to be able to better stockpile addresses and for that to become a competitive advantage</div><div>against other providers in the space. Additionally if this is done in a wide enough scale it can sufficiently lengthen wide spread IPv6 adoption.</div><div><br></div><div>This policy would also allow for companies with the deepest pockets and the most profitable services to concentrate IPv4 space. I'm not sure that is more "fair" </div><div>than the pre-existing framework for "fair".</div><div><br></div><div>__Jason</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems <span dir="ltr"><<a href="mailto:vaughn@swiftsystems.com" target="_blank">vaughn@swiftsystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>+1<br><br>Sent from my mobile device, please forgive brevity and typos. </div><div><div class="h5"><div><br>On Feb 18, 2016, at 2:16 PM, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>> wrote:<br><br></div><blockquote type="cite"><div>+1 — McTim said it very well.<div><br></div><div>Owen</div><div><br></div><div><div><blockquote type="cite"><div>On Feb 18, 2016, at 10:34 , McTim <<a href="mailto:dogwallah@gmail.com" target="_blank">dogwallah@gmail.com</a>> wrote:</div><br><div><div dir="ltr">I am opposed. <div><br></div><div>If there are "<span style="font-size:12.8px">networks in need of additional IPv4 addresses", surely they should be able to show this, in accord with long standing practice. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I'd rather us not move to a situation which enables/encourages speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Regards,</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">McTim</span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer <span dir="ltr"><<a href="mailto:lsawyer@gci.com" target="_blank">lsawyer@gci.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good afternoon -<br>
<br>
Based on feedback from Montreal as well as internal discussions, I've reworked this policy.<br>
AC members and ARIN staff are looking for additional feedback, as well as your position in terms<br>
of supporting or opposing this draft policy.<br>
<br>
We'll be discussing this policy, as well as any feedback provided on this week's AC teleconference,<br>
so I'm very appreciative of your input.<br>
<br>
Thanks,<br>
<br>
Leif Sawyer<br>
Shepherd - ARIN-2015-9<br>
<br>
NRPM section 8: <a href="https://www.arin.net/policy/nrpm.html#eight" rel="noreferrer" target="_blank">https://www.arin.net/policy/nrpm.html#eight</a><br>
<br>
Most current draft policy text follows:<br>
--<br>
<br>
Draft Policy ARIN-2015-9<br>
Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks<br>
Original Date: 23 September 2015<br>
Updated: 16 February, 2016<br>
<br>
Problem statement:<br>
The current needs-based evaluation language in NRPM sections 8.2 and 8.3, regarding transfer of IPv4<br>
netblocks from one organization to another, may cause a recipient organization to bypass the ARIN<br>
registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the<br>
current holder. The result is that the data visible in ARIN registry may become more inaccurate over<br>
time.<br>
<br>
Policy statement:<br>
This proposal eliminates all needs-based evaluation language for sections 8.2 and 8.3, allowing<br>
transfers to be reflected in the database as they occur following an agreement of transfer from the<br>
resource provider to the recipient.<br>
<br>
Section 8.1 Principles:<br>
- Strike the fragment from the 3rd paragraph which reads<br>
", based on justified need, "<br>
so the resulting text reads<br>
"Number resources are issued to organizations, not to individuals representing those organizations."<br>
Section 8.2 Mergers and Acquisitions:<br>
- Change the 4th bullet from:<br>
"The resources to be transferred will be subject to ARIN policies."<br>
to:<br>
"The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification."<br>
<br>
- Strike the final paragraph which begins "In the event that number resources of the combined organizations are no longer justified under ARIN policy ..."<br>
<br>
Section 8.3 Transfers between Specified Recipients within the ARIN Region:<br>
- Change the first bullet under "Conditions on recipient of the transfer" from:<br>
"The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA."<br>
to:<br>
"The recipient must sign an RSA."<br>
<br>
- Change the 2nd bullet under "Conditions on recipient of the transfer" from:<br>
"The resources to be transferred will be subject to ARIN policies."<br>
to:<br>
"The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification."<br>
<br>
Comments:<br>
a. Timetable for implementation: Immediate<br>
b. Anything else<br>
As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) have now been<br>
exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of<br>
receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders<br>
of IPv4 resources who are willing to transfer them in order to fulfill that need. Accordingly, the RIR's<br>
primary responsibility vis-à-vis IPv4 netblock governance has shifted from "allocation" to ensuring an<br>
accurate registry database.<br>
<br>
The RIPE registry can be used as a reference of one which has evolved over the past couple years to<br>
shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock<br>
transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer.<br>
Provided the organizations meet the basic requirement of RIR membership, and that the transferring<br>
organization has the valid authority to request the transfer, the transaction completes without any<br>
"needs-based" review.<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" target="_blank">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" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Cheers,<br><br>McTim<br>"A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel</div>
</div>
_______________________________________________<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" target="_blank">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" target="_blank">info@arin.net</a> if you experience any issues.</div></blockquote></div><br></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>PPML</span><br><span>You are receiving this message because you are subscribed to</span><br><span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).</span><br><span>Unsubscribe or manage your mailing list subscription at:</span><br><span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br><span>Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.</span></div></blockquote></div></div></div><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" rel="noreferrer" 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></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>