<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:11.0pt;
font-family:"Calibri",sans-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:11.0pt;
font-family:"Calibri",sans-serif;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
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>I support the policy.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>What Jason misses below when he says “if they are willing to call themselves an ISP, and pay the <o:p></o:p></p><p class=MsoNormal>appropriate fees.”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>And<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>“for anyone who needs a /21 or less and is willing to pay an <o:p></o:p></p><p class=MsoNormal>extra $400 annually for up to a /22 or, and extra $900 annually for up to a /21.”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>is of course the far larger expense which is the actual purchase price of the addresses. At today’s rates, to go from a /24 to a /21 would cost almost $30k, or 30 years of fees!<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>That, in a nutshell, is why needs-tests are an irrelevance in terms of who gets addresses. The high-bidder always gets them. Virtually all buyers can all justify their needs, or in a pinch, register at RIPE or permanently lease the addresses and don’t tell the RIR(s). The ARIN needs-test is almost never a concern among buyers we talk to. The price of the addresses is ALWAYS a concern.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>What is wrong with “favoring services that generate the most revenue per IP” anyway? Whom should we “favor”?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It always bears repeating here that RIPE has no needs-tests for transfers and the most vital transfer market.<o:p></o:p></p><p class=MsoNormal>And that there are no indications of hoarding, speculation, or market manipulation in RIPE that I can discern. Fears of these potential problems have always been the reasons proffered for the continued requirement for a needs-test, but I never hear any voices who dispassionately regard the RIPE transfer market and then question their prior beliefs that these maladies would come to pass. I mean these are the same people, generally, who feel IPv6 is in the offing and growing closer. Will there never come a time that the coming of IPv6 will convince people that nobody will speculate on IPv4?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The needs-test is a completely irrelevant artifact from a prior era, and address pricing provides better conservation than any needs-test ever did. So anything we can do to remove this irrelevant burden from market participants is a step towards reducing uncertainty in the IPv4 transfer market and a step towards reconciliation with the other trading registries which have removed needs tests, as RIPE has and APNIC has done in the past before being pressured by ARIN to rescind.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Regards,<o:p></o:p></p><p class=MsoNormal>Mike<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>From:</b> ARIN-PPML [mailto:arin-ppml-bounces@arin.net] <b>On Behalf Of </b>Jason Schiller<br><b>Sent:</b> Wednesday, January 24, 2018 10:18 AM<br><b>To:</b> Owen DeLong <owen@delong.com><br><b>Cc:</b> ARIN-PPML List <arin-ppml@arin.net><br><b>Subject:</b> Re: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>I oppose. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>2016-4 was an attempt to replace the slow-start boot strap of get a /24 (or more) <o:p></o:p></p></div><div><p class=MsoNormal>from your upstream, put it into use, then use that to qualify to get your own IP space from ARIN.<o:p></o:p></p></div><div><p class=MsoNormal><br>The transfer slow-start boot strapping is to give the first /24 with no justification, <o:p></o:p></p></div><div><p class=MsoNormal>put it to use, then double (just as you did under slow start).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Essentially changing this to a /21 allows roughly 80% of ARIN members<o:p></o:p></p></div><div><p class=MsoNormal>to be able to get all the IPv4 address space they could even need with <o:p></o:p></p></div><div><p class=MsoNormal>no justification if they are willing to call themselves an ISP, and pay the <o:p></o:p></p></div><div><p class=MsoNormal>appropriate fees.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I oppose a non-needs based (or simply put a money based) justification<o:p></o:p></p></div><div><p class=MsoNormal>system on the grounds that does not provide IP addresses to those who need<o:p></o:p></p></div><div><p class=MsoNormal>them, but rather to those who are more willing to spend, favoring services that<o:p></o:p></p></div><div><p class=MsoNormal>generate the most revenue per IP. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I even more strongly oppose a non-needs based justification that only benifits<o:p></o:p></p></div><div><p class=MsoNormal>some small portion of the community. This proposal is essentially a non-needs<o:p></o:p></p></div><div><p class=MsoNormal>based justification for anyone who needs a /21 or less and is willing to pay an <o:p></o:p></p></div><div><p class=MsoNormal>extra $400 annually for up to a /22 or, and extra $900 annually for up to a /21.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Under NRPM version 2016.2 - 13 July 2016<o:p></o:p></p></div><div><p class=MsoNormal><a href="https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf" target="_blank">https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf</a><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>For an ISP request for ARIN IP space, 4.2.2.1.1 required them to <o:p></o:p></p></div><div><p class=MsoNormal>show utilization of currently held IPv4 space.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>1. They could use the utilization of their provider's /24 along with<o:p></o:p></p></div><div><p class=MsoNormal>the promise of renumbering to justify getting their own /24<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>An ISP could meet the 4.2.2.1.1 demonstration of utilization and<o:p></o:p></p></div><div><p class=MsoNormal>get additional space by showing the 3 month growth projection under<o:p></o:p></p></div><div><p class=MsoNormal>4.2.2.1.3.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>(replacing their provider supplied addressing can be<o:p></o:p></p></div><div><p class=MsoNormal>included in the ask if they promose to return under 4.2.2.1.4)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Or doubling under slow start 4.2.1.4.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>2016-4 came along to remove the need to get IPs from your upstream.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><a href="https://www.arin.net/policy/proposals/2016_4.html" target="_blank">https://www.arin.net/policy/proposals/2016_4.html</a><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>Replace Section 4.2.2 with:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>4.2.2. Initial allocation to ISPs<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>"All ISP organizations without direct assignments or allocations from ARIN <o:p></o:p></p></div><div><p class=MsoNormal>qualify for an initial allocation of up to a /21, subject to ARIN's <o:p></o:p></p></div><div><p class=MsoNormal>minimum allocation size. Organizations may qualify for a larger initial <o:p></o:p></p></div><div><p class=MsoNormal>allocation by documenting how the requested allocation will be utilized <o:p></o:p></p></div><div><p class=MsoNormal>within 24 months for specified transfers, or three months otherwise. <o:p></o:p></p></div><div><p class=MsoNormal>ISPs renumbering out of their previous address space will be given a <o:p></o:p></p></div><div><p class=MsoNormal>reasonable amount of time to do so, and any blocks they are returning <o:p></o:p></p></div><div><p class=MsoNormal>will not count against their utilization."<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal>At that time the difference between ARIN IP space was a 90 day supply<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>versus a two tear supply on the transfer market.<o:p></o:p></p></div><div><p class=MsoNormal>It also seemingly removed the following sections:<o:p></o:p></p></div><div><div><p class=MsoNormal>4.2.2.1. ISP Requirements<o:p></o:p></p></div><div><p class=MsoNormal>4.2.2.1.1. Use of /24<o:p></o:p></p></div><div><p class=MsoNormal>4.2.2.1.2. Efficient Utilization<o:p></o:p></p></div><div><p class=MsoNormal>4.2.2.1.3. Three Months<o:p></o:p></p></div><div><p class=MsoNormal>4.2.2.1.4. Renumber and Return <o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It was my impression that ARIN would not issue a /21 if it was more than a 90 day<o:p></o:p></p></div><div><p class=MsoNormal>supply. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>2016-2 came along and changes the time frame to sync pre-approval for transfers<o:p></o:p></p></div><div><p class=MsoNormal>and approval for the waiting list.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24.<o:p></o:p></p></div><div><p class=MsoNormal>and 4.2.4.3 to 24 months.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This is what creates the problem where now an initial ISP can request a /21<o:p></o:p></p></div><div><p class=MsoNormal>without requiring <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I do not believe the intent was to give ISPs a /21 even if it is larger than a, then <o:p></o:p></p></div><div><p class=MsoNormal>90 day, or now two year supply. I suggest that if more than a /24 is desired, they can get up <o:p></o:p></p></div><div><p class=MsoNormal>to a /21 if it is less than a 2 year supply, and subsequently need to show utilization. <o:p></o:p></p></div><div><p class=MsoNormal>That means a /21 is not entirely justification free like the /24 is.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>__Jason<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><p class=MsoNormal>Fully support the direction you are now taking this.<span class=hoenzb><span style='color:#888888'><o:p></o:p></span></span></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='color:#888888'>Owen<o:p></o:p></span></p></div><div><div><div><p class=MsoNormal><o:p> </o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On Jan 20, 2018, at 9:16 AM, David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficient and creates confusion; there appears to be support for eliminating the inconsistency. With slightly more support for changing section 8 to be consistent with section 4, rather than the other way around. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand <<a href="mailto:scottleibrand@gmail.com" target="_blank">scottleibrand@gmail.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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal>Quoting myself:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>If there are organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN) I’d like to understand what is burdensome, so we can figure out how to reduce that burden. If not, then implementing section 8 as written seems appropriate until we identify a reason to change it. <o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>Do you know of any organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)?<o:p></o:p></p><div id="m_-8450029862563572725m_-6545754943348527387AppleMailSignature"><div><p class=MsoNormal>Scott<o:p></o:p></p></div></div></div></blockquote></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><p class=MsoNormal>===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: <a href="tel:(612)%20626-0815" target="_blank">612-626-0815</a><br>Minneapolis, MN 55414-3029 Cell: <a href="tel:(612)%20812-9952" target="_blank">612-812-9952</a><br>=============================================== <o:p></o:p></p></div></div></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div><p class=MsoNormal><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></blockquote></div><p class=MsoNormal><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><div><p class=MsoNormal><span style='font-family:"Courier New";color:#555555'>_______________________________________________________</span><span style='font-family:"Arial",sans-serif;color:black'><o:p></o:p></span></p><div><p class=MsoNormal><span style='font-family:"Courier New";color:black'>Jason Schiller|NetOps|</span><a href="mailto:jschiller@google.com" target="_blank"><span style='font-family:"Courier New"'>jschiller@google.com</span></a><span style='font-family:"Courier New";color:black'>|571-266-0006</span><span style='font-family:"Arial",sans-serif;color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif;color:black'><o:p> </o:p></span></p></div></div></div></div></div></body></html>