<div dir="ltr">Milton, Owen, John, Bill,<div><br></div><div>I'm not sure a discussion of merits of needs based allocation / assignment is useful </div><div>at this point in the discussion. </div><div><br></div><div>
Discussing what constitutes justified need, and how that has changed over time is</div><div>also not helpful at this point in the discussion.</div><div><br></div><div>Neither is it helpful to discuss alternate flavors of </div>
<div>conservation at this time.</div><div><div><br></div><div>What we need at this point is a high level discussion, about the general direction.</div><div>With that in mind I'd like to address these points:</div>
<div><br></div><div><div>MM> it seems obvious to me that a lot of the thinking that went into this 2013-4 </div><div>MM> is an attempt to rigidify obsolete thinking rather than to update things. This </div><div>MM> is a backwards-looking revision that has little support in the real world.</div>
<div>MM> It seems to me that the proposer of this policy thinks that fundamentally </div><div>MM> nothing has changed in 25 years.</div></div><div><br></div></div><div>The point of this policy is to preserve our principles of stewardship. Up until now,</div>
<div>the source of these principles has been RFC 2050. Many things reference it</div><div>and it's principles when considering stewardship.</div><div><br></div><div>If RFC 205bis passes, all of the stewardship language will be deprecated. </div>
<div><br></div><div>This policy attempts to take those principles and place them in the NRPM.</div><div><br></div><div>My attempt was not to be backwards looking, nor to revert current policy to </div>
<div>what it was in 1996. In theory these principles have and continue to guide</div><div>our policy making, and are still true, so we can simply copy them over.</div><div><br></div><div>I made a conscious effort minimize modernizing the policy and believe I </div>
<div>did so only where the language we use has clarified the principle and is </div><div>consistent with current ARIN policy and operations. The thought here </div><div>was to not change the status quo, and simply document what is the </div>
<div>already agreed upon basis of the current state of things.</div><div><br></div><div>The problem is that in some cases policy and practice has evolved </div><div>beyond the current RFC 2050 language, and based on some </div>
<div>interpretations conflicts with these principles. </div><div><br></div><div style>Should ARIN policy and operations be changed to match the principle?</div><div style>(Did we make a wrong term and abandon a principle we should not have?)</div>
<div style><br></div><div style>Should the principle be modified to make holes for the ARIN practice?</div><div style>(The principle is true, but it doesn't apply here due to this history) </div><div style><br></div>
<div style>Should the principle be documented as is, but ARIN to continue its practice</div><div style>unchanged? (this is what we have now with the current state of RFC 2050)</div><div> </div><div style>These questions can only be answered once the staff assessment is complete, </div>
<div style>and we understand to what extent this draft policy could influence current </div><div style>ARIN policy and operations.</div><div style><br></div><div style>Wait for the staff assessment, see how this policy could change things, then </div>
<div style>argue if these changes should or shouldn't happen, and how to modify this </div><div style>draft to support current ARIN policy and operations, or how to modify current</div><div style>ARIN policy and operations to support these principles, or let both stand in </div>
<div style>conflict and provide advice to ARIN to keep doing what it is doing.</div><div style><br></div><div>MM> <span style="font-family:arial,sans-serif;font-size:13.200000762939453px">> 0.4. Stewardship</span></div>
<font face="arial, sans-serif">MM> </font><span style="font-family:arial,sans-serif;font-size:13.200000762939453px">This section is also inappropriate for a principles document. It purports to </span><div><span style="font-family:arial,sans-serif;font-size:13.200000762939453px">MM> tell the current community, as well as all future deliberations for the next </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.200000762939453px">MM> 20-odd years, how to make policy tradeoffs. That is the kind of thing that </span></div><div><span style="font-family:arial,sans-serif;font-size:13.200000762939453px">MM> should be left to the community itself.</span><br>
<div><br></div></div><div style>The base principles have always had advice about this thing that that should be </div><div style>considered, and what the trade offs are. It has always been up to the community</div><div style>
to consider how to dial these knobs when crafting specific policy. This is not </div><div style>changing, except that the advice text will not be part of the PDP this community</div><div style>uses, so potentially easier to change than getting folks who attend IETF to </div>
<div style>whistle. <br><br></div><div style>__Jason</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 3, 2013 at 9:50 AM, Milton L Mueller <span dir="ltr"><<a href="mailto:mueller@syr.edu" target="_blank">mueller@syr.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would have to oppose most of the statements in this proposed revision of the RIR principles.<br>
While it is a good idea to update a document written literally a generation ago for a different IPv4 world, it seems obvious to me that a lot of the thinking that went into this 2013-4 is an attempt to rigidify obsolete thinking rather than to update things. This is a backwards-looking revision that has little support in the real world.<br>
It seems to me that the proposer of this policy thinks that fundamentally nothing has changed in 25 years.<br>
<br>
Here are some examples:<br>
<br>
> -----Original Message-----<br>
> Policy Statement:<br>
><br>
> Section 0: Principles and Goals of the Internet Registry System<br>
><br>
> 0.1. Efficient utilization based on need (Conservation)<br>
<br>
This represents confused thinking. Conservation as a principle does NOT necessarily mean needs-based allocation. There are many ways to conserve number resources without the fiction of technical needs assessment. For example, pricing or fees graduated to the number of addresses used is a form of conservation. Market trading, in which you bid a scarcity-based price for number blocks, is a form of conservation. Technical needs assessment as currently performed for IPv4 is another form of conservation, but it is arbitrary and often discriminates against specific technologies. I would not want to see this "update" used to rationalize obsolete methods of conservation.<br>
<br>
IPv6 allocations as I understand them are not actually based on demonstrated need in the same way as IPv4. Whatever your position on the needs assessment debate in IPv4, any "principle" regarding conservation should be formulated in a way that is FORWARD-LOOKING, flexible and leaves the door open for the community to change its definition of the best way to avoid wasting number resources. In a nutshell: efficiency and needs assessment are NOT equivalent. This draft clearly doesn't get that.<br>
<br>
> Policies for managing Internet number resources must support fair<br>
> distribution of globally unique Internet address space according to the<br>
> operational needs of the end-users and Internet Service Providers<br>
<br>
Again, "fairness" and "operational need" are distinct concepts. Operational need may justify giving all the available resources to a large provider, which some may find unfair. This statement is essentially meaningless in that it introduces to potentially conflicting standards.<br>
<br>
> operating networks using this address space. The registry should prevent<br>
> stockpiling in order to maximize the conservation and efficient<br>
> utilization of the Internet address space.<br>
<br>
I cannot ever support such an economically vague statement. It would authorize a huge expansion in the role of RIRs. "The registry should prevent stockpiling" means what exactly? What does "stockpiling" actually mean in an IPv6 world, anyway? If I use 1/1000th of a /48 assigned to me am I "stockpiling"? Is there any evidence that "stockpiling" is a problem? If so, where is this evidence?<br>
<br>
> 0.1.1. Documented Justified Need (Needs Based)<br>
<br>
This section attempts to codify and make permanent a set of policies that were developed in the final death throes of IPv4. What a waste of time.<br>
The idea of authorizing intrusive "accounting of resources" is precisely the opposite of the way we need to be going, both in IPv4 and IPv6. We should let the market allocate transfers of the fully-allocated IPv4 numbers, and current policies, which give organizations blocks based on the number of networks they claim and some fill ratio, for IPv6. There should be flexibility in the methods of conservation used. There is no need to specify concrete methods and practices in a principles document. That is just a mistake.<br>
<br>
> All Internet number resource requests are subject to audit and<br>
> verification by any means deemed appropriate by the regional registry.<br>
<br>
Reveals a scarcity mentality appropriate to the last decade.<br>
<br>
> 0.2. Hierarchical aggregation (Routability)<br>
<br>
I agree with the comments Bill Herrin made about this earlier. " Policies for managing Internet number resources must facilitate scalable routing." Scalability is what we care about, not necessarily hierarchical aggregation or anything more specific. Remember, these are supposed to be long-lasting principles, not a codification of what we are doing now, and not a specific set of policies. Let the community set the specific policies flexibly going forward.<br>
<br>
Also agree with Bill that we should have an explicit principle that "ARIN does not set Internet Routing Policy"<br>
<br>
> 0.3. Uniqueness (Registration)<br>
<br>
This aspect of the proposed revisions really went off the rails.<br>
First, uniqueness should be valorized as the single most fundamental and important principle of stewardship, the one to which all the other principles are subordinate. It is the most important justification for having a registry.<br>
<br>
Second, the purpose of uniqueness is NOT to aid law enforcement but to maintain the technical integrity of the address space. Law enforcement is, as the term implies, guided by law and if the world's governments want to require certain forms of identification they can do so, subject to due process, legislative checks and balances, constitutional constraints, and so on. We don't need to be doing that job; indeed it is illegitimate and dangerous for us to attempt to insert an address registry into that role. The person who wrote the uniqueness aspect of this document doesn't seem to understand this.<br>
<br>
> 0.4. Stewardship<br>
><br>
> It should be noted that efficient utilization and hierarchical<br>
> aggregation are often conflicting goals. All the above goals may<br>
> sometimes be in conflict with the interests of individual end-users or<br>
> Internet Service Providers. Care must be taken to ensure balance with<br>
> these conflicting goals given the resource availability, relative size<br>
> of the resource, and number resource specific technical dynamics, for<br>
> each type of number resource. For example, efficient utilization becomes<br>
> a more prominent issue than aggregation as the IPv4 free pool depletes<br>
> and IPv4 resource availability in any transfer market decreases.<br>
> Conversely, because the IPv6 number space is orders of magnitude larger<br>
> than the IPv4 number space, the scale tips away from efficient<br>
> utilization towards hierarchical aggregation for IPv6 number resources.<br>
<br>
This section is also inappropriate for a principles document. It purports to tell the current community, as well as all future deliberations for the next 20-odd years, how to make policy tradeoffs. That is the kind of thing that should be left to the community itself.<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>
</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>