RE: [whois-sc] Task Force 3: Terms of reference on data accuracy

[Steve Metalitz <metalitz@xxxxxxxx>]

Bruce,

Thank you for this draft, and apologies for delay in responding. I submit
these relatively minor suggestions with the understanding that I support the
views expressed by Maggie and Kiyoshi regarding the desirability of a single
task force focused on the top 5 issues identified by the constituencies.
This draft addresses one of those 5, and could be folded into TORs for the
single task force that has been called for.  My suggested additions below
are in CAPS and my suggested deletions are in [brackets].  

Steve Metalitz

-----
From: Bruce Tonkin [mailto:Bruce.Tonkin@xxxxxxxxxxxxxxxxxx]
Sent: Tuesday, October 14, 2003 5:34 AM
To: whois-sc@xxxxxxxx
Subject: [whois-sc] Task Force 3: Terms of reference on data accuracy


Hello All,

Here is a draft terms of reference for task force 3, for discussion at a
teleconference on Tuesday 21 Oct, 2pm Los Angeles, 5pm Washington, DC,
10pm London, 7am(wed) Melbourne

Note that it will be the role of the GNSO Council to manage resourcing
of the 3 task forces in consultation with ICANN staff.  It may be
necessary to combine these task forces if resources are short, but for
now we should concentrate on getting well defined terms of reference for
each of the areas of work.  The three areas are likely to get
significant participation from other areas of ICANN (e.g SECSAC, GAC
etc), and the GNSO should remain a focal point, but seek resources from
other areas to complete the work.

I particularly look forward to input from the 3 constituencies that
raised accuracy as a key issue:
Ie intellectual property, business users, internet service providers, to
further refine the terms of reference.


Regards,
Bruce


Title: Improving Accuracy of collected data

Participants:
- 1 representative from each constituency
- ALAC liaison
- GAC liaison
- ccNSO liaison
- SECSAC liaison
- liaisons from other GNSO WHOIS task forces

Description of Task Force:
==========================

Data is collected from registrants at the time of registration to
facilitate future contact of the registrant for a range of reasons
including business issues (for example problems with payment), security
and stability issues (for example relating to fraudulent use of a domain
name, or failure of a nameserver associated with a domain name),
intellectual property infringement, and other legal issues (e.g use of a
domain name as part of a CONSUMER FRAUD OR criminal activity).  Many users
of the data
perceive that there is an unacceptable level of inaccuracy in the data
that compromises its ability to facilitate identifying and contacting
registrants.

Data quality has been recognised as important by several groups.  For
example one of the OECD Privacy Guidelines (from:
http://cs3-hq.oecd.org/scripts/pwv3/pwhome.htm) states that: "Personal
data should be relevant to the purposes for which they are to be used,
and, to the extent necessary for those purposes, should be accurate,
complete and kept up-to-date"."  The ICANN Security and Stability
Committee (from:
http://www.icann.org/committees/security/whois-recommendation-01dec02.ht
m) stated that:
"It is essential that Whois data used to provide contact information for
the party responsible for an Internet resource is validated at the time
of a registrant's initial registration and on a regular basis
thereafter."

Three GNSO constituencies rated the issue of data quality with respect
to procedures currently followed by registrars to promote accurate,
complete and up-to-date data as one of their top 5 priority issues
(issue 6 in the WHOIS Privacy Issues Report at:
http://www.icann.org/gnso/issue-reports/whois-privacy-report-13may03.htm
). THIS ISSUE WAS AMONG THE TOP 5 PRIORITIES IDENTIFIED ACROSS THE
CONSITUENCIES PARTICIPATING IN THE STEERING GROUP.  

The main issues associated with data quality include:
- verification of data at the time of registration
- ongoing maintenance of data during the period of registration
- protecting against deliberate submission of false information

The types of contact data that may be verified for correctness include
REGISTRANT NAME,
postal address, email address, fax number, phone number.  WIDELY AVAILABLE
[Verification]
software can attempt to verify that a particular data element is
correctly formatted and exists.  Note however it is often difficult to
obtain such software that works on a global basis.  Another issue is
ensuring that the data is actually associated with the registrant (for
example there have been incidents of identity fraud, where the data is
completely verifiable but associated with another person).  Domain names
are provided purely electronically, and rarely involve delivery of a
service to a physical address, or delivery to a physical person.  This
makes AUTOMATED verification more difficult.

The recent WHOIS policy development process created a new policy called
the WHOIS data reminder policy
(http://www.icann.org/registrars/wdrp.htm) that creates a process where
a registrant is reminded on an annual basis to update the WHOIS data.
There is also an established process whereby a user of the data may
lodge a complaint with a registrar to get the contact data corrected.
If the registrant does not correct the information, a registrar may
cancel the domain name licence.  (see clause 3.7.7.2 of the Registrar
Accreditation Agreement
http://www.icann.org/registrars/ra-agreement-17may01.htm).  The recent
WHOIS policy process also included a new policy to ensure that the
redemption grace period could not be used as a mechanism to avoid these
provisions (see Section 1B of
http://www.icann.org/registrars/ra-agreement-17may01.htm).

It is difficult to use verification or maintenance approaches for
registrants that deliberately provide false information.    The
high-cost mechanisms to verify contact information with a high degree of
uncertainty can be easily evaded by low-cost mechanisms at the disposal
of some registrants.  In such cases it may be necessary to collect
additional information associated with an online registration to aid in
contacting the registrant including credit card information, source IP
addresses, and website traffic logs, OR TO TAKE ADDITIONAL STEPS TO VERIFY
SUSPECT REGISTRATIONS.  It also may be necessary to create
expedited procedures for responding to misuse of a domain name
associated with deliberately false information.

The purpose of this task force is to develop mechanisms to improve the
quality of contact data collected at the time of registration.


Out-of-scope
============
To ensure that the task force remains narrowly focussed to ensure that
its goal is reasonably achievable and within a reasonable time frame, it
is necessary to be clear on what is not in scope for the task force.

Given that [the previous GNSO WHOIS task force] PREVIOUS ICANN POLICY
CHANGES HAVE [ has] addressed issues
associated with maintaining accurate information (WHOIS data reminder
policy, and mechanisms for handling complaints about inaccurate data),
this will not be studied in this task force, EXCEPT TO THE EXTENT OF
EVALUATING THE EFFECTIVENESS OF THESE EXISTING MECHANISMS.

The task force should not consider issues associated with changing the
data elements that are collected. [ This is the subject of a separate
task force.]

The task force should not consider mechanisms for restricting the public
display for some data elements, which may lead to a reduction in the
provision of false information by those registrants seeking to protect
their privacy.  [This is the subject of a separate task force.]



Tasks/Milestones
================

- collect information on the current techniques that registrars use to
verify that the data collected is correct.  For example techniques to
detect typing errors by registrants intending to provide correct
information.  Survey approaches used by cctlds to verify that the
contact data collected is correct.

- collect information on techniques used by other online service
providers (where there is no physical contact with the registrant and no
physical delivery of goods or services) to verify that data collected is
correct.

- create a best practices document for improving data verification based
on the information collected that can be applied on a global basis

- determine whether any changes are required in the contracts to specify
what data verification is necessary at time of collection to improve
accuracy

- determine what verification mechanisms can be used cost effectively to
combat the deliberate provision of false information, and determine
whether further policy development AND/OR CONTRACTUAL CHANGES ARE [is]
necessary to provide traceability
of registrants, or provide for more timely responses for misuse of
domain names associated with deliberately false information.