ALAC submits the following comments for the task force's consideration.
The comments are focused on the "best practices" section contained
in the Preliminary Report.
The comments are also focused on those recommendations that would directly
affect individual Internet users and, in particular, registrants.
Best practice #5:
"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.)."
We read the Task Force's recommendation that "ICANN consider"
such a change as a proposal for a future policy-development process.
Before such a policy can be adopted, implementability needs to be studied:
The basic question here is how to encode the "method of verification"
in a way which scales across language barriers, globally.
The appropriate place for ICANN's consideration of this proposal would
be a future GNSO Task Force.
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: ..."
It's unclear what the status of these recommendations is supposed to
be: Is the Task Force suggesting that registrars' development of the plans
mentioned be mandatory? Or is the suggestion that ICANN produce a "hall
of shame" of registrars who do not 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."
This proposed best practice appears to substantially overlap with the
WDRP developed by the DNSO WHOIS Task Force, and approved by the ICANN
Board in 2003; see <http://www.icann.org/registrars/wdrp.htm>.
Changes to the WDRP at this point of time would be premature.
Best practice #8:
"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."
It remains unclear what "ICANN should consider" is supposed to mean in
this recommendation.
The substance of the proposed registrar practice is also troubling.
The recommendation completely ignores the availability of registrants'
postal addresses as an additional channel of contact that can be used
by registrars in order to obtain updated phone and e-mail contact data
when the data available don't work; note that the collection of facsimile
numbers is effectively optional under current RAA language.
The recommendation that domain names be placed on hold "immediately"
does not make any sense, and would be harmful: Communication channels
have outages which lie outside registrants' responsibility and influence;
registrants may be out of reach and may need time to respond. After how
many days of non-response is an e-mail address determined "not to
work"? After how many days without anyone accepting a call is a phone
number found "not to work"?
A proposal containing some similar steps was discussed by the DNSO WHOIS
Task Force and the subsequent Implementation Committee. Under that proposal,
domains would have been put on hold after 15 days of non-response to accuracy
inquiries. The WHOIS Implementation Committee found that recommendation
un-implementable, and recommended a 30 day time line instead, see <http://www.dnso.org/clubpublic/nc-whois/Arc00/doc00085.doc>.
The proposed practice would also significantly lower the threshold for
cancellation of domain names: The current "willful provision of inaccurate
or unreliable information" (RAA 3.7.7.2) standard would be replaced
by a diffuse "not all means of communication work immediately"
standard, with strict time lines for cancellation. This change would be
detrimental to the stability of domain name registrations.
Finally, in cases in which an e-mail address that uses the disputed domian
name is the only available means of contact, the proposed policy would
actually shut down the only existing communications channel to the registrant.
To summarize, best practice #8 ignores registrants' interests to an extent
which borders to contempt. It does not pay attention to the stability
of domain name registrations. It does not pay attention to questions of
implementability. It ignores previous work and community consensus.
We respectfully suggest that the Task Force give up this recommendation.
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 proposal seems to be substantially identical to policy I.1.B of the
DNSO's WHOIS Task Force <http://www.icann.org/gnso/whois-tf/report-19feb03.htm#I>;
that policy has been accepted by Council and Board, but has not been implemented,
yet. Adopting another, mostly identical consensus policy would appear
unwise.
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 proposal ignores identity theft issues: Contact data that perfectly
identify the registrant of one domain name can be false for another domain
name. Blanket application of this proposal would cause damage to registrants
who haven't done anything wrong.
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" appears to describe an eventual policy implementation
process. There is no need to include the demand for such a process as
a specific Task Force recommendation.
As a way forward, we recommend that Task Force 3 seriously consider the
minority position submitted by the registrars' constituency. This document
could provide a basis for improving WHOIS accuracy and registrar compliance
with their accuracy-related obligations in a way which is responsive to
registrants' and users' needs.