<div dir="ltr"><div class="gmail_extra">Tony,</div><div class="gmail_extra"><br></div><div class="gmail_extra">I am confused by your post.</div><div class="gmail_extra"><br></div><div class="gmail_extra">You state that "The point of "needs based" distribution is to preclude a<br>
run-on-the-bank-because-you-can" wrt the free pool.</div><div class="gmail_extra"><br></div><div class="gmail_extra">You then state that "One could go so far as to argue that "need" in an </div><div class="gmail_extra">
IPv4 market distribution model is less about conservation, and more </div><div class="gmail_extra">about precluding hoarding and speculative market manipulations, so </div><div class="gmail_extra">functionally "conservation" is a term that is OBE and applied only to the </div>
<div class="gmail_extra">IPv4 free-pool."</div><div class="gmail_extra"><br></div><div class="gmail_extra">Are you saying needs based prevents a run on the bank emptying of</div><div class="gmail_extra">the free pool, and needs based IPv4 transfer market helps prevent </div>
<div class="gmail_extra" style>hoarding and driving the price of address space up higher. These two</div><div class="gmail_extra" style>things are functionally equivalent, are needed, but cannot both be </div><div class="gmail_extra" style>
lumped under the term "conservation"? In other words this is a </div><div class="gmail_extra" style>semantics problem, but not an intent problem. </div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>I do hear your point about not being overly efficient on IPv6 allocations /</div><div class="gmail_extra" style>assignments. I feel the current draft policy covers that with some text like:</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>"<span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">Care must be taken to ensure balance with these conflicting goals given the </span></div>
<div class="gmail_extra" style><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">resource </span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">availability, relative size of the resource, and number resource specific </span></div>
<div class="gmail_extra" style><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">technical dynamics, for each type of number resource. For example, efficient </span></div>
<div class="gmail_extra" style><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">utilization becomes a more prominent issue than aggregation as the IPv4 free pool </span></div>
<div class="gmail_extra" style><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">depletes and IPv4 resource availability in any transfer market decreases. </span></div>
<div class="gmail_extra" style>
<span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">Conversely, because the IPv6 number space is orders of magnitude larger than </span></div><div class="gmail_extra" style>
<span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">the IPv4 number space, the scale tips away from efficient utilization towards </span></div><div class="gmail_extra" style>
<span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">hierarchical aggregation for IPv6 number resources."</span></div><div class="gmail_extra"><br></div><div class="gmail_extra" style>
And I believe the current ARIN policy also supports this approach for </div><div class="gmail_extra" style>more liberal IPv6 usage, and is consistent with this draft. </div><div class="gmail_extra"><br></div><div class="gmail_extra">
__Jason</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 10, 2013 at 3:26 PM, Tony Hain <span dir="ltr"><<a href="mailto:alh-ietf@tndh.net" target="_blank">alh-ietf@tndh.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
That said, translating 2050 principles into current & forward thinking RIR<br>
policy needs to happen. In that light "Stewardship" of public resources is<br>
the mission, not a policy point, as policies are applied to achieve the<br>
mission. The point of "needs based" distribution is to preclude a<br>
run-on-the-bank-because-you-can, but as I said earlier in an IPv6 context<br>
this has to avoid being so focused on 'conservation' that it precludes<br>
innovation. One could go so far as to argue that "need" in an IPv4 market<br>
distribution model is less about conservation, and more about precluding<br>
hoarding and speculative market manipulations, so functionally<br>
"conservation" is a term that is OBE and applied only to the IPv4 free-pool.<br>
If "efficient" still needs to be on the list as a measurement-metric /<br>
enforcement-stick, combine it with routability, and make it something like<br>
"routing efficiency within the deployed technology". This would allow a home<br>
/ SMB routing technology to be less "efficient" than a professional network<br>
engineer, as well as allow for new / different / non-hierarchal routing<br>
technologies to emerge over time. I would also argue that "uniqueness" is<br>
not an operating principle, as much as a means to achieve the principle of<br>
"public documentation". "Registration" as an RIR principle is circular and<br>
says the RIR's mission is simply to sustain itself.<br>
<span class=""><font color="#888888"><br>
Tony<br>
</font></span><div class="im"><br>
<br>
> -----Original Message-----<br>
> From: Milton L Mueller [mailto:<a href="mailto:mueller@syr.edu">mueller@syr.edu</a>]<br>
> Sent: Monday, June 10, 2013 10:25 AM<br>
> To: 'Tony Hain'; 'Chris Grundemann'; <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
> Subject: RE: [arin-ppml] ARIN-2013-4: RIR Principles / Request for General<br>
> Thoughts<br>
><br>
</div><div class=""><div class="h5">> Tony<br>
> These are very valuable and insightful comments. I would take issue only<br>
> with one part of your conclusion:<br>
><br>
> > While the survey is a great<br>
> > starting point, it might make more sense to have Arin hire a<br>
> > professional survey developer to create the questions for an "unbiased<br>
> > about the outcome" manner as possible.<br>
><br>
> While I am persuaded by your view that questions we are being asked are<br>
> suffused with IPv4-think, in many ways Chris's survey was an accurate<br>
> reflection of the content of 2013-4 itself, which is also suffused with<br>
IPv4-<br>
> think. It would not make sense I think to hire a professional survey<br>
> developer, when the problem we have is not so much the nature of Chris's<br>
> questions as it is the proposal we are working on. A professional survey<br>
> developer hired by ARIN could not (and should not) be developing a policy<br>
> proposal.<br>
><br>
> In short, Chris is fulfilling his role as AC shepherd and with the<br>
feedback from<br>
> this survey, and from good comments such as yours, the author of this<br>
> proposal should be able to go back to the drafting table and make some<br>
> substantial changes and improvements.<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">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" 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>
</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></div>