WHOIS Task force 3 Improving accuracy of collected data DOW

Last Updated: 1 September 2009
Request for comments
The comment period has ended. Thank you for your input.
Click here to read comments
Comment period ended 28 November 2003 23:00 GMT

WHOIS Task Force 3
Description of Work

Amended: 29 October 2003

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
- up to three outside advisors

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

The work of several groups has been sited by parts of the GNSO community as having a bearing on the need for improved accuracy, including the OECD Guidelines for Consumer Protection in the Context of Electronic Commerce (PDF), Implementing the OECD Privacy Guidelines in the Electronic Environment: Focus on the Internet (PDF), and the ICANN Security and Stability Committee.

The 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 the top 5 priority issues , and issue 6 in the WHOIS Privacy Issues Report

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 name (registrant, admin, technical and billing), domain name, postal address, email address, fax number, phone number, and other domain name related data. 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 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 ). 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 ).

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. There may be mechanisms outside of Whois to address this issue.

The purpose of this task force is to develop mechanisms to improve the quality of contact data that must be collected at the time of registration, in accordance with the registrar accreditation agreement (in particular clauses 3.3.1 and 3.7.7.1), and the relevant registry agreement (e.g Unsponsored TLD Agreement: Appendix O (.biz)).

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 previous ICANN policy changes have 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. The effectiveness of these mechanisms will need to be evaluated by the ICANN staff and reported to the GNSO (for example 12 months after implementation of the policies). Note not all the policy changes agreed by the ICANN Board in March 2003 are implemented as of October 2003.

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.

The Task Force will not consider the accuracy for data that is not mandatory, and will not consider which elements should be mandatory.

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 publicly available information on the techniques used by other online service providers (to verify that data collected iss correct) as well as information on the price of services offered by the online service provider.

- 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 additional mechanisms are necessary to provide traceability of registrants, or provide for more timely responses for misuse of domain names associated with deliberately false information.