[arin-ppml] 2014-14, was Internet Fairness

[Owen DeLong]

>> 2) The problem the proposal purports to solve hasn't actually been
>> demonstrated. "ARIN staff [...] is spending scarce staff time on needs testing of small transfers."
> 
> You pose an interesting procedural question. In our considerations of advancing prop-204 to Draft Policy, the question of the problem statement was specifically discussed and it was agreed that the community had spoken "loud and clear" that request turn around times are too long. We can quibble about the author's linkage, but we didn't ignore this and the motion to advance passed.

I don’t think this can be taken to indicate what you claim here.

As I understand the current PDP, the vote is as to whether or not the proposal contains a clear problem statement. To be certain, the problem statement in 204 was indeed clear. I do not believe we are allowed to evaluate the accuracy or validity of the problem statement at that stage, only it’s clarity. As such, I voted to advance 204 to draft policy based on the problem statement being clear. This should not in any way be construed as a vote that it was accurate, legitimate, or that I concur that the stated linkage between delays for request processing and transfers was, in fact, in evidence.

> Certain AC actions may be petitioned, https://www.arin.net/policy/pdp.html, PART THREE PDP PETITION PROCESS, but I don't think failure to convince everyone that the problem statement is clear is one of them. In fact, the petition process appears to be specifically directed at failure to advance things. There does not appear to be provision to petition advancement of a policy proposal to Draft Policy, which is what you seem to be suggesting here.

Clarity and accuracy are different things. Indeed, the problem statement is clear and the AC vote reflects a strong belief by the AC that is the case.

Construing that to extend to the accuracy or validity of said problem statement, however, is not appropriate, IMHO.

>> Obviously, doing the necessary checking
>> requires staff time, but is it a significant amount?  Is it taking much
>> longer than it used to?  Is it costing ARIN a lot of money in staff
>> wages and overhead to do these assessments, or is it lost in the noise?
> 
> If 17.47% is not small, is it significant? There definitely was a lot of comment from the community in Chicago that it is taking too long to turn requests around. What is the datum for a lot of money? I'll leave it to the AC staff to specifically answer the financial questions you pose.

The problem is that there is no indication what fraction of that time is linked to serialized free pool requests processed by teams (vs. previous processing by individuals) vs. transfer processing time. As such, I don’t think we have clear data to indicate the necessity of this proposal or that it will have a meaningful impact on turnaround times.

>> 4) Rearranging the IPv4 deck chairs
> 
> I understand the impulse to belittle and the frustration of some network professionals with certain proposals, even categories of proposals. But I personally am not at liberty to ascribe much weight to an appeal to ridicule.

While whimsically phrased, I don’t think the sentiment of “IPv4 is over, stop tinkering with the policy for the endgame” can be entirely dismissed as ridicule.

We have heard this from substantial fractions of the community on several occasions.

Owen