[arin-ppml] Draft Policy 2014-14, WAS Re: About needs basis in 8.3 transfers

[Owen DeLong]

The majority of my comments were intended towards the general question posed (8.3 transfers and needs basis).

My comments which should be considered in the context of 2014-14 should be strictly limited to those where I expressed an opinion on 2014-14.

Namely:

	1.	I oppose 2014-14 as written.
	2.	I consider that a /16 and a permanent policy are both too much of a floodgate and too much uncharted and dangerous territory.
	3.	As a compromise, I proposed a 12 month policy experiment (add a clause which would terminate 2014-14 12 months after it
		becomes active) with a /20 maximum prefix limit which could be used to gather additional data for the community to consider
		whether or not such policy improves registry accuracy while not allowing large enough blocks to drive any serious harm to the
		stewardship of the address space.

Below are some of my reasons for holding this position, but they should not be taken as direct commentary on 2014-14, but rather more general comment on the need to continue Needs Basis as currently practiced even beyond free-pool runout.

It is unfortunate that economists use language differently from the rest of us and that the plain english reading of words from an economist often
results in a completely skewed view of what they have said.

For example, the term efficiency, when used by an economist should mean "every resource is optimally allocated to serve each person in the best way while minimizing waste and inefficiency". Unfortunately, in the current context, the meaning seems to be defined more along the lines of "every resource is migrated to those best able to pay the most money for it."

Needs, as most people would define them are completely ignored, and instead, the combination of ability and desire to pay are the only criteria which are applied as an evaluation of "the best way possible".

To an economist, the goal of fairness seems to be an absurd concept and, as my esteemed colleague Mr. Mueller has stated should be replaced with "efficiency is the key concern". Unfortunately, for his argument, ARIN's mission statement and the policy development process refer to a requirement that policies be fair, but do not say anything about efficiency other than this sentence under PDP section 4.2 (Technically Sound):

> Support both conservation and efficient utilization of Internet number resources to the extent feasible. Policy should maximize number resource availability to parties with operational need.
> 

Contrast this sub-bullet of "Technically sound" with the title of the previous paragraph:
> 4.1. Enabling Fair and Impartial Number Resource Administration
> 

> Internet number resources must be managed with appropriate stewardship and care. Internet number resource policy must provide for fair and impartial management of resources according to unambiguous guidelines and criteria. All policy statements must be clear, complete, and concise, and any criteria that are defined in policy must be simple and obtainable. Policy statements must be unambiguous and not subject to varying degrees of interpretation. 


And it becomes quite clear that "Fairness" is, in fact, much more of a key concern in policy development than efficiency as an economist would seem to define it.

Of course, it is hard to blame them. "Allocation by sheer greed" is such an ugly term while "Allocation Efficiency" sounds so much more positive. Obviously, if one can get away with it, redefining "Allocation Efficiency" to mean the same thing, then it becomes much easier to sell the idea. However, direct redefinition would be too obvious and people might see through the sales pitch, so instead, more slight of hand is required. First, we change the way we define words like "best way" and "minimizing waste" and "inefficiency". If we can redefine those terms in strictly monetary units so that "best way" means the way that provides the lowest price possible in the immediate circumstance and further define "minimizing waste" as reducing the ancillary transaction costs and other economic contributors to the cost of goods sold and finally redefine "inefficiency" as transaction costs not borne from the underlying cost of the resource being purchased, then suddenly the phrase "allocated to serve each person in the best way while minimizing waste and inefficiency" no longer has any regard for any aspects of those words beyond those which can be mapped into dollars and cents, thus eliminating many of what I believe to be the more important meanings of those terms.

Owen

On Jun 9, 2014, at 20:28 , John Springer <springer at inlandnet.com> wrote:

