<div id="compose" contenteditable="true" aria-label="Message body" style="padding-left: 16px; padding-right: 16px; padding-bottom: 8px;"><div>Well put, David. +1</div><div><br><div class="acompli_signature">-Scott</div><br></div></div>
<div class="gmail_quote">_____________________________<br>From: David R Huberman <<a dir="ltr" href="mailto:daveid@panix.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="1">daveid@panix.com</a>><br>Sent: Saturday, May 14, 2016 5:08 PM<br>Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy<br>To: <<a dir="ltr" href="mailto:arin-ppml@arin.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">arin-ppml@arin.net</a>><br><br><br>Jason,<br><br>1) The policy in last call removes a criterion that is not being applied<br>today. Staff have criteria they use to judge 24-month need, and have been<br>applying it for years without coming back to us and telling us there's a<br>problem or deficiency.<br><br>2) Most requestors (99%? 98%?) tell the truth. They're just trying to<br>operate a network, and aren't attempting to defraud ARIN In any way. ARIN<br>staff have been fighting scammers for a very long time, and are very good<br>at it. They have measurable positive results in fighting fraud.<br><br>For those two reasons, I believe this policy should be adopted by the<br>board, and an obsolete criterion should be removed from NRPM.<br><br>David<br><br><br>> I seem to have missed the this thread in last call, and hope you<br>> will consider the discussion on the other thread: " Re: [arin-ppml]<br>> ARIN-2015-3:(remove 30-day...) Staff interpretation needed"<br>><br>> I maintain that the 30-day [60-day for transfers] check has<br>> been useful in mitigating abusively large requests, and<br>> without it there is no teeth in the policy to prevent abuse.<br>><br>><br>> I asked if I was wrong about this, please explain what<br>> mechanisms are in place to mitigate an end-user asking for<br>> approval for a 10 year supply of addresses on the grounds that<br>> if things go really really well, it will only be a 2 year supply?<br>><br>> I heard no response to indicate there was any mechanism.<br>><br>><br>> I asked staff about information about stats that might help<br>> determine what level of push back ARIN provides against two<br>> year projected need in general, and if that push back would be<br>> sufficient to prevent outlandishly large claims.<br>><br>> We found that 50% - 75% of all requests are approved with<br>> past utilization more heavily weighed.<br>><br>> It remains unclear what level of oversight ARIN has to<br>> question future looking projections. John Curran provided<br>> some text about approvals of future looking projections.<br>><br>> "When we [ARIN] ask organization for their forward<br>> projections, we [ARIN] also ask them to provide details<br>> to show how they've arrived at their projections. We [ARIN]<br>> take into account factors such as new networks, locations,<br>> products, services they plan on offering (and this includes<br>> consideration of anticipated address utilization within the<br>> first 30 days for end-users.)<br>><br>>>From the text John provided it seems one could get IP<br>> addresses solely on future looking plans which are<br>> unverifiable. As such an end-user could easily get a 10<br>> year supply of addresses simply by providing very<br>> optimistic deployment plans for the next 24 months.<br>><br>><br>><br>> I asked if I was not wrong about this, then did people realize<br>> that this policy is basically an end-run around giving out<br>> addresses based on need when they voted to move this<br>> policy forward?<br>><br>> I heard no response to this.<br>><br>> Thanks,<br>><br>> __Jason<br>><br>><br>> On Thu, May 5, 2016 at 11:45 AM, David Farmer <<a dir="ltr" href="mailto:farmer@umn.edu" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="6">farmer@umn.edu</a>> wrote:<br>><br>>> As shepherd for this policy I welcome any additional last call<br>>> feedback for this policy. It is especially important to speak up if<br>>> you feel there are any issues remaining that need to be considered.<br>>> But, even if you simply support the policy as written that is<br>>> important and useful feedback as well.<br>>><br>>> The last call period formally continues through, Monday, May 9th, and<br>>> the AC will consider the feedback during its scheduled call on<br>>> Thursday, May 19th.<br>>><br>>> Thanks<br>>><br>>> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <<a dir="ltr" href="mailto:info@arin.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="10">info@arin.net</a>> wrote:<br>>> > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to<br>>> > send the following to last call:<br>>> ><br>>> > Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization<br>>> > requirement in end-user IPv4 policy<br>>> ><br>>> > Feedback is encouraged during the last call period. All comments<br>>> should<br>>> > be provided to the Public Policy Mailing List. This last call will<br>>> > expire on 9 May 2016. After last call the AC will conduct their<br>>> > last call review.<br>>> ><br>>> > The draft policy text is below and available at:<br>>> > <a dir="ltr" href="https://www.arin.net/policy/proposals/" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="13">https://www.arin.net/policy/proposals/</a><br>>> ><br>>> > The ARIN Policy Development Process is available at:<br>>> > <a dir="ltr" href="https://www.arin.net/policy/pdp.html" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="14">https://www.arin.net/policy/pdp.html</a><br>>> ><br>>> > Regards,<br>>> ><br>>> > Communications and Member Services<br>>> > American Registry for Internet Numbers (ARIN)<br>>> ><br>>> ><br>>> > ## * ##<br>>> ><br>>> ><br>>> > Recommended Draft Policy ARIN-2015-3<br>>> > Remove 30 day utilization requirement in end-user IPv4 policy<br>>> ><br>>> > AC's assessment of conformance with the Principles of Internet Number<br>>> > Resource Policy:<br>>> ><br>>> > ARIN 2015-3 contributes to fair and impartial number resource<br>>> administration<br>>> > by removing from the NRPM text that is operationally unrealistic for<br>>> the<br>>> > reasons discussed in the problem statement. This proposal is<br>>> technically<br>>> > sound, in that the removal of the text will more closely align with<br>>> the<br>>> way<br>>> > staff applies the existing policy in relation to 8.3 transfers. There<br>>> was<br>>> > strong community support for the policy on PPML and at ARIN 36, which<br>>> was<br>>> > confirmed at ARIN 37. There was a suggestion to replace this text with<br>>> an<br>>> > alternate requirement. However, the community consensus was to move<br>>> forward<br>>> > with the removal alone.<br>>> ><br>>> > The staff and legal review also suggested removing RFC2050 references<br>>> and<br>>> > pointed out that 4.2.3.6 has an additional 25% immediate use clause,<br>>> > community feedback was to deal with those issues separately.<br>>> ><br>>> > Problem Statement:<br>>> ><br>>> > End-user policy is intended to provide end-users with a one year<br>>> supply<br>>> of<br>>> > IP addresses. Qualification for a one-year supply requires the network<br>>> > operator to utilize at least 25% of the requested addresses within 30<br>>> days.<br>>> > This text is unrealistic and should be removed.<br>>> ><br>>> > First, it often takes longer than 30 days to stage equipment and start<br>>> > actually using the addresses.<br>>> ><br>>> > Second, growth is often not that regimented; the forecast is to use X<br>>> > addresses over the course of a year, not to use 25% of X within 30<br>>> days.<br>>> ><br>>> > Third, this policy text applies to additional address space requests.<br>>> It<br>>> is<br>>> > incompatible with the requirements of other additional address space<br>>> request<br>>> > justification which indicates that 80% utilization of existing space<br>>> is<br>>> > sufficient to justify new space. If a block is at 80%, then often<br>>> (almost<br>>> > always?) the remaining 80% will be used over the next 30 days and<br>>> longer.<br>>> > Therefore the operator cannot honestly state they will use 25% of the<br>>> > ADDITIONAL space within 30 days of receiving it; they're still trying<br>>> to<br>>> use<br>>> > their older block efficiently.<br>>> ><br>>> > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not<br>>> give<br>>> > out /24 (or larger) blocks. So the justification for the 25% rule that<br>>> > previously existed (and in fact, applied for many years) is no longer<br>>> > 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<br>>> > address assignments have been utilized and must provide appropriate<br>>> details<br>>> > to verify their one-year growth projection.<br>>> ><br>>> > The basic criterion that must be met is a 50% utilization rate within<br>>> one<br>>> > 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<br>>> > guidelines.<br>>> ><br>>> > Comments:<br>>> ><br>>> > a.Timetable for implementation: Immediate<br>>> ><br>>> > b.Anything else<br>>> ><br>>> > #####<br>>> ><br>>> > ARIN STAFF ASSESSMENT<br>>> ><br>>> > Draft Policy ARIN-2015-3<br>>> > Remove 30 day utilization requirement in end-user IPv4 policy<br>>> > Date of Assessment: 16 February 2016<br>>> ><br>>> > ___<br>>> > 1. Summary (Staff Understanding)<br>>> ><br>>> > This proposal would remove the 25% utilization (within 30 days of<br>>> issuance)<br>>> > criteria bullet point from NRPM 4.3.3.<br>>> ><br>>> > ___<br>>> > 2. Comments<br>>> ><br>>> > A. ARIN Staff Comments<br>>> > This policy would more closely align with the way staff applies the<br>>> existing<br>>> > policy in relation to 8.3 transfers. Because there is no longer an<br>>> IPv4<br>>> free<br>>> > pool and many IPv4 requests are likely to be satisfied by 8.3<br>>> transfers,<br>>> the<br>>> > adoption of this policy should have no major impact on operations and<br>>> could<br>>> > be implemented as written.<br>>> ><br>>> > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to<br>>> obsolete<br>>> > RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use<br>>> (within<br>>> 30<br>>> > days of issuance) requirement.<br>>> ><br>>> > Staff suggests removing the first two sentences of 4.2.3.6 to remove<br>>> the<br>>> > references to RFC 2050 and the 25% requirement. Additionally, staff<br>>> suggests<br>>> > removing the reference to the obsolete RFC 2050 in section 4.3.3.<br>>> ><br>>> > B. ARIN General Counsel â Legal Assessment<br>>> > No material legal risk in this policy.<br>>> ><br>>> > ___<br>>> > 3. Resource Impact<br>>> ><br>>> > This policy would have minimal resource impact from an implementation<br>>> > aspect. It is estimated that implementation would occur immediately<br>>> after<br>>> > ratification by the ARIN Board of Trustees. The following would be<br>>> needed in<br>>> > order to implement:<br>>> > * Updated guidelines and internal procedures<br>>> > * Staff training<br>>> > _______________________________________________<br>>> > PPML<br>>> > You are receiving this message because you are subscribed to<br>>> > the ARIN Public Policy Mailing List (<a dir="ltr" href="mailto:ARIN-PPML@arin.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="23">ARIN-PPML@arin.net</a>).<br>>> > Unsubscribe or manage your mailing list subscription at:<br>>> > <a dir="ltr" href="http://lists.arin.net/mailman/listinfo/arin-ppml" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="24">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>>> > Please contact <a dir="ltr" href="mailto:info@arin.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="25">info@arin.net</a> if you experience any issues.<br>>><br>>><br>>><br>>> --<br>>> ===============================================<br>>> David Farmer Email:<a dir="ltr" href="mailto:farmer@umn.edu" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="26">farmer@umn.edu</a><br>>> Networking & Telecommunication Services<br>>> Office of Information Technology<br>>> University of Minnesota<br>>> <a dir="ltr" href="x-apple-data-detectors://27" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="27">2218 University Ave SE</a> Phone: <a dir="ltr" href="tel:612-626-0815" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="28/0">612-626-0815</a><br>>> <a dir="ltr" href="x-apple-data-detectors://28/1" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="28/1">Minneapolis, MN 55414-3029</a> Cell: <a dir="ltr" href="tel:612-812-9952" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="28/2">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 dir="ltr" href="mailto:ARIN-PPML@arin.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="29">ARIN-PPML@arin.net</a>).<br>>> Unsubscribe or manage your mailing list subscription at:<br>>> <a dir="ltr" href="http://lists.arin.net/mailman/listinfo/arin-ppml" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="30">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>>> Please contact <a dir="ltr" href="mailto:info@arin.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="31">info@arin.net</a> if you experience any issues.<br>>><br>><br>><br>><br>> --<br>> _______________________________________________________<br>> Jason Schiller|NetOps|<a dir="ltr" href="mailto:jschiller@google.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="32">jschiller@google.com</a>|<a dir="ltr" href="tel:571-266-0006" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="33">571-266-0006</a><br>> _______________________________________________<br>> PPML<br>> You are receiving this message because you are subscribed to<br>> the ARIN Public Policy Mailing List (<a dir="ltr" href="mailto:ARIN-PPML@arin.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="34">ARIN-PPML@arin.net</a>).<br>> Unsubscribe or manage your mailing list subscription at:<br>> <a dir="ltr" href="http://lists.arin.net/mailman/listinfo/arin-ppml" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="35">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>> Please contact <a dir="ltr" href="mailto:info@arin.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="36">info@arin.net</a> if you experience any issues.<br><br><br>_______________________________________________<br>PPML<br>You are receiving this message because you are subscribed to<br>the ARIN Public Policy Mailing List (<a dir="ltr" href="mailto:ARIN-PPML@arin.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="37">ARIN-PPML@arin.net</a>).<br>Unsubscribe or manage your mailing list subscription at:<br><a dir="ltr" href="http://lists.arin.net/mailman/listinfo/arin-ppml" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="38">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact <a dir="ltr" href="mailto:info@arin.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="39">info@arin.net</a> if you experience any issues.<br><br><br></div>