<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 25, 2014, at 08:42 , <<a href="mailto:lar@mwtcorp.net">lar@mwtcorp.net</a>> <<a href="mailto:lar@mwtcorp.net">lar@mwtcorp.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Tue, 24 Jun 2014 15:04:17 -0700<br> Andrew Dul <<a href="mailto:andrew.dul@quark.net">andrew.dul@quark.net</a>> wrote:<br><blockquote type="cite">The problem described below appears to be more related to the current<br>3-month window for additional allocations, not necessarily the<br>utilization metric. The 3-month window has had a number of<br>side-effects, some of which were not anticipated when that policy was<br>put in place. With run-out in the region approaching rapidly we need to<br>turn our attention to the longer term policies which will support the<br>desires of the community (as best possible) through the transfer market<br>or other mechanisms. Changing the utilization formula (for those<br>requests which do require a formal needs assessment) may be part of the<br>policy changes which are needed.<br></blockquote>Some of the problem of the formula are long standing. If your last allocation<br>was a /22 and you have a larger customer come to you with a legitimate and<br>clear need for a /22 or /21 you have no way of getting it no matter what % utilization<br>is in the policy. It has always seemed to me, that "need" should have a lot more to<br>do with what you are going to do with the requested allocation, and what is available<br>in your current allocations, than some arbitrary utilization percentage. The<br>problem is that ARIN would then have to get into network design arguments.<br></blockquote><div><br></div><div>Actually, I believe that this circumstance is the reason that the immediate needs clause</div><div>exists.</div><div><br></div><div><div class="indent" style="margin: 0px; padding: 0px 0px 0px 3em; border: 0px; font-size: 10px; font-family: arial, helvetica, sans-serif; line-height: 16px; background-color: rgb(255, 255, 255); position: static; z-index: auto;"><h6 style="margin: 0.5em 0px; padding: 0px; border: 0px; background-color: transparent; font-size: 11.5px !important; background-position: initial initial; background-repeat: initial initial;">4.2.1.6. Immediate need</h6><div style="margin: 0.5em 0px; padding: 0px; border: 0px; font-size: 1.2em; line-height: 1.5em; background-color: transparent; background-position: initial initial; background-repeat: initial initial;">If an ISP has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional.</div><div><br></div></div></div><div>Perhaps, in practice, since it is located in principles (not sure how or why that occurred), and there isn't anything concrete stating that it should be treated as an exception to 4.2.4.1, it does not get implemented as I believe was intended. Staff would have to clarify that. If that is the case, it would be a relatively simple proposal to fix:</div><div><br></div><div>Amend section 4.2.4 by adding:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>4.2.4.5 Exceptional Cases of Immediate Need</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>If a subscriber member has a customer who needs a larger block than remains in the subscriber member's</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>free pool, then a request under section 4.2.1.6 shall apply as an exception to the requirements in 4.2.4.1.</div><div><br></div><blockquote type="cite">The argument that just removing the needs test for smaller allocations entirely<br>has some merit. The problem seems to be in defining what is small. A compromise of /20 has<br>been suggested and I think it's reasonable. Even though I support needs<br>testing I can support removing it at a /20 and smaller.<br></blockquote><div><br></div>I really think that removing the needs test is unlikely to gain consensus, even at the smaller point. There is clear resistance in the community to this idea and I expect that opposition will remain strong.</div><div><br></div><div>If people support the idea above, I'm happy to put it into a policy template and get it started in the process. If there is strong support, it can probably be moved through the process fairly quickly.</div><div><br></div><div>Owen</div><div><br><blockquote type="cite"><br>Larry Ash<br><br><blockquote type="cite">Andrew<br>On 6/24/2014 1:08 PM, Steven Ryerse wrote:<br><blockquote type="cite">This is the problem I'm trying to solve and why I've been so vocal about it. <br>Steven Ryerse<br>President<br>100 Ashford Center North, Suite 110, Atlanta, GA 30338<br>770.656.1460 - Cell<br>770.399.9099- Office<br><br>â„ Eclipse Networks, Inc.<br> Conquering Complex Networksâ„ <br><br><br>-----Original Message-----<br>From: <a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a> [<a href="mailto:arin-ppml-bounces@arin.net">mailto:arin-ppml-bounces@arin.net</a>] On Behalf Of Tim Gimmel<br>Sent: Tuesday, June 24, 2014 4:04 PM<br>To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a> List<br>Subject: Re: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17<br><br><br><blockquote type="cite">The problem is that the current process has disenfranchised smaller companies who are somewhat frequently requesting space under the 3 month need projection and are ending up with many /22's, /21's etc instead of the /20 or /19 that would have been possible prior to austerity measures.<br>To make matters worse, it does not seem that such companies are substantially represented on PPML so it is creating an illusion that the policy is not necessary or would not be supported by the community at large (outside of PPML).<br><br></blockquote>This is exactly what is happening, for example I have 4 /20's and a /19 from earlier days, but now I have 7 /21's and that is the most I will ever be able to request. We are using every possible way to keep IPv4 usage down.<br><br>--Tim<br><br></blockquote>_______________________________________________<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">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact info@arin.net if you experience any issues.<br></blockquote><br>Larry Ash<br>Network Administrator<br>Mountain West Telephone<br>123 W 1st St.<br>Casper, WY 82601<br>Office 307 233-8387<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">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact info@arin.net if you experience any issues.</blockquote></div><br></body></html>