[arin-ppml] About needs basis in 8.3 transfers

[Mike Burns]

Hi Owen,

Sorry for the top-post.

Owen, you continue to deny the danger to the registry posed by the needs 
test, comparing it to crackpot beliefs and describing it as FUD.
It is indeed hard to demonstrate registry inaccuracies, even when aware of 
them, due to registry access, confidentiality, and non-disclosure 
agreements.
But earlier in this thread I mentioned the presence of what I called zombie 
corporations in the registry.
These are companies in many states of dormancy whose sole asset is their 
address allocation and a vague corporate state.
These entities are sold to those who can not demonstrate need. ARIN is not 
notified. Whois does not change.
But the visibility into the real owner of the registration is practically 
nil. This is a direct result of the needs test.
Nobody wants to pay real-estate-sized prices and not have their investment 
recorded in Whois. The people who do this do it because they need the 
addresses and can't get them "legitimately".

This problem was acknowledged by John Curran as a potential route for those 
who want addresses but can't justify their entire purchase. He also 
mentioned contracts that lock up addresses, to be transferred over time as 
ARIN needs tests permit. Both these problems exist in the real world and I 
have been party to these agreements. Zombie corporation acquisitions fall 
within policy, so I refuse to wear the bad actor label.

I also pointed out that the public information in the Microsoft/Nortel deal 
included the fact that none of the blocks sold were registered in Whois to 
Nortel.Which means that if Microsoft had not decided after the auction 
finished that they would cut a secret modified LRSA with ARIN, they could 
have purchased the corporate husks of the original registrants, the Bay 
Networks and Synoptics and Wellfleet corporate shells and ip address assets. 
Then Microsoft would have had no problems advertising, routing, and using 
the space. The only issue would have been Whois. That apparently was not 
much of an issue for Nortel, which never did anything to change Whois after 
acquiring those companies in the decade after their acquisition.

This is a real danger which I have seen in the wild many times, one which 
John Curran acknowledged, and one which leads directly counter to our 
primary stewardship role of registering the addresses accurately.

It's fine to make a decision based on balancing conservation, which you feel 
applies to priced space, with registration, which you agree is our primary 
role. But you can't reach an appropriate balance if you deny the facts, 
which you seem to do by demanding some sort of proof of this apparent danger 
to the registry.

Many of us are not so sanguine about registry accuracy in the face of the 
current situation, and to your credit you are willing to compromise in the 
direction of making temporary changes to the needs test requirement in hopes 
of finding evidence one way or the other. This conversation is not in the 
context of 2014-14, a proposal to remove the needs test from some IPv4 
transfers, with size and frequency limits which are designed to prevent any 
fear of hoarding or speculation. In the context of 2014-14, then, arguments 
about hoarding and speculation can be distracting.

I'm sure people like Matthew Kaufman, Milton Mueller, David Huberman and 
many others believe that the needs test should be removed entirely. I fall 
in this camp, too. So 2014-14 is a request for these people to also 
compromise, as it only removes the needs test for smaller transfers, and 
only one such transfer per year per registrant.  Perhaps both sides can come 
together using the size of the needs-free transfer as a method of 
fine-tuning their compromise. Owen thinks a temporary size of /20 is worthy 
of consideration, and McTim thinks a /24 is the right size. I invite anybody 
who agrees that a compromise here is in order to volunteer what sized block 
would, in this context, make the proposal worthy of your support.

Regards,
Mike


----- Original Message ----- 
From: "Owen DeLong" <owen at delong.com>
To: "Matthew Kaufman" <matthew at matthew.at>
Cc: <arin-ppml at arin.net>
Sent: Saturday, June 07, 2014 3:34 AM
Subject: Re: [arin-ppml] About needs basis in 8.3 transfers



On Jun 6, 2014, at 10:04 AM, Matthew Kaufman <matthew at matthew.at> wrote:

