<div dir="ltr">Comments in line.<div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 5, 2016 at 11:30 AM, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Mon, Apr 25, 2016 at 11:47 AM, Jason Schiller <<a href="mailto:jschiller@google.com">jschiller@google.com</a>> wrote:<br>
...<br>
<span class="gmail-"><br>
> David, I hear a lot of people such as yourself, supposing that removal of<br>
> the 30 day need check will not change anything else. But I believe it makes<br>
> (pre-)approval for transfer solely based on the 2 year need projection,<br>
> which I am concerned could be wildly optimistic.<br>
<br>
</span>I'm not sure if this is directed at me or David Huberman, but I'll<br>
respond anyway.<br>
<br>
The staff assessment for ARIN-2015-3 says;<br>
This policy would more closely align with the way staff applies the<br>
existing policy<br>
in relation to 8.3 transfers. Because there is no longer an IPv4<br>
free pool and many<br>
IPv4 requests are likely to be satisfied by 8.3 transfers, the<br>
adoption of this policy<br>
should have no major impact on operations and could be implemented<br>
as written.<br>
<br>
I interpret this as saying the evaluation will be based on<br>
more-or-less the same criteria it is today just with no requirement to<br>
use 25% in 30 days, which you and everyone seems to support.<br></blockquote><div><br></div><div>yes, true, but... what does it mean to have the same criteria just with</div><div>no requirement to use 25% in 30 days?</div><div><br></div><div>8.3 references "demonstrating need" "under current policies"</div><div><br></div>"The recipient must demonstrate the need for up to a 24-month supply of IP </div><div class="gmail_quote">address resources under current ARIN policies and sign an RSA."<div><br></div><div>WRT ISPs "under current policy means" under 4.2.2 and 4.2.2.</div><div><br></div><div>which in short says roughly:</div><div>For ISP initial:</div><div>The ISP must already have at least a /24 from their provider, and</div><div>show that the space they are using is efficiently used. </div><div><br></div><div>They can then one for one swap their re-allocation for a direct </div><div>allocation from ARIN (gotten from ARIN or the transfer market).</div><div><br></div><div>If they want more IP space then what they are currently using, they </div>need to show 3 month [or 24 month for transfers] growth projections<br>"showing specifically how the requested allocation will be utilized" <div> </div>For additional ISP space:<br>They must show 80% utilization, with no blocks less than half full.<br>"Determination of the appropriate allocation to be issued is based on </div><div class="gmail_quote">efficient utilization of space within this time frame, consistent with the </div><div class="gmail_quote">principles in 4.2.1."</div><div class="gmail_quote"><br></div><div class="gmail_quote">4.2.1 includes slow start. So if the IP space you need in the next 3 months</div><div class="gmail_quote">[24 months for transfers] is more than what you used in the previous </div><div class="gmail_quote">3 months [24 months for transfers] you get slow started. That means,</div><div class="gmail_quote">you get double what you had the last 3 months [24 months for transfers],</div><div class="gmail_quote">you use it up, you show utilization, and double again so long as the most</div><div class="gmail_quote">recent space was utilized in less than 3 months [24 months for transfers]</div><div class="gmail_quote"><br></div><div class="gmail_quote">There is quite a lot of teeth in there to prevent abuse.</div><div class="gmail_quote"><br></div><div class="gmail_quote">WRT end-users "under current policy means" under 4.3.3 and 4.3.6.1</div><div class="gmail_quote"><br></div><div class="gmail_quote">For end-user initial:</div><div class="gmail_quote"><br></div>"Requesters must provide appropriate details to verify their one-year </div><div class="gmail_extra">growth projection. The basic criteria that must be met are:<br><br>- 25% immediate utilization rate, and<br>- 50% utilization rate within one year."<br>For end-user additional:<br>They must demonstrate 80% utilization on average, and no block less than <br>half full, and then use the same initial criteria. <br><br>There is no slow-start. The only thing that limits abuse is the threat that ARIN<br>might check for compliance with the requirement to use 25% in 30 days <br>[60 days for transfers]. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Without this check you are free to make any wildly optimistic plan that </div><div class="gmail_extra">supports a wildly optimistic growth projection and then in two years time</div><div class="gmail_extra">simply say "plans changed. We are still going to that, but over 10 years</div><div class="gmail_extra">instead." </div><div class="gmail_extra"><br></div><div class="gmail_extra">This easily becomes:</div><div class="gmail_extra">1. make a wildly optimistic plan, </div><div class="gmail_extra">2. officer attest to it, </div><div class="gmail_extra">3. end-run around need.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Which is nearly 2015-7 for end-users which is:</div><div class="gmail_extra">1. officer attest to the statement we think we might need X in the next 2 years</div><div class="gmail_extra">2. end-run around need.<br><div class="gmail_quote"><br></div><div class="gmail_quote">I maintain that the 30 day check has been useful in mitigating abusively large </div><div class="gmail_quote">requests, and without it there is no teeth in the policy to prevent abuse.</div><div class="gmail_quote"><br></div><div class="gmail_quote">If I am wrong about this, please explain what mechanisms are in place to mitigate</div><div class="gmail_quote">an end-user asking for approval for a 10 year supply of addresses on the grounds </div><div class="gmail_quote">that if things go really really well, it will only be a 2 year supply?</div><div class="gmail_quote"><br></div><div class="gmail_quote">If I am not wrong about this, then did people realize that this policy is basically an</div><div class="gmail_quote">end-run around giving out addresses based on need when they voted to move this</div><div class="gmail_quote">policy forward?</div><div class="gmail_quote"><br></div><div class="gmail_quote">___Jason</div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-"><br>
> I am not confusing it with 2015-7: Simplified requirements for demonstrated<br>
> need for IPv4 transfers. I believe 2015-7 would result in two changes, 1.<br>
> lowering the bar for ISP to match what end users need in 2015-3, and 2.<br>
> removing any demonstration of current utilization (and by extension<br>
> demonstration that you can and are properly managing the space you have) for<br>
> both ISPs and end users.<br>
><br>
> I can see where there could be some confusion as I have the same concern for<br>
> both proposals, that there needs to be some tangible verifiable claim.<br>
<br>
</span>Thanks for clarifying.<br>
<br>
...<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">--<br>
===============================================<br>
David Farmer <a href="mailto:Email%3Afarmer@umn.edu">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-626-0815" value="+16126260815">612-626-0815</a><br>
Minneapolis, MN 55414-3029 Cell: <a href="tel:612-812-9952" value="+16128129952">612-812-9952</a><br>
===============================================<br>
</div></div></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">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div></div>