WHOIS Task Force 3 (accuracy) had its (first? only?) open conference call. The call was intended to extend the reach of the ongoing public comment process. It wasn't too successful at that.
I believe I hogged the line for the most part of the call, going through the individual "best practices" proposed in TF3's preliminary report. In a nutshell, the proposed recommendations either don't make sense, are harmful, or moot.
Best practice 5 reads as follows:
ICANN should also consider including the “last verified date" and "method of verification" as Whois data elements, as recommended by the Security and Stability Advisory Committee. See Whois Recommendation of the Security and Stability Advisory Committee, available at http://www.icann.org/committees/security/sac003.htm. (“Whois data must contain a "Last Verified Date" that reflects the last point in time at which the information was known to contain valid data. It must also contain a reference to the data verification process.”).
This may actually be a good idea, but it would require some thought on how the "method of verification" can be expressed in WHOIS in a way that scales across language barriers. The place for ICANN's consideration would be a GNSO policy-development process, so this "best practice" would really belong into a different section of the report, and is essentially another issue for future policy-making.
Best practice 6:
With input from the relevant contracted parties and other interested stakeholders, ICANN should solicit direct input from each registrar relating to its current level of compliance with existing agreements, and plans to improve the accuracy of Whois data that it collects. The plans will be made publicly available except to the extent that they include proprietary data, and registrars that fail to submit plans by a date certain would be publicly identified. The plans should state specific steps for improving WHOIS data accuracy, including: ...
(The report goes on to list a number of steps that "should" be included with registrars' plans.)
The report fails to explain what problem this is supposed to cure. It's also unclear what the real suggestion here is: Are the elements listed supposed to be policies that registrars must comply with? Or is the proposal that ICANN create a public hall of shame identifying those registrars who don't comply with non-mandatory measures?
Best practice 7:
ICANN should require domain name registrants to update and correct Whois data on an annual basis including, for example, clear instructions to domain name registrants of this obligation and special email addresses for expedited and priority handling of such updates.
Much of this is very close to the WDRP. It's unclear where the actual changes would lie, and what would justify them.
Best practice 8, emphasis mine:
ICANN should consider requiring Registrars to verify at least two of the following three data elements provided by domain name registrants - phone, facsimile and email - and ensure that these elements function and that the Registrar receives a reply from these means of communication. Where none of the three data elements works, then the domain name should immediately be placed on hold. If only one of the means of communication works, then the domain name shall be placed on hold for a period of 15 days in which the domain name registrant shall correct all of the WHOIS data elements. If the domain name registrant fails to correct all of the WHOIS data elements during that time frame, the domain name registration shall be cancelled.
Several things are wrong with this proposed policy. To begin with, what does "immediately" mean here? The DNSO WHOIS task force had discussions on a similar proposal. Back then, a hard and fast 15 day time line for responses from registrants was considered inadequate by many. Now, TF 3 is suggesting "immediate" in the same place. The 15 day hold period could be problematic, too: What if the one means of communication with the registrant that works is by e-mail, through an address that uses the domain name in question? The policy proposed would actually cut off the one remaining means of contacting the registrant.
There was brief discussion that, maybe, short deadlines and hard rules could be triggered when there is actual misconduct in connection with a registration. Ken Stubbs and I both made the point that registrants of domains related to, say, phishing expeditions, are often victims themselves, so this policy proposal would be likely to cause collateral damage while not hitting bad actors. I also noted that shutting down domain names based on mere allegations of misconduct would expose legitimate domain name holders to attackers, and would be dangerous from a stability point of view.
Best practice 9:
Where a domain name registration is cancelled due to the non-functionality of WHOIS data elements - phone, facsimile, and email - the domain name can be reconnected for a fee to be set by the registrar. Upon reconnection of any domain name in circumstances where the domain name had been placed on hold or was immediately cancelled, the Registrar shall verify all data elements before reconnecting the domain name. The Registrar should ensure that the reconnection charge it imposes is sufficient to cover the costs of the heightened verification it must perform in reconnecting a previously cancelled domain.
This "best practice" seems to repeat the substance of the consensus policy on the interaction between WHOIS-related domain cancellations and the redemption grace period that had been designed by the DNSO WHOIS Task Force, and was accepted by Council and Board last year.
Best practice 10:
When a domain name registration is cancelled (or suspended, etc.) for false contact data, all other registrations with identical contact data should be cancelled (or suspended, etc.) in like fashion.
This recommendation fails to consider cases in which the "false contact data" belong to a real entity which has nothing to do with the disputed registration -- a situation that would be made much more likely were registrars to deploy technology that screens registrations for "accuracy" proactively. (This is another favorite proposal of the Intellectual Property Constituency.)
Best practice 11:
ICANN staff should undertake a review of the current registrar contractual terms and determine whether they are adequate or need to be changed in order to encompass improved data accuracy standards and verification practices as a result of the current PDP.
This "best practice" describes what's otherwise known as an implementation process. Please implement the results from this PDP.
Best practice 12:
ICANN should develop and implement a graduated scale of sanctions that can be applied against those who are not in compliance with their contractual obligations or otherwise violating the contractual rights under these agreements.
This recommendation seems to assume a considerable compliance problem on the registrar side. The report fails to make that compliance problem transparent -- in fact, the summary on the whois data problem reporting system that's part of the same report speaks about more than 24,000 accuracy complaints submitted through the system, and 19 (nineteen) complaints about unsatisfactory resolution. That's less than one unsatisfactory resolution complaint per thousand WHOIS inaccuracy reports. So, what problem is this graduated sanctions proposal supposed to solve?
Overall, the Task Force may be much better off using the registrar constituency's minority report as a basis for its further work.
