<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 26, 2014 at 3:01 PM, John Springer <span dir="ltr"><<a href="mailto:springer@inlandnet.com" target="_blank">springer@inlandnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi John,<br>
<br>
Thank you for the clear statement of opposition. Please allow me to address the points you offer inline.<span class=""><br>
<br>
On Wed, 24 Dec 2014, John Santos wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Oppose 2014-14<br>
<br>
1) /16 is not "small"<br>
</blockquote>
<br></span>
This has actually been mentioned before, by several commentators. The problem with "big" and "not "small"" is that they require reference to a datum, which WRT to 2014-14 has not been provided. Owen Delong provided a fair attempt to come to grips with what big or small actually mean as percentages of the number and size of transfers that have occured since the STLS policy was adopted in 2009, here:<br></blockquote><div><br><br><br></div><div>Hi John,<br><br></div><div>I think it might help if we use the terms<br></div><div>XX-Small, X-Small, Small, etc. as defined<br>by ARIN themselves at<br> <a href="https://www.arin.net/fees/fee_schedule.html">https://www.arin.net/fees/fee_schedule.html</a><br><br></div><div>This might help eliminate confusion, and allow<br>for some flexibility going forward; if we instead<br>of hard-coding a specific size, instead tie it to<br>the fee schedule, and say "only entities that<br></div><div>currently fall into the "Small" and below category<br></div><div>of the ARIN fee schedule (ie cumulative /18 or<br>less of total IPv4 holdings as of the 2013 fee<br>schedule) may obtain a single transfer allocation<br>of size not to exceed the largest allowed for an<br>XX-Small organization (which, as of the 2013<br></div><div>fee schedule would mean a /22 or smaller)."<br><br></div><div>Or perhaps keep it supremely simple:<br></div><div>"Any org-ID may obtain one transfer allocation<br></div><div>of size not to exceed the largest allocation <br></div><div>within the XX-Small category (currently a /22,<br></div><div>as of the 2013 fee schedule) per year without<br></div><div>requiring needs justification."<br><br></div><div>That way, as our concept of ISP size shifts<br>and changes over time, so too does the<br></div><div>maximum needs-free allocation size.<br><br></div><div>[after writing the first paragraph, I realized<br></div><div>we probably don't need to limit who can<br>make use of this; the larger org-IDs aren't<br>going to bother messing around with xx-small<br>sized allocations, so it should be self-limiting.]<br><br></div><div>Thanks!<br><br>Matt<br></div></div></div></div>