<div dir="ltr">John,<div><br></div><div style>Thank you for your careful consideration.</div><div style><br></div><div style>My intention certainly is not to undermine current NRPM policy or RSA text </div><div style>or change RIR operations. Ideally all of the things taken from RFC 2050 are</div>
<div style>high level principles, and are still as true today as they were then.</div><div style><br></div><div style>It seems things may not be that simple.</div><div style><br></div><div style>First let me say this is not my effort, but rather our effort, where our is both the </div>
<div style>community, the AC, and ARIN staff.</div><div style><br></div><div style>To that end, would it be unreasonable to ask for something different in the staff assessment?</div><div style><br></div><div style>Certainly a standard staff assessment should be done, but could staff also publish </div>
<div style>a separate assessment, of each of the snippets of the draft policy that would</div><div style>impact ARIN operations, how it would impact ARIN operations, and if there are other</div><div style>events (text) that have superseded this text.</div>
<div style><br></div><div style>The community will then have:</div><div style><br></div><div style>1. the original principle</div><div style>2. the history about the departure<br>3. the now current policy</div><div style>
4. how that might be changed if we reassert the principle in RFC 2050</div><div style><br></div><div style>The community can the first decide if the current policy / ARIN practice should remain</div><div style><br></div>
<div style>
Assuming it should remain, the community should judge if this is:</div><div style>A: Consistant with the original principle - should have no ARIN policy impact </div><div style>B: The original principle is still true, but need to be modified to support current policy</div>
<div style>C: Inconsistent with the original principle, but the original principle still holds true,<br></div><div style><div> current NRPM text should change, but resulting ARIN policy should be the same</div><div>
<div>
D: Inconsistent with the original principle, but the original principle still holds true,</div><div> current ARIN policy should change</div><div><div>E: Inconsistent with the original principle, but the original principle still holds true,</div>
<div> current ARIN policy is an artifact of other events but should not change</div><div style>F: Inconsistent with the original principle, and the community has concluded that it </div><div style> should depart from this original principle, as it is no longer valid.</div>
<div style><br></div><div style>For example wrt the text: </div><div style>"<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">IP addresses are </span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">valid as long as the criteria continues to be met"</span></div>
<div style>the community may decide that: </div><div style>- Yes this is a general principle that is still true</div><div style>- No we don't think it should mean ARIN should start reclaiming legacy space</div><div style>
that is under 80% utilized.</div><div style>- No we don't think this should challenge the current RSA</div><div style>- Yes we need some clarifying text asserting this</div><div style>Conclusion ARIN AC (working with the community should work on text asserting this)</div>
<div style><br></div><div style>For example wrt 0.1.1 text:</div><div style><br></div><div style>"<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Assignment of Internet number resources is based on documented operational need. </span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Utilization rate of address space will be a key factor in number resource assignment. </span></div><div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">T</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">o this end, registrants should have documented justified need available for each assignment. </span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Organizations will be assigned resources based on immediate utilization plus expected utilization."</span></div><div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>
</span></div><div style>The community might decide that:</div><div style>- Yes this is a general principle that is still true, IPs should be given on a needs basis<br></div><div style>- No we don't think ARIN should start giving out less IPv6 addresses, or make it harder to get</div>
<div style>- Yes this does conflict with IPv6 allocation / assignment policy which is currently not based on need</div><div style>- The conflicting IPv6 allocation / assignment policy should still be used by ARIN</div><div style>
- The community concludes IPv6 allocation / assignment policy should have always be based on need </div><div style>- The community should work to modify the NRPM to </div><div style> 1. Make IPv6 allocation / assignment policy based on need</div>
<div style> 2. point out the balance between aggregation and efficient utilization much more favors the former</div><div style> 3. ensure the needs based policy still results in the same allocation / assignment size</div>
<div><br></div><div></div></div><div></div></div></div><div style> </div><div style>If we proceed in this fashion, we can identify </div><div style>- the non-controversial (non-ARIN policy changing) text,</div><div style>
- the community can deal with each piece of text that might change ARIN policy, and decide at a high </div><div style>level to what extent the particular policy should impact ARIN policy</div><div style>- decide what sort of changes is needed to what (this draft, other NRPM text, RSA, ARIN policy, etc)</div>
<div style>- begin crafting those changes</div><div style><br></div><div style>My apologies to staff for the added work, but if done well, this will truly be something to be proud of.</div><div style><br></div><div style>
__Jason</div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 31, 2013 at 6:54 AM, John Curran <span dir="ltr"><<a href="mailto:jcurran@arin.net" target="_blank">jcurran@arin.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<div>On May 31, 2013, at 1:47 AM, Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>></div>
<div> wrote:</div>
<br><div class="im">
<blockquote type="cite">
<div dir="ltr">
<div>John,</div>
<div><br>
</div>
<div>Reading your respons brings to mind a general question.</div>
<div><br>
</div>
<div>You said "<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">the most likely </span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">change that would be anticipated </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">by insertation of that into ARIN </span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">policy would be ..."</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>
</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">In this and other cases the "that" is RFC-2050 text.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>
</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Shouldn't the text of RFC-2050 already impact ARIN policy?</span></div>
</div>
</blockquote>
<div><br>
</div>
</div><div>At the time of publication more than 15 years ago, RFC 2050 was a baseline </div>
<div>of operational guidelines for all of the regional registries, with each RIR free </div>
<div>to establish any additional guidelines as appropriate. Since that time, both</div>
<div>individual RIRs have evolved, as well as the entire structure of the Internet</div>
<div>Number Registry System. This is one of the key reasons why it was felt</div>
<div>that RFC2050 was long overdue to be refreshed, as many material issues</div>
<div>have changed since that time (e.g. Jon Postel no longer available as IANA,</div>
<div>formation of ICANN, introduction of additional RIRs, IPv6, etc.) RFC 2050</div>
<div>was operational guidelines from a single point in time, with it made clear</div>
<div>that the policies followed by an RIR could be supplemented with additional</div>
<div>policy and/or these global operational guidelines themselves could be </div>
<div>amended by the IANA to reflect changing requirements.</div>
<div><br>
</div>
<div>The reality is that the entire system has so extensively changed that each</div>
<div>RIR has its own adopted policy, has contractual relations with its members,</div>
<div>and we have a formal process with ICANN for adoption of global policy. There </div>
<div>is quite a bit in RFC 2050 operational guidelines which has been preempted </div>
<div>by these events, and hence the reason why the RFC2050bis effort has </div>
<div>focused on primarily describing the Internet Number Registry System, and </div>
<div>calling out those technical considerations from RFC 2050 which are inherent</div>
<div>to use of the the Internet Protocol and should be considered in establishing</div>
<div>registry policy.</div>
<div><br>
</div>
<div>I would say that the underlying concepts in RFC 2050 should indeed be</div>
<div>considered when setting ARIN registry policy, but how exactly that is done,</div>
<div>and how much weight is given to individual principles is very much up to this </div>
<div>community.</div><div class="im">
<div><br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">(Assuming no translational issues, out of context, etc) </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">why </span><span style="font-size:13.333333969116211px;font-family:arial,sans-serif">would the impact differ </span><span style="font-size:13.333333969116211px;font-family:arial,sans-serif">when
the text is in RFC-2050, </span></div>
<div><span style="font-size:13.333333969116211px;font-family:arial,sans-serif">or in </span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">the NRPM?</span></div>
</div>
</blockquote>
<div><br>
</div>
</div><div dir="ltr">
<div class="gmail_extra">See above. ARIN must follow NRPM in operation of the registry, whereas</div>
<div class="gmail_extra">RFC 2050 is a 15 year-old base set of operational guidelines and technical</div>
<div class="gmail_extra">principles for consideration in establishing registry policy for this region.</div>
<div class="gmail_extra"><br>
</div>
</div><div class="im">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"></div>
<div class="gmail_extra">(I'm not debating there is value in community being more clear</div>
<div class="gmail_extra">in outlining its expectations and impact on operations. I think </div>
<div class="gmail_extra">that point is true if this text is added to the NRPM and while this </div>
<div class="gmail_extra">text remains in RFC-2050.</div>
</div>
</blockquote>
<div><br>
</div>
</div><div>As there is language in RFC 2050 which is clearly obsoleted by events,</div>
<div>it is necessary for the community to discuss and determine what aspects</div>
<div>should be considered current and incorporated into ARIN registry policy.</div><div class="im">
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">We certainly can improve on the 2050 text, but I was trying to avoid</div>
<div class="gmail_extra">any updates that may be controversial, and was more interesting in</div>
<div class="gmail_extra">preserving the principles in 2050 in the first go around. )</div>
</div>
</blockquote>
</div><div dir="ltr">
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">A very admirable goal, but you are conflicted between the implied goals</div>
<div class="gmail_extra">of "avoiding updates" versus "producing something which is both current</div>
<div class="gmail_extra">and accurate." I'm not sure that the latter is achievable without quite a</div>
<div class="gmail_extra">bit of debate on what should be adopted.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Best wishes on your effort!</div><div class="im">
<div class="gmail_extra">/John</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">John Curran</div>
<div class="gmail_extra">President and CEO</div>
<div class="gmail_extra">ARIN</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><br>
</div>
</div></div>
</div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><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>