[arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate

Mike Burns mike at nationwideinc.com
Sun May 15 14:13:42 EDT 2011


Hi Tom,

I don't think we will have to rely on "moments of controlled disclosure" you 
describe, involving NDA-covered private network information to the local 
registrar, simply to have accurate contact information.
Why?
Because proper registration is going to be the effective proof of ownership.
As the value of control of  IP assets becomes more widely known, and higher, 
in the face of free pool exhaust, those who control these rights will be 
motivated by their desire to publicy record their rights in a registry.
When addresses are free, conflict over their control is limited, and proof 
of ownership much less important.
When conflict rises, along with value, and there is no tangible "certificate 
of control", getting the authoritative registry recognition is more 
important.
I believe John Curran referenced an increase in the processing of old 8.2 
Transfers, cleaning up old mergers, which I take to be an indication of the 
motivation I am describing here.

Therefore,  x: (NOT current RSA signatories + NOT willing/able to undergo a 
need/capability test + ARE certain to self-maintain the quality of their own 
whois information at historically unprecedented  high levels in perpetuity) 
is the population I intended to reach with this proposal.
They will have every incentive to keep their information registred 
correctly, if only to increase its resale value.
You call them Saints. I call them normal humans who want some evidence of 
their valuable control rights.
All your groups, x,y,and z will likely keep their registration more updated 
than they have historically as the value of their holdings becomes clearer 
to all.

If I have a new business plan that I am pitching to investors, and if my 
projected growth plan includes a need for increasing IPv4 addresses over the 
next 24 months, what do I say to the investor who asks how I will get those 
addresses and what they will cost?
If I could purchase 24 months supply on the transfer market now, but would 
have to keep ARIN in the dark, and know that I could get the addresses 
routed by submitting the purchase document to my network provider,  why 
wouldn't I do that, and isn't it clear that Whois accuracy will suffer?
Is this situation so unworldly that it can't be envisioned?
The sole limitation to getting this transaction registered is the ARIN needs 
test for transfers.

I think it's really quite a stretch to think the needs requirement increases 
registration accuracy, as you imply.
Remember, if ARIN is doing a needs analysis for somebody, it's because they 
have already been contacted in reference to the desire to have ARIN book a 
transfer, right? So if they have already done that, why does the needs 
requirement enchance contact information accuracy?
I don't see the logic there.

Regards,
Mike



----- Original Message ----- 
From: "Tom Vest" <tvest at eyeconomics.com>
To: "Mike Burns" <mike at nationwideinc.com>
Cc: "Owen DeLong" <owen at delong.com>; <arin-ppml at arin.net>; "Paul Vixie" 
<vixie at vix.com>
Sent: Sunday, May 15, 2011 11:34 AM
Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate



On May 12, 2011, at 1:26 PM, Mike Burns wrote:

> Hi Owen,
>>
>>> I still don't see the connection between my proposal to drop needs 
>>> requirements for transfers and the participation rate of DNS whois or 
>>> the UK land office.
>>> I may be missing something obvious, though.
>>
>
>> I believe he is arguing that if you turn address policy into a 
>> free-for-all (as in your proposal), like
>> DNS, it will decrease, rather than increase whois accuracy. I hadn't 
>> thought of this consequence, but,
>> now that Tom and Paul have brought it up, it does make sense.
>
>
> I am still missing the connection between removing needs requirements for 
> transfers and having that decrease whois accuracy.
> If you can connect the dots, you will go a long way in convincing me that 
> my proposal is flawed.

Hi Mike,

Again, apologies for the delayed response. I tried to clarify the connection 
in my message of May 13, 2011 12:04:39 PM EDT (specifically, @ bullet points 
3 and esp. 4). But that was a long message that also covered several other 
reasons why the so-called "needs" (which IMO should be "capability") 
requirement is important which are completely independent of its relevance 
to whois accuracy, and perhaps I wasn't clear enough on the specific one 
that interests you.

Basically, the need/capability test facilitates the ongoing 
maintenance/preservation of whois accuracy because it assures that each 
subsequent allocation/assignment (and in the future, each transfer 
transaction) will trigger the same kind of "moment of controlled disclosure" 
that occurs when a new entity joins an RIR and/or requests an initial 
allocation. As a group, network operators -- and esp. growing ones --  
undergo the sort of internal changes (e.g., reorgs, relocations, new sites, 
new non-M&A commercial partnerships, et al.) that can trigger changes in 
their external contact details fairly frequently. For all sorts of reasons 
that are mostly banal (oversights, procrastination, impatience with 
"bureaucracy," miscommunication, someone else's job, thought they were 
already informed, etc.), the RIRs don't always "get the memo" at the time 
when such changes occur -- or even afterward, during subsequent "casual" 
interactions. Absent other countervailing factors, such changes would cause 
the overall quality of registration data to degrade progressively over time, 
with the more dynamic/faster growing networks typically leading the way 
down.

What prevents (or at least substantially mitigates) this progressive decay 
is the policy-mandated needs/capability test requirement. That requirement 
assures that each subsequent interaction between registrants and the RIR 
that could materially alter the distribution of IP number resources *will 
not* be "casual" in the above sense, but rather will (typically) involve 
some presentation of documents which illustrate the existence and size of 
the new addressing requirements. The review of such materials -- which 
frequently include invoices for new network-related assets or similar 
documents that show buyer address and other contact info -- provides a 
formal opportunity for RIR and registrant representatives to make sure that 
they're on the same page with respect to all current contact information.

So, to put this explicitly in the context of your proposal:

The exhaustion of the unallocated IPv4 pool is not going to reduce the 
frequency with which address registrants undergo the sort of internal 
changes that can make some or all of their current whois contact details 
outdated -- if anything it might make those changes happen more frequently. 
Thus, in order for whois data quality to be preserved going forward at (at 
least) current accuracy levels, the current practice of making each 
subsequent address-related transaction subject to a mandatory 
needs/capability capability review must continue.

In order for your proposal to have *any chance at all* of causing a net 
improvement in whois data quality, the number of future Pv4 transfer seekers 
that are

x: (NOT current RSA signatories + NOT willing/able to undergo a 
need/capability test + ARE certain to self-maintain the quality of their own 
whois information at historically unprecedented  high levels in perpetuity)

...would have to exceed the sum of other kinds of future address seekers, 
including those who are:

y: (NOT current RSA signatories + ARE willing/able to undergo a 
need/capability test + NOT certain to self-maintain the quality of their own 
whois information at historically unprecedented high levels in perpetuity)

z: (ARE current RSA signatories + (n/a) + NOT certain to self-maintain the 
quality of their own whois information at historically unprecedented high 
levels in perpetuity)

Logically, the universe of potential future address seekers is complete 
characterized by (x + y + z) as described above, plus two other groups that, 
hypothetically, wouldn't be affected either way by your proposal:

Incorrigibles: (NOT signatories + NOT willing + NOT self-maintaining)

Saints: (ARE signatories + (n/a)+ ARE self-maintaining)

[Note: I say "hypothetically" above because I actually believe that the 
adoption of this policy would undermine an existing community "norm" of 
whois participation that currently contributes to "irrationally" high data 
quality across current registrants -- and as a result your policy would 
cause average levels of whois "self-maintenance" to decline across all 
groups. But that possibility is not factored into this analysis]

Assuming that "saints" and "incorrigibles" would be equally represented 
across both current ARIN members/RSA signatories and future address seekers 
(and excluding any possible "normative" affects), your proposal would only 
be net positive at the point where ((non-Saint, non-Incorrigible x)) exceeds 
(non-Saint, non-Incorrigible (y+z)). Given the size of the current ARIN 
membership, the only way this pans out in your favor if 90%+ of current 
members and 90%+ of future address seekers actually fall into the "Saint" or 
"Incorrigible" category.

But of course, this assumption would also mean that your policy (and all 
policies, more-or-less) are almost complete irrelevant.

Happily, I believe that  those demographic assumption are grossly 
inconsistent with both RIR administrative experience and with the documented 
record of RIR community-policy interactions over the last 20 years.

Hence, I am opposed.

TV


>>> My whole goal is to increase accuracy in Whois, and I am not relying on 
>>> any financial or price mechanism for that increase.
>>
>
>> And now there is evidence that your proposal would likely have the 
>> opposite effect.
>
> What evidence?
>
>>> I have not argued that pricing will increase registration, I have argued 
>>> that pricing will ensure productive use.
>>
>
>> Which also remains in dispute and unproven.
>> Owen
>
> Hence the word argued.
>
>
> Regards,
> Mike




More information about the ARIN-PPML mailing list