ALAC comments on TF3 report

[Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>]

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.

Regards,
-- 
Thomas Roessler  <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/