
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 17, 2017, at 12:32 , Chris Woodfield <<a href="mailto:chris@semihuman.com" class="">chris@semihuman.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hello,</div><div class=""><br class=""></div><div class="">Reviving the thread on Draft Policy ARIN-2017-7. So far, the community response to the proposal in its current state appears to be universally negative. </div><div class=""><br class=""></div><div class="">Having read the comments on this proposal, it could be plausible that an alternate solution to the problem statement could be that in lieu of retiring most of the section, specific sections could be substantially simplified by pointing to the currently-duplicated clauses in Section 6, eliminating the need to manually keep these sections in sync by applying similar policy to both where warranted (in particular, the sections around utilization justification seem like the best candidates).</div></div></div></blockquote><div><br class=""></div>I think you mean section 8 as section 6 applies to IPv6 policy and would be absurd if applied to IPv4.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Does the community feel that this is a viable route to explore, which would simplify Section 4 while keeping the necessary relevant sections, in lieu of the original proposal?</div></div></div></blockquote><div><br class=""></div>Perhaps. Or perhaps we just abandon this proposal.</div><div><br class=""></div><div>Owen</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">-Chris</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 21, 2017, at 12:16 PM, Austin Murkland <<a href="mailto:austin.murkland@qscend.com" class="">austin.murkland@qscend.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I do not support this policy for the reasons Kevin and Albert outlined.  This seems a bit premature.<div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">Austin Murkland</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Jun 20, 2017 at 1:40 PM, ARIN <span dir="ltr" class=""><<a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 15 June 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-242: Retire Obsolete Section 4 From the NRPM" to Draft Policy status.<br class="">

<br class="">

Draft Policy ARIN-2017-7 is below and can be found at:<br class="">

<a href="https://www.arin.net/policy/proposals/2017_7.html" rel="noreferrer" target="_blank" class="">https://www.arin.net/policy/pr<wbr class="">oposals/2017_7.html</a><br class="">

<br class="">

You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are:<br class="">

<br class="">

* Enabling Fair and Impartial Number Resource Administration<br class="">

* Technically Sound<br class="">

* Supported by the Community<br class="">

<br class="">

The PDP can be found at:<br class="">

<a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank" class="">https://www.arin.net/policy/pd<wbr class="">p.html</a><br class="">

<br class="">

Draft Policies and Proposals under discussion can be found at:<br class="">

<a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank" class="">https://www.arin.net/policy/pr<wbr class="">oposals/index.html</a><br class="">

<br class="">

Regards,<br class="">

<br class="">

Sean Hopkins<br class="">

Policy Analyst<br class="">

American Registry for Internet Numbers (ARIN)<br class="">

<br class="">

<br class="">

<br class="">

Draft Policy ARIN-2017-7: Retire Obsolete Section 4 from the NRPM<br class="">

<br class="">

Problem Statement:<br class="">

<br class="">

Since IPv4 free pool exhaustion, policy focus has shifted to transfers. The community elected, instead of revamping and modernizing section 4 in light of this to, instead, recreate the relevant parts of section 4 in section 8.5. As a result, section 4 is generally obsolete and can be mostly retired. Since some small amounts of space do occasionally recreate the free pool, a mechanism for addressing this must remain and therefore a much reduced section 4 is proposed here instead of outright retirement.<br class="">

<br class="">

Policy statement:<br class="">

<br class="">

Replace section 4 of the NRPM with the following:<br class="">

<br class="">

4. IPv4<br class="">

<br class="">

4.1 IPv4 Requests<br class="">

<br class="">

4.1.1 Any new requests for IPv4 addresses allocated or assigned by ARIN shall be evaluated based on the criteria for transfer recipients contained in section 8.5.<br class="">

<br class="">

4.1.2 Any approved requests which cannot be met from the ARIN free pool shall be handled according to section 4.2.<br class="">

<br class="">

4.2 Unmet requests<br class="">

<br class="">

In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to specify the smallest block size they'd be willing to accept, equal to or larger than the applicable minimum size specified elsewhere in ARIN policy. If such a smaller block is available, ARIN will fulfill the request with the largest single block available that fulfills the request. If no such block is available, the organization will be provided the option to be placed on a waiting list of pre-qualified recipients, listing both the block size qualified for and the smallest block size acceptable.<br class="">

<br class="">

Repeated requests are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space.<br class="">

<br class="">

Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses.<br class="">

<br class="">

4.2.1. Waiting list<br class="">

<br class="">

The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time.<br class="">

<br class="">

4.2.2. Fulfilling unmet needs<br class="">

<br class="">

As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a timely re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list.<br class="">

<br class="">

Comments:<br class="">

<br class="">

a. Timetable for implementation: Immediate<br class="">

______________________________<wbr class="">_________________<br class="">

PPML<br class="">

You are receiving this message because you are subscribed to<br class="">

the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">

Unsubscribe or manage your mailing list subscription at:<br class="">

<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">http://lists.arin.net/mailman/<wbr class="">listinfo/arin-ppml</a><br class="">

Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.<br class="">

</blockquote></div><br class=""></div>

_______________________________________________<br class="">PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact <a href="mailto:info@arin.net" class="">info@arin.net</a> if you experience any issues.</div></blockquote></div><br class=""></div>_______________________________________________<br class="">PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.</div></blockquote></div><br class=""></body></html>