<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Jason -
<div class=""> </div>
<div class=""> Your query below is with regard to ARIN allocations from the free pool, or with regard to approval of the transfer of IPv4 number resources?</div>
<div class=""><br class="">
</div>
<div class="">/John</div>
<div class=""> <br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 24 Jan 2018, at 8:06 AM, Jason Schiller <<a href="mailto:jschiller@google.com" class="">jschiller@google.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">ARIN staff, </div>
<div class=""><br class="">
</div>
<div class="">After the implementation of 2009-8 </div>
<div class="">and post IANA IPv4 depletion</div>
<div class="">(say 02/03/2011)</div>
<div class=""><br class="">
</div>
<div class="">If an ISP wanted more than a 90 day supply would </div>
<div class="">that have been limited to only a 90 day supply?</div>
<div class="">Is that because of both:</div>
<div class="">4.2.4.3. Subscriber Members Less Than One Year</div>
<div class="">4.2.4.4. Subscriber Members After One Year ?</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Does that also apply to an ISP asking for IP space</div>
<div class="">4.2.1.6. Immediate Need?</div>
<div class="">
<div class=""><br class="">
</div>
<div class="">Does that also apply to an ISP asking for IP space</div>
</div>
<div class="">4.2.1.4. Slow start?<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Does this also apply to ISP asking for IP space </div>
<div class="">under 4.2.2. Initial allocation to ISPs?</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">After the implementation of 2013-7<br class="">
</div>
<div class="">(say September 2014)</div>
<div class=""><br class="">
</div>
<div class="">Did any of this change?</div>
<div class=""><br class="">
</div>
<div class="">Did 4.2.4.3 Request size simply </div>
<div class="">replace 4.2.4.3 and 4.2.4.4 and </div>
<div class="">do essentially the same limit?</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">After the implementation of 2016-4</div>
<div class="">(say March 2017) </div>
</div>
<div class=""><br class="">
</div>
<div class="">Did any of this change?</div>
<div class="">
<div class="">Is that because of 4.2.4.3 Request size</div>
</div>
<div class="">still limits the maximum an ISP can get?</div>
<div class=""><br class="">
</div>
<div class="">Then after 2016-2</div>
<div class="">(say April 20, 2017) </div>
<div class=""><br class="">
</div>
<div class="">Would all of the above change to a 2 year supply?</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
Owen,
<div class=""><br class="">
<div class="">responses in line</div>
<div class=""><br class="">
</div>
<div class="">__Jason</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Wed, Jan 24, 2018 at 10:38 AM, Owen DeLong <span dir="ltr" class="">
<<a href="mailto:owen@delong.com" target="_blank" class="">owen@delong.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word" class="">While there’s some truth to that, it was also the reality under which we operated when that /21 was coming from the free pool rather than from the transfer market.
<div class=""><br class="">
</div>
<div class="">Admittedly, the price penalty was a bit higher because that was under an older fee structure which had higher prices for ISPs, but, as the old Churchill joke ends… “Madam, the first question established what you are, now we are merely haggling
over price.”</div>
<div class=""><br class="">
</div>
<div class="">So, given that, do you really believe we need to place additional limits on transfers that didn’t exist on the free pool?</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I don't believe this limit is new or additional... </div>
<div class="">My understanding of the policy that existed between 09/18/2012 and 04/20/2017 </div>
<div class="">was that an ISP could only get a 3 month supply of addresses.</div>
<div class=""><br class="">
</div>
<div class="">This was established under 2009-8 (01/13/2010 and triggered 02/03/2011)</div>
<div class="">and modified by 2016-2 (04/20/2017)</div>
<div class=""><br class="">
</div>
<div class=""><a href="https://www.arin.net/vault/announcements/2011/20110203.html" class="">https://www.arin.net/vault/announcements/2011/20110203.html</a><br class="">
</div>
<div class=""><a href="https://www.arin.net/resources/request/ipv4_countdown_plan.html" class="">https://www.arin.net/resources/request/ipv4_countdown_plan.html</a><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Post 04/20/2017, and ISP can only get a 2 year supply.</div>
<div class=""><br class="">
</div>
<div class="">I believe you need to show that the initial /21 you are asking for is a</div>
<div class="">90 day supply or less during the 09/2010-04/2012 time period, which</div>
<div class="">subsequently reverted to a two year window.</div>
<div class=""><br class="">
</div>
<div class="">Hopefully staff questions above will clarify this.</div>
<div class=""><br class="">
</div>
<div class="">At the very least it was never my expectation that passing 2016-4</div>
<div class="">would exclude the initial /21 from needing to meet the requirement </div>
<div class="">of 4.2.2.1.3. Three Months. </div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><br class="">
</div>
<div class="">Also, even with the /24 limit, under current policy, they can immediately turn around, claim they’ve used that /24 and with officer attestation get an additional /23, then turn around again and get an additional /22 which would leave them only
1 /24 short of a /21 (which they could turn around and immediately obtain unto an additional /21 under the same policy). So we essentially already allow this transaction, but the question is how many hoops do we want to add to the process.</div>
<div class=""><br class="">
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Assuming there is no fraud in the transaction you describe, then </div>
<div class="">they would essentially be doing slow start. </div>
<div class="">Get a block press it into service, show it is being used, and double.</div>
<div class=""><br class="">
</div>
<div class="">That is exactly how it is supposed to work. </div>
<div class="">That is exactly what we did under slow start with no history of use:<br class="">
1. get a /24 (or more up to a /21 from an upstream) show it is being used,</div>
<div class="">2. trade it out for ARIN space that replaces, and doubles the size</div>
<div class="">3. re number into the new space</div>
<div class="">4. press the unused new space into service</div>
<div class="">5. double you previous allocation if you do it in less than half the 90 day window</div>
<div class="">6. get the same size as your previous allocation if you do it in less that 90 days</div>
<div class="">7. fall back to a smaller next allocation if you do it in more than 90 days.</div>
<div class=""><br class="">
</div>
<div class="">The transfer version is more liberal in that it allows a straight doubling of all</div>
<div class="">your holdings as opposed to only your last allocation doubling, and there is</div>
<div class="">no time horizon, you can double even if it take you 3 years to press your </div>
<div class="">address space into service.</div>
<div class=""><br class="">
</div>
<div class="">So, less silly than slow start with a 1 year window, and much less silly than</div>
<div class="">slow start with a 3 month window.</div>
<div class=""> </div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""></div>
<div class="">I’m usually the one on the other side of this argument, but under the current circumstances, even I think it’s kind of silly.</div>
<span class="gmail-HOEnZb"><font color="#888888" class="">
<div class=""><br class="">
</div>
</font></span></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">What am I missing? What is so silly with this approach?</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word" class=""><span class="gmail-HOEnZb"><font color="#888888" class="">
<div class=""></div>
<div class="">Owen</div>
</font></span>
<div class="">
<div class="gmail-h5">
<div class=""><br class="">
</div>
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jan 24, 2018, at 7:17 AM, Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank" class="">jschiller@google.com</a>> wrote:</div>
<br class="gmail-m_-4929274636949792564Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">I oppose.
<div class=""><br class="">
</div>
<div class="">2016-4 was an attempt to replace the slow-start boot strap of get a /24 (or more) </div>
<div class="">from your upstream, put it into use, then use that to qualify to get your own IP space from ARIN.</div>
<div class=""><br class="">
The transfer slow-start boot strapping is to give the first /24 with no justification, </div>
<div class="">put it to use, then double (just as you did under slow start).</div>
<div class=""><br class="">
</div>
<div class="">Essentially changing this to a /21 allows roughly 80% of ARIN members</div>
<div class="">to be able to get all the IPv4 address space they could even need with </div>
<div class="">no justification if they are willing to call themselves an ISP, and pay the </div>
<div class="">appropriate fees.</div>
<div class=""><br class="">
</div>
<div class="">I oppose a non-needs based (or simply put a money based) justification</div>
<div class="">system on the grounds that does not provide IP addresses to those who need</div>
<div class="">them, but rather to those who are more willing to spend, favoring services that</div>
<div class="">generate the most revenue per IP. </div>
<div class=""><br class="">
</div>
<div class="">I even more strongly oppose a non-needs based justification that only benifits</div>
<div class="">some small portion of the community. This proposal is essentially a non-needs</div>
<div class="">based justification for anyone who needs a /21 or less and is willing to pay an </div>
<div class="">extra $400 annually for up to a /22 or, and extra $900 annually for up to a /21.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Under NRPM version 2016.2 - 13 July 2016</div>
<div class=""><a href="https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf" target="_blank" class="">https://www.arin.net/vault/pol<wbr class="">icy/archive/nrpm_20160713.pdf</a><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">For an ISP request for ARIN IP space, 4.2.2.1.1 required them to </div>
<div class="">show utilization of currently held IPv4 space.</div>
<div class=""><br class="">
</div>
<div class="">1. They could use the utilization of their provider's /24 along with</div>
<div class="">the promise of renumbering to justify getting their own /24<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">An ISP could meet the 4.2.2.1.1 demonstration of utilization and</div>
<div class="">get additional space by showing the 3 month growth projection under</div>
<div class="">4.2.2.1.3.</div>
<div class=""><br class="">
</div>
<div class="">(replacing their provider supplied addressing can be<br class="">
</div>
<div class="">included in the ask if they promose to return under 4.2.2.1.4)</div>
<div class=""><br class="">
</div>
<div class="">Or doubling under slow start 4.2.1.4.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">2016-4 came along to remove the need to get IPs from your upstream.</div>
<div class=""><br class="">
</div>
<div class=""><a href="https://www.arin.net/policy/proposals/2016_4.html" target="_blank" class="">https://www.arin.net/policy/pr<wbr class="">oposals/2016_4.html</a><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">Replace Section 4.2.2 with:</div>
<div class=""><br class="">
</div>
<div class="">4.2.2. Initial allocation to ISPs</div>
<div class=""><br class="">
</div>
<div class="">"All ISP organizations without direct assignments or allocations from ARIN </div>
<div class="">qualify for an initial allocation of up to a /21, subject to ARIN's </div>
<div class="">minimum allocation size. Organizations may qualify for a larger initial </div>
<div class="">allocation by documenting how the requested allocation will be utilized </div>
<div class="">within 24 months for specified transfers, or three months otherwise. </div>
<div class="">ISPs renumbering out of their previous address space will be given a </div>
<div class="">reasonable amount of time to do so, and any blocks they are returning </div>
<div class="">will not count against their utilization."</div>
<div class=""><br class="">
</div>
</div>
<div class="">At that time the difference between ARIN IP space was a 90 day supply</div>
<div class="">versus a two tear supply on the transfer market.<br class="">
<br class="">
</div>
<div class="">It also seemingly removed the following sections:</div>
<div class="">
<div class="">4.2.2.1. ISP Requirements</div>
<div class="">4.2.2.1.1. Use of /24</div>
<div class="">4.2.2.1.2. Efficient Utilization</div>
<div class="">4.2.2.1.3. Three Months</div>
<div class="">4.2.2.1.4. Renumber and Return </div>
</div>
<div class=""><br class="">
</div>
<div class="">It was my impression that ARIN would not issue a /21 if it was more than a 90 day</div>
<div class="">supply. </div>
<div class=""><br class="">
</div>
<div class="">2016-2 came along and changes the time frame to sync pre-approval for transfers</div>
<div class="">and approval for the waiting list.</div>
<div class=""><br class="">
</div>
<div class="">It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24.</div>
<div class="">and 4.2.4.3 to 24 months.</div>
<div class=""><br class="">
</div>
<div class="">This is what creates the problem where now an initial ISP can request a /21</div>
<div class="">without requiring </div>
<div class=""><br class="">
</div>
<div class="">I do not believe the intent was to give ISPs a /21 even if it is larger than a, then </div>
<div class="">90 day, or now two year supply. I suggest that if more than a /24 is desired, they can get up </div>
<div class="">to a /21 if it is less than a 2 year supply, and subsequently need to show utilization. </div>
<div class="">That means a /21 is not entirely justification free like the /24 is.</div>
<div class=""><br class="">
</div>
<div class="">__Jason</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""> </div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong <span dir="ltr" class="">
<<a href="mailto:owen@delong.com" target="_blank" class="">owen@delong.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word" class="">Fully support the direction you are now taking this.<span class="gmail-m_-4929274636949792564HOEnZb"><font color="#888888" class="">
<div class=""><br class="">
</div>
<div class="">Owen</div>
</font></span>
<div class="">
<div class="gmail-m_-4929274636949792564h5">
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jan 20, 2018, at 9:16 AM, David Farmer <<a href="mailto:farmer@umn.edu" target="_blank" class="">farmer@umn.edu</a>> wrote:</div>
<br class="gmail-m_-4929274636949792564m_-8450029862563572725Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficien<wbr class="">t 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.
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand <span dir="ltr" class="">
<<a href="mailto:scottleibrand@gmail.com" target="_blank" class="">scottleibrand@gmail.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto" class="">
<div class=""><span style="background-color:rgba(255,255,255,0)" class="">Quoting myself:</span></div>
<span style="background-color:rgba(255,255,255,0)" class="">
<div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class="">
</span></div>
<blockquote type="cite" class="">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. </blockquote>
</span>
<div class=""><br class="">
</div>
Do you know of any <span style="background-color:rgba(255,255,255,0)" class="">organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)?</span><br class="">
<br class="">
<div id="gmail-m_-4929274636949792564m_-8450029862563572725m_-6545754943348527387AppleMailSignature" class="">
<div class="">Scott</div>
</div>
</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
-- <br class="">
<div class="gmail-m_-4929274636949792564m_-8450029862563572725gmail_signature">==============================<wbr class="">=================<br class="">
David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank" class="">
Email:farmer@umn.edu</a><br class="">
Networking & Telecommunication Services<br class="">
Office of Information Technology<br class="">
University of Minnesota <br class="">
<a href="https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g" class="">2218 University Ave SE</a> Phone:
<a href="tel:(612)%20626-0815" value="+16126260815" target="_blank" class="">612-626-0815</a><br class="">
Minneapolis, MN 55414-3029 Cell: <a href="tel:(612)%20812-9952" value="+16128129952" target="_blank" class="">
612-812-9952</a><br class="">
==============================<wbr class="">================= </div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
<br class="">
______________________________<wbr class="">_________________<br class="">
PPML<br class="">
You are receiving this message because you are subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription at:<br class="">
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">http://lists.arin.net/mailman/<wbr class="">listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.<br class="">
</blockquote>
</div>
<br class="">
<br clear="all" class="">
<div class=""><br class="">
</div>
-- <br class="">
<div class="gmail-m_-4929274636949792564gmail_signature"><font color="#555555" face="'courier new', monospace" class="">
<div class=""><span style="font-family:arial" class=""><font color="#555555" face="'courier new', monospace" class="">______________________________<wbr class="">_________________________<br class="">
</font>
<div class=""><font face="'courier new', monospace" class="">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank" class="">jschiller@<wbr class="">google.com</a>|<a href="tel:(571)%20266-0006" value="+15712660006" target="_blank" class="">571-266-0006</a></font></div>
<div class=""><font face="'courier new', monospace" class=""><br class="">
</font></div>
</span></div>
</font></div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
<br clear="all" class="">
<div class=""><br class="">
</div>
-- <br class="">
<div class="gmail_signature"><font color="#555555" face="'courier new', monospace" class="">
<div class=""><span style="font-family: arial;" class=""><font color="#555555" face="'courier new', monospace" class="">_______________________________________________________<br class="">
</font>
<div class=""><font face="'courier new', monospace" class="">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank" class="">jschiller@google.com</a>|571-266-0006</font></div>
<div class=""><font face="'courier new', monospace" class=""><br class="">
</font></div>
</span></div>
</font></div>
</div>
</div>
</div>
_______________________________________________<br class="">
PPML<br class="">
You are receiving this message because you are subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription at:<br class="">
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
Please contact info@arin.net if you experience any issues.</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>