> OP of "[arin-ppml] About needs basis in 8.3 transfers", I hope this has been useful to you. And the speech in Bellevue. As shepherd of 2014-14, I am less sure of what I may make of it.
> 
> It is a lovely philosophical discussion. Clearly an excellent opportunity for adherents of two diametrically opposed camps to ascend the lofty pulpit and orate, without the messy necessity of voicing support or opposition to the Draft Policy that theoretically all of this refers to, this being a list for the discussion of public policy.
> 
> Comments to each of my esteemed collegues below.
> 
> On Mon, 9 Jun 2014, Andrew Dul wrote:
> 
>> On 6/6/2014 8:06 AM, Milton L Mueller wrote:
>>> All we are debating is the presence or absence of needs assessment as a gatekeeping function for that market.
> 
> Not precisely. For unless you are just commenting generally about an unconnected bunch of opinionating, you are commenting about 2014-14, which, while it is about "the presence or absence of needs assessment" may not be relegated to a simplistic gatekeeping function by your merely stating that it is so. 2014-14 seeks to address a specific issue (transfer request processing time) that happens to fall within a much larger context (access to number resource rights). Using one to draw conclusions about the other runs immediately afoul of the several ergo propter hocs. Unless you are not referring to 2014-14, in which case carry on, my bad.
> 
>>> This is a fairly administrative and technical argument, not a moral one.
> 
> Not really. For instance, what argument is that? And I sure thought I read some moralizing in this long thread which is not invalidated by the previous statement.
> 
>>> Efficiency is the key criterion (not fairness, really).
> 
> 2014-14 or not, you decide.
> 
>>> If you support needs assessments you have to make a case that the costs and burdens associated with it are justified by quantifiable benefits.
> 
> In what context? 2014-14? If so, you're getting way too fancy. IMO, that is what the proposal author is trying to do, (make the case, not get fancy). To express support for the DP, (if that's what you are trying to do), all the double negatives here are kinda confusing. If you are speaking to an opponent of the DP, they do not in fact have to make the case as you describe. I sort of have to make the opposite case.
> 
>>> In this case, inefficiency is unfairness: if the needs assessment process prevents resources from going where they are wanted most, or if the cost burdens associated with the process exceed the value of the numbers acquired for small operators, or if it is shown that large, established companies with well-established relationships to ARIN can navigate the process more easily, then there are signs that needs assessment is unfair because of its inefficiencies.
> 
> You said above efficiency and fairness were not really the key criterion, here you say they are the same (or rather that their opposites are, which implies...). Which do you mean?
> 
>>> You have to do a better job of explaining why it is "fair" to force a willing seller and a willing buyer to submit to an additional step when that step both limits the quantity of resources available for transfer and raises the cost of participating in the market by a substantial degree.
> 
> Again, if you are trying to help rebut opponents of 2014-14, this is not their job. The failure to prove the converse leads to status quo. Whomever you might be addressing with this comment apparently needs no encouragement to continue to make this exact case at some length. I would find more useful, comments why this is _NOT_ fair. Call me kooky.
> 
>> Milton,
>> 
>> Thank you for this two paragraph summary of what we are debating here.
> 
> So, Andrew. As one shepherd of 2014-14 to another, what are we to do with "Re: [arin-ppml] About needs basis in 8.3 transfers" WRT 2014-14? Are arguments there able to be applied wholesale to 2014-14, mapping (divining?) pro-needs basis logic as anti-2014-14 and vice verse?  If not, is it all to be discounted by saying that the authors did not explicitly express either support or opposition and therefore we are not permitted to read anything into their statements?
> 
> All list posters who posted to "About needs basis in 8.3 transfers", is it OK to read your minds about this or do you want to come back and state what you mean clearly in a context that is unambiguous?
> 
>> Are there, in your opinion, any reasonable "steps" (e.g. policy
>> elements) that the registry community should implement as policy between
>> a buyer and a seller that are not the "existing traditional needs
>> assessment" which would provide a benefit to the IPv4 market and
>> Internet community as a whole?
> 
> Excellent question, such commentary would be valuable and welcome, and if so, what?
> 
> John Springer
> 
>> Andrew
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>> 
>> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140610/23b61ad1/attachment.htm>