[alac] Revised: Comments WHOIS TF3

[Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>]

As agreed on the conference call today, here are slightly revised
comments.  I'll submit these on behalf of ALAC unless I hear
objections by Friday, close of business (European time).

Begin comments:

> 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.

Add:

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: ...

Delete:

> It is not clear to us what problem these steps are supposed to cure.

Replace:

> It's also unclear what the status of these recommendations is

by:

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.
> 

Strike:

> 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.
> 
> The Task Force report does not make clear what actual problem such a
> sanction system would be supposed to cure, and how it would achieve
> that.  The only data on registrar compliance contained in the report
> relate to the WHOIS Data Problem Reporting System. These data
> suggest that less than one complaint on unsatisfactory resolution
> per thousand data problem reports was received.  (19 complaints on
> unsatisfactory resolution; > 24,000 data problem reports.)

(The registrars can take care of this part themselves.)

> 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/