<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller <span dir="ltr"><<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I support the removal of the 30 day utilization as it is unreasonable for any larger end-site, who may have a real need for say a /16, with 65,000 desktops arriving on a loading doc next week, but an inability to unbox, configure and deploy 16,384 to the various office locations in 30 days. <div><br></div></div></blockquote><div><br></div><div>agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>However, this is the only provision that has a real, tangible, and verifiable claim. Without this check justified need for end users simply becomes a 1 year future looking projection, and with sufficient arm waving an easy end run around justified need for any end user with no IP space or if they are efficiently using what they currently hold. </div><div><br></div></div></blockquote><div><br></div><div>good point!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>I could get on board if the maximum sized block permitted on a purely future looking projection was a /24 and you had to use it prior to getting more.</div><div><br></div></div></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>I could certainly get on board if there were some other tangible and verifiable claim to show there was a real commitment to use half the address space within one year.</div><div><br></div></div></blockquote><div><br></div><div>Would this language suffice, or would we need a metric of some sort?</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div>McTim</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>__Jason</div><div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones <span dir="ltr"><<a href="mailto:bjones@vt.edu" target="_blank">bjones@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small">Looks good to me Dave. I am okay with using criteria or criterion, however using the strict definition it looks as though criterion is the proper singular form.</div></div><div class="gmail_extra"><br clear="all"><div><div>--<br>Brian</div></div><div><div>
<br><div class="gmail_quote">On Wed, Jan 27, 2016 at 5:54 PM, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The following is the proposed update for ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy based on strong support in Montreal.<br>
<br>
Beyond deleting the 25% bullet as the policy says, their are editorial changes as follows to the remaining text;<br>
<br>
- It looks weird to have single item bullet list, so merge the two remaining sentence fragments into a single sentence.<br>
- Change "are" to "is", since there is only one remaining criteria<br>
- Use of "criteria" as a singular is common usage, even though technically it's plural.<br>
- Resulting in "The basic criteria that must be met is a 50% utilization rate within one year."<br>
<br>
The remaining and resulting text for 4.3.3 is now included in the policy text, for editorial clarity. The original staff and legal suggested removing the RFC2050 reference and also pointed out that<br>
4.2.3.6 also has a 25% immediate use clause and a RFC2050 reference.<br>
<br>
Feedback in Montreal was that deleting the 25% immediate use was a nice bite-sized change, and we shouldn't try to do more than that with this change, so those changes are not included at this time.<br>
<br>
Any additional feedback or comments are appreciated.<br>
<br>
Thanks<br>
<br>
---------<br>
<br>
Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy<br>
<br>
Date: 27 January 2015<br>
<br>
Problem Statement:<br>
<br>
End-user policy is intended to provide end-users with a one year supply of IP addresses. Qualification for a one-year supply requires the network operator to utilize at least 25% of the requested addresses within 30 days. This text is unrealistic and should be removed.<br>
<br>
First, it often takes longer than 30 days to stage equipment and start actually using the addresses.<br>
<br>
Second, growth is often not that regimented; the forecast is to use X addresses over the course of a year, not to use 25% of X within 30 days.<br>
<br>
Third, this policy text applies to additional address space requests. It is incompatible with the requirements of other additional address space request justification which indicates that 80% utilization of existing space is sufficient to justify new space. If a block is at 80%, then often (almost always?) the remaining 80% will be used over the next 30 days and longer. Therefore the operator cannot honestly state they will use 25% of the ADDITIONAL space within 30 days of receiving it; they're still trying to use their older block efficiently.<br>
<br>
Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give out /24 (or larger) blocks. So the justification for the 25% rule that previously existed (and in fact, applied for many years) is no longer germane.<br>
<br>
Policy statement:<br>
<br>
Remove the 25% utilization criteria bullet point from NRPM 4.3.3.<br>
<br>
Resulting text:<br>
<br>
4.3.3. Utilization rate<br>
<br>
Utilization rate of address space is a key factor in justifying a new<br>
assignment of IP address space. Requesters must show exactly how<br>
previous address assignments have been utilized and must provide<br>
appropriate details to verify their one-year growth projection.<br>
<br>
The basic criteria that must be met is a 50% utilization rate within one year.<br>
<br>
A greater utilization rate may be required based on individual network<br>
requirements. Please refer to RFC 2050 for more information on<br>
utilization guidelines.<br>
<br>
Comments:<br>
a.Timetable for implementation: Immediate<br>
b.Anything else<br>
<br>
-- <br>
================================================<br>
David Farmer Email: <a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a><br>
Office of Information Technology<br>
University of Minnesota<br>
2218 University Ave SE Phone: <a href="tel:1-612-626-0815" value="+16126260815" target="_blank">1-612-626-0815</a><br>
Minneapolis, MN 55414-3029 Cell: <a href="tel:1-612-812-9952" value="+16128129952" target="_blank">1-612-812-9952</a><br>
================================================<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" 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/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>
</blockquote></div><br></div></div></div>
<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" 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/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></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><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>|<a href="tel:571-266-0006" value="+15712660006" target="_blank">571-266-0006</a></font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</font></span></div></div></div>
<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" rel="noreferrer" 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.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Cheers,<br><br>McTim<br>"A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel</div>
</div></div>