[arin-ppml] Comments on Draft Policy 2010-3

[Joe St Sauver]

Hi,

I have reviewed https://www.arin.net/policy/proposals/2010_3.html
dated 2 Feb 2010, and I have many serious concerns about the
draft policy in its current form. 

Let me go over just a dozen of those concerns now. 

1) The overarching purpose of IP whois point of contact information
is and should be to insure that operational problems can be addressed 
by those who are most knowledgeable and best situated to address them.

While ISPs have a role in limiting or responding to problematic traffic 
flowing through their networks, ultimately it is the down stream customer
who is configuring and operating systems which are sourcing or sinking 
traffic, and it is those customers who will need to fix many operational 
issues.

If customer address and telephone information is redacted from IP
whois reassignment and reallocation data, the community's ability to 
contact the administrator of a problematic system is profoundly 
impaired, and we are reduced to relying on a third party, the upstream 
ISP, to proxy our query or complaint to their downstream customer. 

Some ISPs may be willing to play this intermediate role, others may not.
There is nothing in this policy that compells them to take on that 
additional work (nor is there any indication of how the costs of 
meeting that communication "mandate" might be paid). 

Even if ISPs *are* required to forward communications they receive
to their downstream confidential customer, it will likely take time 
for them to do so -- maybe just a minute or two, but more likely 
hours, or perhaps even days if this process is handled manually. 

When dealing with problematic systems, time can be of the essence,
yet this policy as currently written enforces no processing time 
"SLA" on ISPs who may have elected to shroud customer data.

2) As written, it is unclear that ARIN would be permitted to 
respond to legal process seeking disclosure of shrouded customer
contact information. In particular, while the policy states that 
"the customer's actual information must be provided to ARIN on 
request" the policy also states that the information "will be 
held in the strictest confidence." 

The customer information will be held in "strictest confidence"
by *whom?* The ISP? ARIN? The ISP *and* ARIN? As written, the 
policy is at best ambiguous, and at worst the proposed language 
may create a new duty, requiring ARIN to employ all reasonable
efforts to protect customer data it may receive (including
potentially defending against legal actions seeking compulsory
redisclosure of the customer's data).

3) The draft policy allows *ISPs* the option of shrouding their
customer's data, ("*ISPs* may choose to...", emphasis added), 
but what of the customer's preferences when it comes to the
release of their point of contact data? The policy is silent 
on this matter.

While *some* customers may want to have their contact information
concealed by their ISP, *other* customers may actually prefer full
disclosure and complete transparency. For example, full disclosure
of contact information may be preferred by some as a matter of 
bolstering one's online reputation (thereby avoiding what some term
suspicion about "men in ski masks").

Unfortunately, as written, disclosure or non-disclosure of the 
customer's point of contact data is solely a matter for the ISP's 
discretion. This ignores the role and importance of customer
preferences when it comes to controlling the release of their 
own data.

4) Does this proposed policy apply to both PA and PI customer 
address space? The policy speaks only of "reassignments and 
reallocations" -- is that meant to implicitly limit this to 
just PA space?

In the case of PI space that may be announced by multiple ISPs for
multihoming, which ISP has controlling authority when it comes
to determining if customer address and phone number information
should be withheld? If there are multiple upstream ISPs, which
ISP's address and phone number would be shown in lieu of the
customer's information? Either? Both? The customer him/her self?
The policy is silent in the face of this potential complexity,
and potentially clouds control over PI netblocks.

5) Eroding the availability of customer point of contact data
hinders the public's ability to formally or informally audit ISP 
IP reallocations and reassignments, even though we are now 
approaching a critical period when IPv4 address scarcity may motivate 
shenanigans or abuse. This lack of transparency is inconsistent with 
the Number Resource Organizations first and most critical goal, which 
is to "Protect the unallocated Number Resource pool" 
(http://www.nro.net/about/index.html)

6) Will this proposed policy be consistent with the policies of other 
regional registries? If ARIN is more permissive in its reassignment
and reallocation process than other registries, ARIN invites an
influx of abusive customers/cybercriminals, potentially damaging 
the value of ARIN-assigned/ARIN-allocated space for all who have or
will receive address space from ARIN.

7) Access to IP whois/rwhois data is critical to working cyber abuse 
issues in many circumstances (for example, consider a case where 
malware or phishing incident involves URIs with raw IP addresses 
rather than domain names). Removing customer point of contact
information from whois/rwhois hinders efforts to resolve incidents
of cyber abuse. Since the rationale for this policy makes it clear
that it is motivated solely by competitive concerns, the importance
of those competitive concerns should be weighed against the damage
this proposed policy would potentially cause to the safety and 
stability of the Internet.

8) Customer address and phone number information serves an important
purpose with respect to customer differentiation and disambiguation.

Consider an assignment made to a customer with a common name 
(hypothetically "John Smith" or "Jane Doe"). If whois/rwhois data
lacks address and phone number information, how am I to distinguish
John Smith of Akron Ohio from John Smith of Wichita Kansas? Answer,
entities (other than the ISP) couldn't, absent assignment of a 
unique global customer identifier.

Confouding those two "John Smiths" could have profound consequences.
For example, what if a block list operator incorrectly attributed 
both of those blocks to a single malicious "John Smith"?

In a case where one's abusive, and one's wholly innocent, the misdeeds
of the abusive customer may inadvertently result in unjustified 
action against the innocent customer who has the misfortune of
having the same "customer name."

9) For that matter, what constitutes an acceptable customer "name"? 

If, hypothetically, a celebrity such as Cher held a netblock, would 
"Cher" be enough of a name to meet the requirement of this proposed
policy? Are nicknames sufficient? First initial plus a last name? 
Just first and last initials? What of a corporation? Is just the 
corporation's name to be listed? The corporation's name plus a 
human point of contact there? Are role names acceptable? (I wonder 
how many netblocks will end up owned by the customer with the
name of "hostmaster", eh?)

10) Arguing in the alternative, if customer privacy *is* a critical
objective, the draft as written fails to adequately shield the
core of customer identity information, namely the customer's name.

Given the customer's name, it may be possible for data brokers and
other "e-penders" to merge the customer's name with other data 
sources to the ultimate detriment of the customer's privacy.

Similarly, continuing to argue in the alternative, if privacy *is*
important, the policy as written still allows the public to identify
and potentially tabulate all reassignments or reallocations assigned 
to a given customer. Thus, if a single customer with dozens or 
(perhaps even hundreds) of small distributed reassignments or
reallocations is perceived differently than a single customer with
a single monolithic netblock, this policy fails to "protect" that 
customer's (rather dubious) address usage.

I also have issues with the proposed policy's process, oversight
and review.

11) The draft policy has a proposed implementation timeline that 
is abrupt: implementation is to be "immediate." No explanation or 
justification is provided for this highly expedited deployment
time frame. 

If this policy were to be passed, more time should be provided to 
allow ISPs and customers to prepare to accomodate this policy. 

12) If a customer is wronged by this policy, does the customer 
have the right to appeal their ISP's actions? If so, to whom? 
The policy is silent on this point. 

If this policy is passed, will there be any analysis of the uptake 
of this policy, or any review of the burden it imposes on ARIN 
or other members of the community? No. 

Given all of these flaws, I urge that this policy not be adopted 
unless/until the preceding issues are considered and satisfactorily 
resolved.

Thank you for considering this feedback on Draft Policy 2010-3.

Joe St Sauver, Ph.D.

Disclaimer: the opinions expressed are my own, and do not necessarily
represent the opinion of any other entity or organization.