> On 6/6/2014 2:31 PM, Owen DeLong wrote:
>>
>>> On Jun 6, 2014, at 9:59 AM, Matthew Kaufman <matthew at matthew.at> wrote:
>>>
>>>> On 6/6/2014 7:24 AM, Owen DeLong wrote:
>>>> Removing needs basis from 8.3 transfers doesn’t do that and it has a 
>>>> number of other harmful outcomes as previously discussed.
>>>>
>>> Can you name a harmful outcome of removing needs basis from 8.3 
>>> transfers that doesn't already exist in the form of contracts that lock 
>>> sellers to future buyers and/or contracts that allow the use of address 
>>> space by another entity?
>> As I have stated, we cannot block all mechanisms which circumvent policy. 
>> Yes, you can still produce the negative outcomes by circumventing the 
>> intent of policy. Bad actors will, of course do so. If you have 
>> strategies for effectively preventing bad actors from doing so, then I am 
>> open to discussing those.
>>
>> If you just want to use the fact that bad actors can circumvent policy by 
>> means we cannot control as a justification for eliminating policy, then 
>> this has been discussed and I still find that position unconvincing.
>>
>>
>
> That's only the first part of said justification. First off, lets stop 
> calling them "bad actors": A company with shareholders that knows it will 
> need IPv4 space over the next 3 years has employees that are legally 
> obligated to enter contracts that will ensure that they can acquire that 
> space once ARIN can not longer provide it. These contracts will take the 
> form of right of first refusal, lock-ups, or leasing of space and none of 
> them can be controlled or prevented by ARIN. The employees are not acting 
> in bad faith and the companies are not as a result "bad actors". They are 
> simply participants in a market for a limited resource... no need to 
> assign a value judgement to them.

Why should I stop calling community members who will choose to circumvent 
the intent of policy in favor of their own greed over the wishes of the 
community bad actors?

The employees have no such obligation unless the management of the company 
chooses to move the company in that direction.

> And there will be "needs justification"... only it will be done by the 
> interaction of the market and their CFO... the company will work out how 
> much space it needs over what it believes is a reasonable planning horizon 
> and then use that as justification for releasing the funds necessary to 
> enter into those contracts.

I call BS. This is the somewhat idealized case. The less idealized case is 
“We can gain a market advantage over our competitors by investing a couple 
of billion dollars in tying up as much of the available address space as 
possible.” Sure, no one organization is likely to achieve this kind of 
capture, especially under current policies. However, remove the needs test 
from policy and you’ve disabled several of the safeguards currently built 
into policy in favor of a free-for-all where a small number of companies 
behaving in this manner could, indeed, prevent the vast majority of 
competing organizations from obtaining address space going forward.

> Next, I and many others believe that there is a danger to the registry 
> once such a market becomes prevalent. Specifically, that the accuracy of 
> the registry will suffer. It will, more and more often, fail to reflect 
> who is using and/or controlling the use of the address space, instead 
> containing some historical trivia.

Yes, and many people believe in various things ranging from tin foil hats to 
virgin birth. I prefer to base policy decisions on documented fact rather 
than religion and FUD.

> I can foresee an avalanche effect, where as the registry becomes less and 
> less accurate, participants in the IPv4 market find it less and less 
> necessary to ensure that their own transfers or leases are reflected in 
> the registry... a sort of "broken windows" effect where it simply becomes 
> more and more acceptable to not care.

That’s certainly one worst case scenario. I would argue that if that were to 
occur, it would likely drive IPv6 adoption more than it would actually harm 
the IPv4 situation. YMMV.

> If you think that's a likely outcome, and that such a thing would be bad 
> for ARIN, you should support making it easier for people who are doing 
> perfectly legitimate things to record those things in the registry. I do.

I think it’s a very unlikely outcome and I don’t think it would be bad for 
ARIN. I think it would be bad for those attempting to continue to use the 
IPv4 internet if it were to happen, but not hugely so, at least initially. I 
think it would be a slow progression of increasing pain (much like NAT and 
CGN have already been).

You keep calling transfers outside of policy “perfectly legitimate”, but in 
reality, they are not perfectly legitimate. Can we please stop trying to 
call violators of policy and circumventers of policy intent “perfectly 
legitimate”?

> If you think that the market prices and the long-term risk created by the 
> introduction of IPv6 make hoarding and speculation or even significantly 
> overestimating ones own need unlikely, then there's no reason to oppose 
> removing specific needs justification as a requirement to record a 
> transfer in the registry. I don’t.

I do not believe that they do this at all. So I believe that there is reason 
to oppose removing specific needs justification as a requirement to record a 
transfer in the registry.

Owen

_______________________________________________
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.