<div dir="ltr"><div>David,</div><div><br></div>This policy was  proposed to make transfers easy, with predictable outcomes, for organizations that have used what they got and likely need more.  <div><br></div><div>This policy was not proposed to ration to those organizations with the most need, which is exactly what the up to a /16 every 6 months does.</div><div><br></div><div>I appreciate the need to prevent abuse, but want this policy to be able to be used by all organizations that are using what they have got, and will continue to do such.  For this reason I oppose the once every 6 months clause.</div><div><br></div><div><br></div><div>In a later thread I suggested demonstrate growth of IPv4 utilization of at least half of the amount of specified transfers since the previous transfer pre-authorization or approval.  Would that approach work for your scenario?  As long as your newly deployed specified transfer space was above 50% or you had some other growth somewhere else to off set under utilization (which may be associated with a renumbering event) then you should be fine.</div><div><br></div><div>If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?  </div><div><br></div><div>While I hate creating added complexity, I could get on board for an either or...  <br></div><div><br></div><div>-------</div><div><div>8.5.7 Alternative Additional IPv4 Address Block Criteria</div><div>In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.</div><div><br></div><div>An organization may only qualify under 8.5.7 once every 6 months, unless they can also demonstrate growth of IPv4 utilization of at least half of the amount of specified transfers since the previous transfer pre-authorization or approval.<br></div></div><div><br></div><div>OR if the community prefers</div><div><br></div><div>An organization may only qualify under 8.5.7 once every 6 months, unless they can also demonstrate at least 50% utilization of each allocation and assignment.<br></div><div>------</div><div><br></div><div>I think Owen prefers the former version, and maybe the former version does not penalized a requester for something unrelated to the intent of the anti-abuse text.  This approach would still meet your needs, not rate limit the organizations with the most need who want to use this policy, still provide benefits over the non-simplified approach of having a predictable outcome and not dependent on some assessment of the hand waviness of future looking predictions, and does not impact organizations that use this policy infrequently.)</div><div><br></div><div>___Jason</div><div>  </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 3, 2017 at 8:39 AM, David R Huberman <span dir="ltr"><<a href="mailto:daveid@panix.com" target="_blank">daveid@panix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What I dislike about the proposed addition of:<span class=""><br>
<br>
"- at least 50% utilization of each allocation and assignment"<br>
<br></span>
... is it gives ARIN staff no room to take into account individual topology.<br>
<br>
I may run a network at 95% utilization across all IP addresses.  But I may also have a pool of addresses in datacenter X that is under 50% utilized. Why am I being penalized for something unrelated to the intent of the anti-abuse text?<br>
<br>
I think I like the 2016-3 anti-abuse mechanism as-is. It is effective at stopping an abuse vector, and easy to implement across myriad topologies.<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<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/<wbr>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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="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>