[arin-ppml] ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers

[Owen DeLong]

On Jun 29, 2012, at 3:43 PM, David Farmer wrote:

> 
> 
> On 6/29/12 17:14 CDT, Owen DeLong wrote:
>> 
>> Sent from my iPad
>> 
>> On Jun 29, 2012, at 5:13 PM, David Farmer <farmer at umn.edu> wrote:
>>> On 6/29/12 10:06 CDT, jeffmehlenbacher at ipv4marketgroup.com wrote:
>>>> As I previously told you Owen, we are asked once per week by a
>>>> prospective buyer or seller how these transactions can be accommodated
>>>> without enduring the rigors of justification.  When we identify the
>>>> risks for both buyers and sellers alike, they go quiet.  You wonder
>>>> where they go don't you?  I have a pretty good idea they simply seek
>>>> alternative means and providers.  So it's not fear mongering to suggest
>>>> people will disregard the registry.  Some do.  I cannot quantify it
>>>> because we neither endorse nor monitor.
>>> 
>>> We need to find middle ground here guys.
>>> 
>> 
>> 24 months _IS_ middle ground. Continuing to negotiate for half-way to infinity in an iterative process is a perversion of Zeno's paradox designed to effectively achieve infinity over time.
>> 
>> Calling for iterative middle ground is equivalent to calling for infinity.
> 
> I agree with that, however the above didn't say anything about 60 months.  We all need to practice a little more active listening. I'm referring to what he is really asking for, or more precisely what he is being asked for;
> 
> "we are asked once per week by a prospective buyer or seller how these transactions can be accommodated without enduring the rigors of justification."

Yes, he's asking to eliminate needs basis justification and he's willing to accept any middle ground that is closer to that than the status quo. That's where he started before we went from 12 to 24 months, so I fail to see how it differs from the iterative set of compromises I describe above.
He was at least an active participant in favor of the move to 24 months and I believe one of the people calling for it to be longer as well in the last policy cycle.

> 
>>> Jeff, and others,
>>> 
>>> Needs justifications are not going to go away, so stop asking for the community to make it go away, its not going to happen.
>>> 
>>> However, on the flip side,
>>> 
>>> Owen, and others
>>> 
>>> The community does need to find way of simplifying the process and make needs justification less of a burden if transfers are going to work the way we need them too.  If we don't then people will find a way around the process.  Owen, you're fond of John Gilmore's quote about the "Internet routing around damage," well if our policies create damage they will get routed around too and that's not fear mongering.
>> 
>> True, but at 24 months, I am not convinced we are creating damage. (other than the damage caused by the extended dichotomy between free pool justification and transfer justification periods). Going to 36 months or 60 months would only exacerbate that damage.
>> 
>> 
>>> So trying to think outside the box here, what if we created some special rules that simplified demonstrating operational need for smaller transfers but still fundamentally kept reasonable needs justifications in place overall.
>> 
>> I'm amenable to discussing that. It sounds reasonable on the surface. However, I don't find it terribly difficult to justify operational need for a smaller allocation/assignment and I believe that the bar for operational need for a transfer is identical to that for an allocation/assignment.
> 
> What you and I think is difficult or not is honestly irrelevant, I here this complaint all the time.  Not just through Jeff

I hear the complaint often as well. When I do, I ask more questions... Do you?

Upon further investigation, I almost always find that the complainant falls into one of the following categories:

	+	Doesn't have any idea what space they have or how it is used
	+	Did not review the relevant sections of NRPM prior to submitting their request and applied
		using terms that placed them under utterly incorrect policy sections for their intent.
		(If you say "we are an ISP..." ARIN can't second-guess you into end-user criteria for example)
	+	Submitted a mal-formed request and took the first round of additional questions as a denial and
		gave up declaring ARIN "too difficult to work with".
	+	Submitted a request for a large complex network without providing a sufficient or credible justification
		and became resistant when asked to do so.
	+	Got themselves awkwardly trapped in the you can get a larger aggregate to grow your network if you
		agree to return... policy and then grew into both the larger aggregate and the space they were supposed
		to be returning and had no way forward. (I have helped a few organizations disentangle these and they
		are hard, but they are also self-inflicted wounds so to speak).

If you or Jeff can point to "justification is too hard" examples with meaningful details that don't fit into one of those categories, I'd like to know more about it. Otherwise, sorry, but I have little sympathy and I do not believe it is in our best interests to craft policy to make allocations and assignments easily and readily available to those who cannot reasonably show demonstrated need.

>>> - Allow any organization to receive a transfer of an unaggregated /24, that the original assignment was a single class C or a /24 that is not part of a larger range of addresses held by the same organization originating the transfer, on the condition that the recipient puts it into operational use within 6 month and they cannot receive another such transfer for 24 months without demonstrating justified need.
>> 
>> I would be OK with that if they can show that it is at least 50% utilized within 6 months and not merely routed.
> 
> I was thinking routed and actual devices using it, no particular utilization level, but with a contractual claw-back for failure to meet the requirement.  If you want a waiver from the normal process you better meet your commitments.
> 
> The intent here is to facilitate getting old unused Class C's into use.

I understand the intent and I believe that a 50% minimum utilization within 6 months is not at all unreasonable. After all, to get a new /24 from the registry, you have to show immediate utilization of 50%.

> 
>>> - Allow any organization to receive a transfer of up to 50% of their current holdings or /16 which is ever is smaller on the condition that the recipient puts it into operational use within 6 month and they cannot receive another such transfer for 24 months without demonstrating justified need.
>> 
>> I could accept this with the same caveat above if it were limited to /20.
> 
> The intent here is to facilitate getting old unused Class B's into use.

That's not what it would do. It places the maximum they can receive at /16 if they have more ≥/15 already in inventory.

Transferring a /16 to an organization that merely routes it and puts one address on a router interface would meet your test. That's not a justified needs basis, it's an abandonment of needs basis. The test bar has to be higher than that.

> 
>>> - All transfers larger than /16 require demonstrating justified need with a window of 24 or maybe 36 months.
>> 
>> 24 months, yes. (current policy already). 36 months, uh, no. See my above concern about damage.
> 
> I'm fine with 24, if we find can loosen up for the smaller stuff, the big guys have the technical and legal staff, and financial resources to make it work.  But, I completely believe that requiring both financial resources and rigorous justification maybe asking to much.

The small guys can get it pretty easily from the free pool, so I'm not sure what benefit the community derives from that at the present time or any time in the next 3 policy cycles.

> I also believe we can't eliminate justified need, to prevent market power plays, but no one is going to corner the market with a /16.

With /16 chunks, it could become cost effective to spawn enough Delaware corporations to do just that. What makes you think it wouldn't?

Owen