PRELIMINARY REPORT - WHOIS TASK FORCE 3

WHOIS TASK FORCE 3 IMPROVE THE ACCURACY OF DATA COLLECTED FROM GTLD REGISTRANTS PRELIMINARY REPORT .pdf version

Introduction
Summary of Work
Summary of Constituency Positions
      At-Large Advisory Committee
      Business Users Constituency
      Intellectual Property Constituency
      Internet Service and Connectivity Providers Constituency
      Non-Commercial Users Constituency
      Registrar Constituency
      Registry Constituency
Summary of ICANN's InterNIC WDPRS Report
      Key Findings
      Background and Overview of the WDPRS
Matters Requiring Further Consideration and Proposed Best Practices
Comments Provided in Submitting Vote or Position on Best Practices Section
Registrar Constituency Minority Report
Appendix A – Position Statement of the At-Large Advisory Committee
Appendix B - Position Statement of the Business Users Constituency
Appendix C - Position Statement of the Intellectual Property Constituency
Appendix D - Position Statement of the Internet Service and Connectivity Providers Constituency
Appendix E - Position Statement of the Non-commercial Users Constituency
Appendix F - Position Statement of the Registrar Constituency
Appendix G - Position Statement of the Registry Constituency
Summary of Task Force 3 Public Comments

Introduction

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

Summary of Work

The GNSO Council orally issued its request for Constituency Statements on February 19 with the statements being due on March 19, 2003. The Task Force is to issue its Preliminary Report, as recognized under the PDP, on April 9, 2004.

In the WHOIS Task Force 3 Description of Work, amended October 29, 2003, the GNSO Council identified five Tasks/Milestones, the first two of which are addressed, to the extent currently possible, in this Interim Report:

The "Tasks/Milestones" for Task Force 3 are as follows:

1. 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.
2. Collect publicly available information on the techniques used by other online service providers (to verify that data collected is correct) as well as information on the price of services offered by the online service provider.
3. Create a best practices document for improving data verification based on the information collected that can be applied on a global basis.
4. Determine whether any changes are required in the contracts to specify what data verification is necessary at time of collection to improve accuracy.
5. 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 more timely responses for misuse of domain names associated with deliberately false information.

In connection with Task 1, TF3 collected limited data from Registrars. TF3 also has sought to survey, via CENTR, the Whois Data Accuracy practices of CENTR members, and has circulated to the CCNSO through ICANN Staff, a survey of Whois Data Accuracy practices by ccTLDs.

The Task Force has been informed through ICANN Staff that CENTR determined not to include TF3’s survey questions in the CENTR survey. Similarly, the remaining ccTLDs and ccTLD organizations have decided not to respond to the survey submitted to them.

Task 2 required the Task Force to collect publicly available information on the techniques used by other online service providers to verify that WHOIS data collected is accurate as well as the price of services offered by the online service provider. The Task Force also undertook a survey of online service providers but only received one substantive response to its request.

As a result of the highly limited number of responses to its inquiries, the Task Force is currently developing a proposed statement of best practices based on the experience and observation of the Task Force and the represented constituencies. If the Task Force is able to develop a statement that is supported by a super-majority of the constituencies, it will be included in the final version of this report as a recommendation of the Task Force. A recommendation of this nature will permit the Task Force to continue its work on tasks 4 and 5.

Summary of Constituency Positions

Not all Constituencies have submitted Position Statements. If further submissions are received prior to April 19, 2004, they will be summarized and included in this draft report and the resultant Interim Report of the Task Force.

At-Large Advisory Committee

The position of the At-Large Advisory Committee is included as Appendix A.

Summary:

The Committee position observes that:

• Attempting to procure accurate information from entities that do not wish to provide it is wasted time and effort. A determined entity will always work around, not within, any system of rules or processes.
• Implementation of any data verification schemes must be applied globally and not be applied to a gTLD on a discriminatory country-by-country basis.
• Known verifications schemes are unable to differentiate plausible data from accurate data.
• The feasibility of known verification schemes, given current requirements, is unproven.
• Registrar Accreditation Agreement provisions regarding data collection and display may not have force in many jurisdictions.
• Registrants should not directly or indirectly bear the costs of any data verification service primarily required by third-party data users.

The Committee position recommends that:

• That no further action should be taken to compel unwilling subjects to provide accurate data.
• That the Task Force should concentrate its efforts on ensuring that those entities that do wish to provide accurate data can easily do so through simple and cost-effective processes.
• A review and amendment of the relevant provisions of the Registrar Accreditation Agreement to ensure consistency with existing national privacy legislations.
• That ICANN require the exclusive use of a distributed coordinated Whois model instead of centralized implementations.

Business Users Constituency The position of the BUC is included as Appendix B.

Intellectual Property Constituency

The position of the IPC is included as Appendix C.

Summary:

The Constituency position makes no supporting observations.

The Constituency position recommends that:

• ICANN should work with all relevant parties to create a uniform, predictable and verifiable mechanism for ensuring compliance with Whois-related provisions of the present agreements and devote adequate resources to such a compliance program.
• ICANN should ask each registrar to present a plan for substantially improving the data it collects.
• The RAA and gTLD registry agreements should be modified to provide for graduated or intermediate sanctions for patterns of violations by a registrar of the Whois data accuracy obligations of those agreements.
• That the policy development process for this task force should mutate into an ongoing effort with the goals of researching and communicating information regarding practicable and cost-effective methods used to improve the quality of identifying and contact data submitted by customers in online transactions outside the realm of gTLD domain name registrations and development of best practices within the realm of gTLD domain name registration for improving the accuracy, currentness and reliability of contact data in the Whois database.

Internet Service and Connectivity Providers Constituency

The position of the ISCPC is included as Appendix D.

Non-Commercial Users Constituency

The position of the NCUC is included as Appendix E.

Summary:

The Constituency position observes that:

• Accuracy of Whois data is not unconditionally desirable.
• Whois data protections are necessary to protect registrants and other contacts contained in the gTLD Whois database from identity theft and to ensure freedom of speech.
• The purpose of the gTLD Whois system was originally to allow for technical coordination between domain holders.
• The original purpose of the gTLD Whois system was not to provide law enforcement or other self-policing interests with a means of circumventing normal due process requirements.
• Privacy is key to ensuring accuracy of the data in the gTLD Whois databases.
• The Task Force has not collected sufficient information to reach any conclusions regarding best practices for verifying data accuracy.

The Constituency position recommends that:

• Submission of personally identifiable contact data should be optional.
• ICANN recognize the data protection principle that the purpose of data and data collection processes must be well-defined before policies regarding its use and access can be established.
• Registrants be allowed to protect their personally identifiable information and that there should be no penalization for inaccurate data entry.
• The Task Force makes recommendations regarding revision of the procedures by which domain name holders update and/or correct domain name data.

Registrar Constituency

The position of the Registrar Constituency is included as Appendix F.

Summary:

The Constituency position observes that:

• The issue of a useful and sustainable model for access to registrant data is an issue of primary concern to the Constituency.
• Registrars are the primary caretakers of Whois access and Whois data in the gTLD namespaces.
• Registrars are a diverse group of companies employing a broad range of business models in many different countries.
• The primary interest of Registrars regarding this issue is that of commercial implementer, operator and caretaker.
• The current body of policy allows Registrars to uphold their obligations in a responsible manner that does not impinge the contractual rights or obligations of other parties to these agreements.
• ICANN's existing program of registrar/registry compliance and education is a necessary element of ICANN's function and should receive the full support of the community.

The Constituency position recommends that:

• ICANN continues to develop its ongoing compliance program to ensure that contracted parties are appropriately meeting their obligations under the various agreements.
• ICANN does not ratify any Whois related policy that substantially alters the rights and obligations found in current policy.
• The GNSO Council undertakes a specific examination of Registrar data collection and protection practices and reports on the policy implications of the various data protection regulations in effect around the world.

Registry Constituency

The position of the Registry Constituency is included as Appendix G.

Summary of ICANN's InterNIC WDPRS Report

On March 31, 2004 ICANN published the first of its reports concerning the InterNIC Whois Data Problem Reporting System. The entire report can be found at http://www.icann.org/whois/wdprs-report-final-31mar04.htm.

Key Findings

• Over the course of the eighteen-month reporting period (Sep-02 through Feb-04), the system received 24,148 confirmed Whois inaccuracy reports.
• 82% of the reports concerned domain registrations in .com, and .net and .org accounted for 13% and 5% of all reports respectively. An enhanced version of the system has recently been launched that will include not just the legacy gTLDs, but all gTLDs under contract to ICANN: .aero, .biz, .com, .coop, .info, .museum, .name, .net, .org, and .pro.
• 54.7% of the reports submitted included an indication that the registrant's mailing address was inaccurate.
• A total of 16,045 unique domains names were the subject of Whois Data Problem Reports meaning that roughly 1/3 of all submissions were duplicates. The most common reason for the submission of multiple reports for one domain name (thus creating the duplicates) were efforts to shut down domains that were alleged to be the source or subject of spam.
• More than 40% of all the reports (9,938 out of 24,148) were submitted by just 0.3% of reporters (20 individuals out of 5,755 reporters). Over 20% of the reports had text fields that included the word "spam".
• The number of complaints sent to each registrar was generally proportional to each registrar's relative market share.
• On average, registrars were each sent approximately 0.00048 Whois inaccuracy reports per active registration per year, which equates to an average of 4.8 reports per year for every 10,000 domains under management.
• ICANN received 19 complaints indicating that the submitter was dissatisfied with the way a registrar handled the problem report.
• Registrars' voluntary participation in the tracking system at ICANN's request facilitated the monitoring of trends and tracking of compliance.
• The WDPRS has had a role in the correction of a substantial number of Whois data inaccuracies. As many as 36% of all Whois inaccuracy reports resulted in the correction of data or a deletion of a domain name. Whois inaccuracies measuring in the thousands have been corrected since the system was implemented.
• Beginning on 31 October 2003, all ICANN-accredited registrars were obligated to comply with the new "Whois Data Reminder Policy." The WDRP is intended to be an additional step to improve Whois data accuracy. Experiences with the implementation of that new policy will be the subject of an ICANN report to be published by 30 November 2004.
• In ICANN's planning for Fiscal Year 2004-05, there is provision for additional dedicated staff resources to monitor the Whois Data Problem Report System, to obtain accurate and useful statistical data, and to monitor registrar and registry compliance with Whois service, privacy and accuracy obligations.

Background and Overview of the WDPRS

ICANN's Memorandum of Understanding with the United States Department of Commerce requires that ICANN publish an annual report that provides statistical and narrative information concerning community experiences with the InterNIC Whois Data Problem Reports System. This report will also include an evaluation of the impact of the WDPRS on improved accuracy of Whois data.

Whois data for gTLDs includes information about the registrant, administrative contact, technical contact and nameservers associated with each domain name. This information is used for a variety of purposes including identifying and verifying online merchants, investigations by consumer protection and other law enforcement authorities, determining whether a domain name is available for registration, identifying the source of spam e-mail, enforcement of intellectual property rights, addressing cyber-attacks and other wise resolving technical network issues. Whois services have been available on the internet since the early 1980s, and continue to be broadly used.

ICANN implemented the WDPRS on September 3, 2002 in order to assist registrars in complying with their contractual obligations. The goal of the WDRPS is to streamline the process for receiving and tracking complaints about inaccurate data and incomplete Whois data. Reports are submitted through the InterNIC website which is operated by ICANN. The centerpiece of the WDPRS is a centralized online form, available at http://wdprs.internic.net, for submitting reports about Whois data inaccuracies.

Reports received via the WDPRS are forwarded to the responsible registrar for handling. ICANN's experience has been that accredited registrars do conscientiously comply with their contractual obligations by acting promptly to correct incomplete or inaccurate data that is brought to their attention.

Eighteen months of experience have brought to light several areas where the original WDPRS could be improved. Specifically, the originally deployed system did not include a gTLDs under contract with ICANN, included excessive manual processes, imposed administrative burdens on registrars who chose to comply with the system, did not capture adequate statistics and lacked integrated mechanisms for monitoring and receiving feedback from persons who submitted reports. To correct these deficiencies and improve the overall system, ICANN has recently launched an improved version of the system.

The WDPRS has had a role in the correction of a substantial number of Whois data inaccuracies. As many as 36% of all Whois inaccuracy reports resulted in the correction of data or a deletion of a domain name. Whois inaccuracies measuring in the thousands have been corrected since the system was implemented.

One additional step recently taken by ICANN to improve Whois data accuracy is the implementation of the "Whois Data Reminder Policy". This new policy is an ICANN Consensus Policy as defined in the "Registrar Accreditation Agreement" and is therefore binding on all accredited registrars. Further details can be found at http://www.icann.org/registrars/wdrp.htm.

Matters Requiring Further Consideration and Proposed Best Practices

The surveys conducted by Task Force 3 provided limited input that could serve as a basis for identifying and assessing best practices for improving data accuracy and verification. Taking these limited inputs into account, the Task Force compiled a preliminary list of matters requiring further consideration and proposed best practices, which are set forth below. Also included is the vote of each constituency on the particular statements and recommended best practices. The vote of the ALAC was taken without prejudice as to whether or not that vote would be counted, in light of the anticipated legal opinion from ICANN counsel on that issue.

Matters Requiring Further Consideration

1. ICANN should work with all relevant parties to continue to create its ongoing compliance program to ensure that contractual parties are meeting the WHOIS-related provisions of the present agreements. ICANN should devote additional resources to such a compliance program in order to provide adequate support. See http://gnso.icann.org/issues/whois-privacy/raa-whois-16dec03.shtml. ICANN should work with and assist registrars in developing, in consultation with other interested parties, and by a date certain, "best practices" concerning the "reasonable efforts" which should be undertaken by registrars to investigate reported inaccuracies in contact data (RAA Section 3.7.8). See http://www.dnso.org/dnso/notes/20030219.WhoisTF-accuracy-and-bulkaccess.html.
    
   

   For	Against	Abstain
   CBU IPC ISP Registry	ALAC NonComm Registrar

2.  
3. In developing such a program, ICANN should consider:
   1. The resources assigned to manage this plan, including up front and careful consideration of the costs associated with implementing various recommendations for registrars and flexible options for registrars to implement the policies in a compliant manner;
       
      

      For	Against	Abstain
      CBU IPC ISP Registry	ALAC NonComm Registrar

   2.  
   3. The specific elements of compliance that the internet community is primarily concerned with;
       
      

      For	Against	Abstain
      CBU IPC ISP Registry	ALAC NonComm Registrar

   4.  
   5. Measurement and reporting mechanisms that allow appropriate analysis of the effectiveness of this ongoing program including existing compliance assistance mechanisms such as ICANN's online Whois data inaccuracy reporting tools;
       
      

      For	Against	Abstain
      CBU IPC ISP Registry	ALAC NonComm Registrar

   6.  
   7. Continued outreach to and education of affected stakeholders to ensure that existing requirements and obligations are understood and met and that new requirements are captured and appropriately dealt with. This effort should ensure that ICANN advisories related to this issue are specifically brought to the attention of newly accredited Registrars and that resources be made available to the Registrar community to ensure that the impact and scope of these obligations are apparent and understood;
       
      

      For	Against	Abstain
      CBU IPC ISP Registry	ALAC NonComm Registrar

   8.  
   9. Requiring that informational resources be provided to new Registrants and brought to their attention via the registration agreement that all Registrants must agree to prior to the activation and renewal of their gTLD registration, based on a model version of materials, so that no registrar gains a competitive advantage from differential treatment of this requirement;
       
      

      For	Against	Abstain
      CBU IPC ISP Registry	ALAC NonComm Registrar

   10.  
   11. Ongoing development and promotion of gTLD Registry, Registrar and Registrant best practices that foster the accuracy of the Registrant data contained in the Whois database.
        
       

       For	Against	Abstain
       CBU IPC ISP Registry	ALAC NonComm Registrar

4.  
5. Any Best Practices that are viewed as being mechanisms for improving data verification on a global basis should be developed by or under the direction of ICANN, soliciting the cooperation of responsible registrars, and disseminated to accredited registrars and other relevant parties as part of ICANN's ongoing educational and compliance initiatives. In such efforts, recognizing that technology/software may play a role in developing this solution, ICANN should rely on the competitive marketplace for the provision of relevant technology and should mandate only the outcome, not how the Registrar accomplishes the outcome. ICANN should consider retaining an independent third party which could, on a confidential basis, gather the critical underlying data germane to assessing current data verification practices in the registrar and other relevant industries, as well as from selected ccTLDs. In addition, ICANN should consider the work of the IETF, including its work on the IRIS protocol being developed by the CRISP working group.
    
   

   For	Against	Abstain
   CBU IPC ISP Registry	ALAC NonComm Registrar

6.  
7. Specific examination of registrar data collection and protection practices should be undertaken, including investigating all options for the identification and viability of possible: A) automated and manual verification processes that can be employed for identifying suspect domain name registrations containing plainly false or inaccurate data and for communicating such information to the domain name registrant; and b) readily available databases that could be used for or to assist in data verification, taking into account the wide variety of situations that exist from region to region. The GNSO Council or other appropriate body should participate in specific examination of registrar data collection and protection practices to ensure consideration of policy implications, including various data protection regulations that may affect certain jurisdictions in which registrars operate.
    
   

   For	Against	Abstain
   CBU IPC ISP Registry	ALAC NonComm Registrar

8. Proposed Best Practices
    
9. 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.”).
    
   

   For	Against	Abstain
   CBU IPC ISP Registry	ALAC NonComm Registrar

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

    For	Against	Abstain
    CBU IPC ISP Registry	ALAC NonComm Registrar

    1.  
    2. Identification and public disclosure of a designated contact point for receiving and acting upon reports of false Whois data;
        
       

       For	Against	Abstain
       CBU IPC ISP Registry	ALAC NonComm Registrar

    3.  
    4. Plans to work with ICANN to train employees and agents regarding the Whois data accuracy requirements;
        
       

       For	Against	Abstain
       CBU IPC ISP Registry	ALAC NonComm Registrar

    5.  
    6. Taking reasonable steps to screen submitted contact data for falsity, including use of automated screening mechanisms, manual checking, spot-checking, and other verification techniques for submitted data;
        
       

       For	Against	Abstain
       CBU IPC ISP Registry	ALAC NonComm Registrar

    7.  
    8. Steps to correct false data in all registrations that are substantially identical to that in the initially false registration that has come to the registrar's attention;
        
       

       For	Against	Abstain
       CBU IPC ISP Registry	ALAC NonComm Registrar

    9.  
    10. Steps to improve the accuracy of contact data submitted to it through re-sellers or other agents;
         
        

        For	Against	Abstain
        CBU IPC ISP Registry	ALAC NonComm Registrar

    11.  
    12. Measurements for improving performance of the quality of the registrar's Whois data.
         
        

        For	Against	Abstain
        CBU IPC ISP Registry	ALAC NonComm Registrar

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

    For	Against	Abstain
    CBU IPC ISP Registry	ALAC NonComm Registrar

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

    For	Against	Abstain
    CBU IPC ISP Registry	ALAC NonComm Registrar

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

    For	Against	Abstain
    CBU IPC ISP Registry	ALAC NonComm Registrar

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

    For	Against	Abstain
    CBU IPC ISP Registry	ALAC NonComm Registrar

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

    For	Against	Abstain
    CBU IPC ISP Registry	ALAC NonComm Registrar

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

    For	Against	Abstain
    CBU IPC ISP Registry	ALAC NonComm Registrar

At Large Advisory Committee Position

I'm writing to you as ALAC's liaison to the GNSO Council; I understand that Vittorio Bertola, ALAC's liaison to TF3, is traveling and can't reach you by e-mail. Apologies for submitting the vote slightly late.

For purposes of tallying a vote, ALAC votes AGAINST all recommendations made in the proposed TF3 report.

For purposes of giving advice, we respectfully suggest that the report, in its current state, not be presented for public comment, but rather be substantially revised.

The document put up for a vote on TF3 is not even suitable as a basis for public comment or decision-making on the Council and Board levels: Such a document would have to discuss the Task Force's inputs and deliberations, it would have to compare the recommendations made to the baseline policy and practice effective today, and it would also have to include discussion of the effects (and side effects) of the recommendations made. Making the addressees and status (consensus policy?) of individual recommendations transparent would also contribute to enabling an informed discussion of the proposals made.

Specific to the area of WHOIS accuracy, it would also be helpful to compare any recommendations made to the results of the DNSO Whois Task Force's and Implementation Committees work from 2002/2003, and to make sure that the considerable body of public comment and community discussion is taken into account that was generated back then.

Thomas Roessler, May 27, 2004

Commercial and Business Users Constituency

The BC votes in support of the Best Practices section of the Preliminary Report in the overall interest, at this late date, of moving a preliminary report forward for public comment. This vote is cast, however, with some reservations, which do not affect our general support to place the preliminary report for open, public comment.

In particular, we are troubled by the level of detail in Item 8, which recommends that a domain name be put on hold for a period of 15 days and requires that the domain name be cancelled if the registrant fails to correct the registration within that time frame. We question whether the report should be dictating any specific time frames at this stage and
serious consideration must be given into whether the 15 day strict cancellation policy can be reasonably implemented.

In item 10, requiring that a domain name registration be cancelled or suspended, etc. for
false contact data, along with all other registrations with identical contact data, needs additional clarification. This suggestion requires further study into how it can be reasonably implemented without imposing strict monitoring obligations on registrars or imposing undue costs on any stakeholder.

On behalf of the BC, I'd like to acknowledge everyone's hard work on these difficult issues. We look forward to working with you all, as always, in a constructive manner as we strive toward reaching consensus policy.

Sarah B. Deutsch, Representative, May 27, 2004

Intellectual Property Constitutency

Voted in favor of all aspects of the Best Practices Section of the "Preliminary Report" without comment.

Brian Darville, Representative

ISP Constituency

Voted in favor of all aspects of the Best Practices Section of the Preliminary Report "in the interest of moving ahead . . . ."

Greg Ruth, Representative, May 28, 2004

Non-Commercial Users Constituency

I marked a vote for each of the provisions of the document, though I'd like to convey my vote is clearly against the entire Best Practices document as it currently stands rather than against the specific provisions. I appreciate the work that has gone into this and there are some provisions that I would actually support, but not enough to accept them the way the current document is framed.

Frannie Wellings, Representative, May 27, 2004

Registrar's Constituency

I have taken counsel from members of the Registrar Constituency and other GNSO participants and must respectfully vote "no" on all counts, with qualification, on the proposals contained in this draft.

Those qualifications being:

1. There are a limited number of highly onerous requirements that cause substantial portions of the document to become unacceptable to registrar interests. For instance, the requirement to admit liability and submit to a managed remediation plan in the event that a registrar is non-compliant with some or all of their Whois related obligations is an unworkable aspect of this document. However, many of the subordinate terms would be acceptable to the members of the Registrar constituency if they were not associated with the liability that comes with the declarations.
2. The proposal mixes active and passive verification techniques with seeming disregard for the actual quality of the end result. It is the registrar position that passive verification coupled with mandatory participation in the Whois Data Problem Reporting System will create a substantial increase in the quality of the data contained in the Whois database without undue impact on registrants and registrars. Active verification at the time of registration, beyond simple data characteristic checking, is an unproven and unexplored option that is likely to impose significant cost and burden on registrants and registrars.
3. The proposal does not adequately consider the true impact of existing programs nor does it consider potential improvements to these programs in an effort to achieve whois data accuracy. The proposal is silent on existing programs like the WDPRS despite very strong data that it is a viable option that we should seriously examine and potentially mandate as policy.
4. The proposal does not sufficiently consider the inputs of the SSAC and other historical GNSO proposals including the results of the prior Whois Task Force. ICANN and the GNSO have developed a substantial number of recommendations and considerations that were not considered for inclusion in this report. The sum of many of these is likely to have a drastic impact on increasing the Whois data quality.

Overall, there are a number of elements of this proposal that the registrar constituency could support, but given the unintended - but likely - consequences, we must formally oppose this particular version.

I sincerely appreciate the investment that has been made in this document by the members of this task force and urge everyone to continue moving forward with this difficult, but important process.

Ross Rader, Representative, May 27, 2004

Registries Constituency

Voted in support of items 1-7 & 12.. abstained on items 8,9, & 10.

Ken Stubbs, Representative, May 28, 2004

Matters Requiring Further Consideration, Policy Recommendations and Proposed Best Practices

The GNSO Registrar Constituency does not believe that the findings of Whois TF3 are well-suited to advance the goal of increasing the overall accuracy of the Whois database and in some cases may actually increase data inaccuracy. While we do not support the existing recommendations of the task force, we fully support the overall policy objectives of the GNSO and have therefore created an alternate set of recommendations that we believe can be implemented and achieve the goals of the task force as set out in the GNSO Council' terms of reference for TF3.

1. Proposed Best Practices
   • Registrars must identify and disclose a designated public contact point responsible for receiving and acting upon complaints received via the mandatory Whois Data Problem Reporting System (WDPRS) and related whois record data accuracy issues.
     • ICANN should amalgamate and publish this list on their website.
     • Registrar should certify that this contact point has been trained on Whois Data Accuracy policy requirements.
   • Registrars should work together to create a clear, consistent process in order to enable registrants wishing to update or correct their established whois data to do so in a quick and simple manner to ensure compliance with Section 3.2.2 of the Registrar Accreditation Agreement (http://www.icann.org/registrars/ra-agreement-17may01.htm#3.2.2).
   • Registrars should take reasonable steps to prevent Registrants from supplying inaccurate data at the time of registration.
   • Registrars should act upon complaints received via the WDPRS within one week of receipt.
   • Registrars must resolve WDPRS complaints within 45 days of receipt.
     • Acceptable resolution includes;
       1. correction of the report inaccuracy
       2. confirmation of the validity of the data
       3. cancellation of the registration in the event that the Registrant does not provided corrected data in response to valid reported inaccuracies.
2. Policy Recommendations
   • Participation in ICANN's Whois Data Problem Report System should be a mandatory contractual requirement for registrars and registrants. The WDPRS System should be the focal point in ICANN's efforts to promote Whois data accuracy.
     • Registrars must respond to complaints received via the WDPRS and act upon them in a timely manner
     • Registrars must close problem reports when the issue has been resolved or the name has been canceled.
     • Registrars must attempt to contact registrants regarding the reported inaccuracy through all means available to them.
       1. It is recommended that Registrars first attempt to use automated means such as an email sent to each of the domain name contacts and if unsuccessful undertake a second attempt via telephone or fax numbers and finally via post.
       2. If the Registrar is incapable of contacting the Registrant or an Agent of the Registrant via one of these means within the time permitted by this process, the Registrar should place the registration on hold for a period of 30 days. If within this period the data accuracy issues are not resolved, then the Registrar should cancel the registration permanently.
       3. The Registrar shall verify the corrected data prior to reactivating the domain name or closing the WDPRS problem report. Registrars may choose to perform this function on a for-fee basis.
     • The identities of parties filing complaints must be made verifiable by the party accepting the accuracy complaint. The WDPRS system should require the payment of a reporting fee or other mechanisms to discourage frivolous complaints.
   • Amend RAA to ensure that Registrants who willfully provide false contact information or fail to respond to requests for data verification within 30 days will have their registration(s) cancelled.
     • Note: This is currently an optional condition
3. We propose that the task force endorses these additional recommendations and request that the GNSO Council consider them for further policy development work;
   • The Task Force endorses the follow recommendations of the Security and Stability Advisory Council;
     • 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.
     • A Whois service must discourage the harvesting and mining of its data.
     • Whois services must provide mechanisms to protect the privacy of registrants.
     • Whois records known to be false or inaccurate must be frozen or held until they can be updated or removed.
     • Whois records that have information that can not be validated may be frozen or held until it can be verified.
     • A standard format for Whois data must be developed.
     • A publicly available list of publicly available Whois servers must be available using a widely known and available resource
     • A Whois service that supports searching in the current architecture of distributed indices and separated registry and registrar services must be developed.
   • The Task Force endorses the following additional recommendations received throughout the consultative process;
     • Registrars must verify Whois data in a timely fashion when specific data accuracy issues are brought to their attention.
       1. Registrars must be allowed to charge for these services.
          • Potential implementations may include;
            • problem reporting fee
            • data inaccuracy correction fee
            • domain name "reconnection fee"
            • other?
          • Such fees are only appropriate in instances where Registrants have not tried to previously update their data prior to the filing of the problem report but were unsuccessful because of Registrar non-compliance with Section 3.2.2 of the Registrar Accreditation Agreement (http://www.icann.org/registrars/ra-agreement-17may01.htm#3.2.2)
       2. Registrars should be permitted to charge for all data verification activities.
       3. The GNSO should undertake the development of a policy that provides a mechanism to forgive the Redemption fee in cases where the registrant can ultimately verify the accuracy but had just been unavailable previously. It may also be appropriate to develop this through the implementation analysis process if applicable.
       4. ICANN should work with all relevant parties to continue to create its ongoing compliance program to ensure that contractual parties are meeting the WHOIS-related provisions of the present agreements. In developing such a program, ICANN should consider:
          • The resources assigned to manage this plan, including up front and careful consideration of the costs associated with implementing various recommendations for registrars and flexible options for registrars to implement the policies in a compliant manner;
          • The specific elements of compliance that the internet community is primarily concerned with;
            • measurement and reporting mechanisms that allow appropriate analysis of the effectiveness of this ongoing program including existing compliance assistance mechanisms such as ICANN's online Whois data inaccuracy reporting tools;
            • continued outreach to and education of affected stakeholders to ensure that existing requirements and obligations are understood and met and that new requirements are captured and appropriately dealt with. This effort should ensure that ICANN advisories related to this issue are specifically brought to the attention of newly accredited Registrars and that resources be made available to the Registrar community to ensure that the impact and scope of these obligations are apparent and understood.
            • requiring that informational resources be provided to new Registrants and brought to their attention via the registration agreement that all Registrants must agree to prior to the activation and renewal of their gTLD registration, based on a model version of materials, so that no registrar gains a competitive advantage from differential treatment of this requirement;
            • ongoing development and promotion of gTLD Registry, Registrar and Registrant best practices that foster the accuracy of the Registrant data contained in the Whois database

Summary and recommendations

The At-Large Advisory Committee would like to express appreciation for the difficult and time-consuming work that the Task Force has been doing.

However, we stress that trying to get accurate information from people who are not willing to provide it is a waste of time and effort. No automated verification scheme is able to tell between true data and plausible data, and thus such schemes would only have the effect of increasing the number of crimes such as identity theft and make reliable identification of actual fraudsters even more difficult.

Generic TLDs are a global resource which should be impartially accessible to registrants from all parts of the world. Verification schemes usually do not cover all parts of the world with the same effectiveness, and often information which may seem implausible to an American eye will be actually true; so these schemes must not be used to unfairly discriminate access to gTLDs depending on the registrant's country. Also, any communication with the registrant should happen in the registrant's own language; and the registrant should not be asked to bear the cost of verification activities, since they are not part of the service he is asking for, but rather of services desired by some third-party data users.

The actual feasibility of a verification scheme that meets these requirements, even after the data gathering activity made by the task force, is still unproven. For these reasons, we recommend against taking any action in this field at this stage.

We thus suggest that the focus of the work on Whois accuracy is shifted from how to force unwilling people to provide their true information to how to effectively allow registrants who want to provide true information to do so. There are a number of practical hurdles for any registrant to keep his/her data up to date, and removing these hurdles would prove much more beneficial to the overall accuracy of the Whois databases than going after an impossible and worrying dream of a global centralized control system over registrants' identities.

Finally, we note that the Registrar Accreditation Agreement provisions about data collection, display and accuracy requirements and their enforcement are clearly illegal, and thus void, in a number of jurisdictions.

Thus we recommend that ICANN suspends any enforcement of those provisions until the RAA and the related policies are amended so to comply with existing laws; as clearly and repeatedly exposed in writing and in person by a number of relevant public authorities, any other choice is likely to bring ICANN and involved registrars to litigation with registrants and with the Privacy Authorities in European and other countries.

A deeper analysis on the problem of Whois accuracy

We think that, to be able to solve a problem, you should first investigate the reasons why it happens. In this case, you could roughly divide the registrants whose data are inaccurate into four categories:

1. Those who purposely provide inaccurate data for fraudulent reasons.
2. Those who purposely provide inaccurate data to protect their privacy.
3. Those who mistakenly provide inaccurate data.
4. Those who provide accurate data at registration, but then fail to keep them up to date so that the information becomes inaccurate.

Until now, the general discussion on accuracy has been almost completely focused on the first category - and we think this is an error. The purpose of the Whois system is not to provide bullet-proof identification for those who register domains and operate services on top of them, but rather to provide quick contact information for those domain holders who want to be contacted. Turning the Whois system into a certified directory of domain name owners would go beyond its purpose and, as practice shows, is practically incompatible with its spirit and architecture.

Also, at the present state of technology and of operational practices, costs of very secure authentification of world-wide registrants for all domain name registrations would be high and would possibly destroy the domain name market as we know it today. We think it might be more cost-effective (and also more respectful of basic civil rights of people) to seek after fraudulent registrants once they actually commit a fraud, rather than to presume that all registrants are to commit frauds and so should be carefully screened in advance.

Finally, we point out that there is no verification system, other than requiring a person to physically show up and exhibit a secure proof of identity such as a passport or national ID document, that could tell between true personal data and plausible, but fake, personal data. If going down the path of imposing stricter and stricter checks on data as they are submitted by the registrant during the registration process, after spending lots of time and lots of money on them, we might actually discover that no benefit has arisen in terms of fraud prevention, but that the stricter checks have caused a huge increase in crimes like identity theft, which by the way are made easier by the very existence of the public and anonymously accessible Whois system.

Said this, we think that an increased accuracy in the Whois database, if limited to those registrants who actually agree to provide their data, would be highly desirable. This is why we think that future activities in the field of enhanced accuracy should not focus on the first category of the above list, but rather on the other three.

We will not discuss here the issue of privacy protection, which is the subject of another task force; we just stress that the overwhelming majority of those who purposely provide inaccurate data does so for privacy protection reasons, rather than for fraudulent intentions. Just allowing these people not to disclose their data to the public, but just to the registrar, would actually avoid most cases of wilful inaccuracy.

The third category is, according to our experience, somewhat small – also because this kind of error is clerical and can easily be fixed in case there is actual need to contact the owner. Once the registrant's desire to publish their data is ascertained, some simple automated verifications could be made by the registrar's system, to warn the registrant about possible errors.

However, creating an automatical verification algorithm for all countries and scripts of the world might prove very difficult and prone to errors for less common countries; the current practical examples only come from TLDs and environments with geographically limited registrants. On the other hand, systems which provide automatical verification only for residents of some countries could be acceptable only as long as they do not prevent or make it unreasonably harder for residents of “unverifiable” countries to register domains. This is why we think that the output of this automated verification algorithms should only be used as a warning to the registrant, but should not prevent the registrant from submitting data that might seem incorrect, as they could possibly be absolutely correct.

We also note that requiring Roman-script information for registrants of those countries who do not use Roman characters would be unduly discriminating them in access to gTLDs. All registrants should be asked to provide their data only in their local language and script, and just as an option they could be asked whether they want to provide Romanized data as well. Requiring the ability to type in Roman script to register domains in global generic TLDs is unacceptable.

Finally, we think that much could be done to improve the situation of the fourth category – those registrants who would be happy to provide accurate information, but who fail to keep it up to date. In fact, experience shows that updating Whois data is a long and difficult process for registrants. In many cases, the registrant has to send faxes, make phone calls, and suffer other costs while devoting a significant amount of time; in other cases, the authentication mechanism used by registries or registrars is based on the e-mail address (or on a username/password couple which, if forgot, will be resent to the current e-mail address), so that a change in the e-mail address of the registrant will make him/her unable to manage the information, and will make these domains orphan. If you add this to the fact that keeping personal data up to date in a public Whois registry certainly cannot be the first worry of a registrant when he's changing address, phone number or e-mail address, you realize that this is possibly the easiest cause of inaccuracy in Whois databases.

Also, in many cases the registrant is only the last link in a long chain of interactions that starts with a registry, then goes through an ICANN-accredited registrar, a domain name reseller, a web hosting company, or even an “Internet-savvy” friend who does the job for the registrant. We think that this is an unavoidable consequence of the average registrant turning from a skilled engineer in a small Internet, as it was when Whois was designed, to a non-technical average person in a mass Internet. It is very difficult to create the awareness of the existence and purpose of the Whois database for non-technical persons on a mass scale, and we think this is another reason why we should never expect the Whois to be a terribly accurate list of all registrants.

However, for this category the problem possibly lies in the lack of simple online systems for the registrant to edit his/her data in the database at no cost. Thus we think that one of the two following solutions should be tried:

1. Requiring registries to directly deal with registrants' update requests, by supplying them a virtual certificate or account at registration, plus offline procedures to recover access if such account is lost;
2. Changing the architecture of the Whois database from centralized to distributed.

Since the first option would raise many concerns in terms of business models, customer ownership, and cost recovery, the second could possibly be more interesting. After all, the very reason for which the DNS system was created, replacing the old centralized hosts table, was the impossibility of keeping this centralized table up to date. We should simply apply the same principle and move the data at the edge of the network, by embedding Whois servers into DNS server implementations. Whois queries could then be sent directly to the authoritative name servers for the domain, and only if no reply is received, the registry could be used as a fall-back. This way, registrants would be able to keep their Whois information up to date as easily as they keep their zone files up to date, and even if this would not completely solve the problem, it would possibly cause a dramatic increase in the number of Whois records that are actually kept updated.

We thus recommend a shift in the focus of accuracy-related discussions, so to deal with those types of inaccuracy that can and should actually be solved, rather than dealing with world-wide verification and law enforcement systems that are not practically conceivable at the present social and political state of our planet, and that would anyway have to be discussed at other political levels.

Input to the GNSO Council task forces on WHOIS - April 2004

In order to provide input to all three Task Forces (TF) and provide a broader statement from the Commercial and Business User Constituency (hereafter Business Constituency or BC), we have consolidated our input into a single document.

Members of the Business Constituency use the Internet to conduct business. The Business Constituency is a constituency representing customers of providers of connectivity, domain names, IP addresses, protocols and other services related to electronic commerce in its broad sense. The BC membership includes corporations, entrepreneurs, and associations.

The BC recognizes that the Internet is changing and evolving into a more commercial and widely used communication mechanism, and that the characteristics of the Internet users are also changing over time. It is generally agreed that more and more users are registering domain names for a wider and wider variety of purposes. As the user characteristics are changing and the Internet is growing, it is important to keep in mind the key issues of Internet stability. The BC believes that accurate WHOIS data is an essential element to that core value. In examining the possibility of changes in the WHOIS, the BC believes that better mechanisms are needed to ensure accurate WHOIS data, while balancing the needs of the full set of stakeholders and affected parties.

Principles for the use of WHOIS

Striking a balance among concerns and needs of the different stakeholders related to accuracy, reliability, access and privacy issues is the goal. This is consistent with the OECD Guidelines on the Protection of Privacy and Trans-border Data Flows of Personal Data, the international consensus, that works to strike a balance between effective privacy protection and the free flow of information.

Purposes of Business User access to WHOIS:

Business users access the WHOIS database to obtain registrant contact information for the following reasons:

1. to verify the availability of a name they might wish to register
2. to thwart security attacks of their networks and servers
3. to validate the legitimacy of a website for transactions
4. to identity consumer fraud and cyber-scam incidents
5. to undertake routine reviews to protect their brands
6. to support UDRP and other infringement proceedings
7. to combat spam.

The BC's guiding principles related to WHOIS are:

1. Accuracy and access. Accuracy and access to accurate data are the top priorities. Enforcement of accuracy requirements is essential.
2. Use of data. It is key to find a balance between data use for legitimate purposes and avoiding unwelcome or illegal use.
3. Balance of Stakeholder needs. Any changes in access to WHOIS must be balanced across the needs of all stakeholders and take into account the costs to the registries/registrars to maintain more complex systems, as well as the burden on the legitimate users of WHOIS.
4. Marketing. WHOIS data should never be used for marketing purposes. This includes precluding the use of WHOIS data for marketing by the registry or registrar other than for services that are directly applicable to registration or other purposes that are not inconsistent with the original purpose [see OECD Guidelines] or for which the registrant has explicitly opted-in.
5. Scope. The focus for now should be ensuring a consistent system of WHOIS across generic top-level domain names. Any discussion of WHOIS policies that might affect WHOIS within country-code domain names should be addressed later and through the new Country Code Names Supporting Organization.

Task Force 3: Mechanisms to improve quality of contact data

The BC notes:

• Accuracy because WHOIS is public communication. A domain name registration in a TLD is a public form of communication, and as such, requires accurate data for the WHOIS registry.
• Accuracy because users need accurate data. The average Internet user, whether business, government, NGO or individual, has an expectation of accurate WHOIS information, which they then use to address legitimate issues: verifying the legitimacy of a web site, pursuing a network problem, addressing IP infringement concerns, calling for assistance from law enforcement, etc.
• Accuracy is important for individuals and organizations. The same concerns about the need for accurate data are independent of the nature of the registrant. A non-statistical survey of BC members regarding the situations they have experienced with trademark infringements, consumer fraud, and network issues indicates that there are problems with individuals and with organizations. However, none of the consumer fraud incidents encountered by the well-known brand holders involved organizations. The five situations examined all involved individuals who provided false information. Discussions with law enforcement have and continue to evidence similar problems with individuals.
• Some examples of data authentication exist in other industries, including financial services and in some of the ccTLDs.

The BC therefore proposes:

• Best Practices are available from other sources: The BC recommends further examination of best practices in authentication in other industries and from selected ccTLDs.
• Changes to the contracts are needed to ensure there is enforcement. The requirement to provide accurate data is a part of the Registrar contract, yet it appears that few registrars fulfill this requirement. The BC believes that this must be enforced by ICANN while allowing flexibility in the way registrars carry out this obligation. The previous WHOIS TF discussed the development of graduated sanctions. They also heard from several ccTLDs with successful data verification practices. The BC calls for the development of policy to evaluate a system of graduated sanctions.

Recommendation: more research is needed, and standards may offer solutions to development of modifications to WHOIS. Discussion of WHOIS is limited by a lack of research which would allow fact based policy. The ccTLD registries also have significant experiences which could be the better understood and provide useful "understanding" to guide gTLD policy development. The BC encourages the GNSO Council to seek current information on both the CRISP project (on WHOIS standards undertaken by the Internet Engineering Task Force) and any other relevant standards process, to examine the role of these potential standards in providing a solution. The BC recognizes that the cost of implementing changes in WHOIS must be analyzed and understood as changes are considered. Changes in WHOIS should not become an "unfunded mandate" upon registrars.

This statement responds to the issue identified in the purpose statement of the terms of reference for Task Force 3: see http://gnso.icann.org/issues/whois-privacy/tor3.html.

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

IPC’s recommendations for improvement of data quality include the following:

– ICANN should work with all relevant parties to create a uniform, predictable, and verifiable mechanism for ensuring compliance with the WHOIS-related provisions of the present agreements, and should devote adequate resources to such a compliance program. The Registrar Accreditation Agreement makes the requirements clear. See http://gnso.icann.org/issues/whois-privacy/raa-whois-16dec03.shtml. However, this agreement is only as good as the level of compliance with it, and recent decisions by US courts indicate that only ICANN can enforce these agreements. See Register.com v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004).

– ICANN should ask each registrar to present a plan, by a date certain, for substantially improving the accuracy of Whois data that it collects. The plans will be made publicly available except to the extent that they include proprietary data. The plans should include at least the following features:

– identification and public disclosure of a contact point for receiving and acting upon reports of false Whois data;

• how the registrar will train employees and agents regarding the Whois data accuracy requirements;
• how the registrar will take reasonable steps to screen submitted contact data for falsity, which steps may include use of automated screening mechanisms, manual checking, including spot-checking, and verification of submitted data;
• when false data comes to the registrar's attention, whether through a third-party complaint or otherwise, how the registrar will treat other registrations in which the contact data submitted is substantially identical to that in the registration that has come to the registrar's attention;
• how the registrar monitors the extent to which contact data submitted to it through re-sellers or other agents is false or significantly incomplete, and what the consequences are for re-sellers or agents whose performance is unacceptable;
• how the registrar evaluates compliance by its current registrants with the obligation to provide accurate and current contact data;

– how the registrar measures performance in improving the quality of the Whois data it manages

– The RAA and gTLD registry agreements should be modified to provide for a regime of graduated or intermediate sanctions for patterns of violations by a registrar of the Whois data accuracy obligations of those agreements. (This recommendation is without prejudice to the possibility that such a regime would also be appropriate for encouraging compliance with other provisions of these agreements.)

– The PDP with regard to the issues addressed by TF3 should mutate into an ongoing effort with the following goals:

• Research and dissemination of information on practicable and cost-effective methods used to improve the quality of identifying and contact data submitted by customers in online transactions outside the realm of gTLD domain name registration
• Development of best practices within the realm of gTLD domain name registration for improving the accuracy, currentness, and reliability of contact data in the Whois database

Introduction

The ISPCP Constituency herein provides input to the three Whois Task Forces as required by ICANN by-laws. The ISPCP stresses the need for balanced policy that takes into consideration the interests of all stakeholders, and allows for the effective enforcement of civil and criminal laws while protecting registrant information from marketing or other illegitimate/illegal uses. This goal is the underlying theme running throughout the comments below. It is also consistent with commonly accepted tenets of privacy protections and laws throughout the world.

ISPCP Uses of Whois Data

1. to research and verify domain registrants that could vicariously cause liability for ISPs because of illegal, deceptive or infringing content.
2. to prevent or detect sources of security attacks of their networks and servers
3. to identify sources of consumer fraud, spam and denial of service attacks and incidents
4. to effectuate UDRP proceedings
5. to support technical operations of ISPs or network administrators

Terms of Reference for Whois Task Forces

WHOIS Task Force 3

– Focused on developing mechanisms to improve the quality of contact data that must be collected at the time of registration in accordance with the registrar accreditation agreement and the relevant registry agreement

– Related issues:

• Verification of data at time of registration
• Ongoing maintenance of data during registration period
• Protecting against deliberate submission of false information

ISPCP Position

Task Force 3 - Improving Accuracy of Collected Data

Finally, the ISPCP Constituency is quite concerned about the abundance of inaccurate and incomplete data. Such deficiencies significantly hinder ISPs' ability to identify and contact registrants. Thus, ISPs support ready access to accurate Whois data to facilitate resolution of network problems, sourcing of spam. Further, ready access to accurate data is necessary for securing our networks and enforcing our acceptable use policies.

Because of the heavy reliance by ISPs on registrants’ data to facilitate future contact with the registrant for business issues, security and stability issues, intellectual property infringement and a myriad of other legal issues, accuracy is of the utmost importance.

While automated verification software does exist, its accuracy and therefore its reliability on a global scale is suspect. Registrars should take multiple steps to ensure that the data they receive is accurate, and there should be some enforcement mechanism to ensure registrars’ compliance. In addition, it would be useful for registrars to have a list of best practices that further help verify data and produce an accurate database.

The ISPCP Constituency proposes:

• The creation of a best practices document aimed to improve data verification, with the prospect of a global application.
• Registrars take increased and more uniform measures to verify accurate data. The ISPCP does not advocate removing all flexibility from current or future registrar practices, but some uniformity and compliance with best practices will net a more accurate database.
• 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.

NCUC STATEMENT FOR WHOIS TASK FORCE 3

WHOIS Task Force 3 (TF3) deals with the accuracy of WHOIS data, established to determine the best mechanisms to improve the quality of the data. The Non-Commercial Users Constituency (NCUC) approach to Task Force 3 is guided by the following principles:

– First, the NCUC does not believe that accuracy of WHOIS data is unconditionally desirable. These task forces were established with the assumption for task force 3 that accuracy is desirable in all cases and regardless of the extent of the WHOIS data elements. The NCUC recognizes the need to protect such extensive and public data from identity theft and spam and to protect freedom of speech. Submission of personally identifiable contact data should be a choice, not a requirement. Many people are indeed forced to enter incorrect data in order to protect themselves.

– Second, the NCUC thinks it imperative that ICANN recognize the well-established data protection principle that the purpose of data and data collection processes must be well-defined before policies regarding its use and access can be established. The purpose of WHOIS originally was identification of domain owners for purposes of solving technical problems. The purpose was _not_ to provide law enforcement or other self-policing interests with a means of circumventing normal due process requirements for access to contact information. None of the current WHOIS Task Forces are mandated to revise the purpose. Therefore, the original purpose must be assumed until and unless ICANN initiates a new policy development process to change it.

– Third, registrants should be allowed to protect their personally identifiable information, a protection recognized by the European Data Protection Directive, Article 29 Working Party, by the OECD Privacy Guidelines and by data protection legislation across the world. As George Papapavlou and Giovanni Buttarrelli pointed out, it is possible that WHOIS data accuracy requirements may indeed be breaking many of these laws. The NCUC submits that accuracy is desirable solely to the extent necessary to serve the purpose of the data collection and the interest of the data subject; accordingly, technical information should be accurate. However, there should be no penalization for inaccurate data entry given that the extent and the accessibility of the data currently required goes well beyond the purpose of data collection. As Papapavlou discussed, when there are various options to achieve a purpose, priority must be given to the least privacy-intrusive option.

– Fourth, while this task force was established with privacy defined as out of scope, privacy is key to accuracy of data entry. Data protection principles have to be implemented and enforced as a whole. The best way to improve the accuracy is to provide privacy and security. Show registrants that their data will be safeguarded, that their e-mail accounts will be protected from spam and that they themselves will be protected from stalkers and other criminals, and they will be more likely to enter accurate data. Users will continue to feel the need to protect their privacy by their own means, to defend themselves, if the policies of WHOIS data do not.

– Finally, if there is a way to facilitate accuracy of data for those who wish to submit accurate data, in other words opt-in, the NCUC would be supportive. We are against, however, calls to require accurate data entry and penalize or even criminalize those who choose not to. This task force has reached out to various companies in order to collect data on verification procedures, but has found this process difficult (ironically, because companies are concerned with the privacy of their policies and procedures). The responses submitted to the TF3 questionnaire are sparse. We do not have enough data to allow Task Force 3 to reach any conclusion of best practices for verifying accuracy. However, this Task Force has received testimony that domain name holders in numerous cases are having a very difficult time updating, revising and changing their own data. This is currently the most important issue facing the task force: that the data subjects themselves cannot update their domain name information. Further, it is a violation of the EU Privacy Directive. Accordingly, this TF must first take on clear proposals for revisions of the procedures by which registrars, thick registries, and resellers handle instructions from domain name holders to update and/or correct domain name data. These procedures must include: clear instructions to domain name holders on how to update their information; special email addresses for expedited and priority handling of such updates; and TF3-proposed revisions to the Registrars Accreditation Agreement to insure that the EU Privacy Directive rules on the ability of domain name holders to update and policy the accuracy of their own data is ensured and followed.

Overview

This document responds to the call for submissions from the GNSO Names Council Whois Task Force 3: Whois Data Accuracy and the issues identified within the terms of reference for this task force.

This task force has been specifically requested to:

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

Response

The issue of a useful and sustainable model for appropriate access to registrant data via publicly accessible means continues to be a primary concern for the ICANN GNSO Registrar Constituency. Registrar Constituency membership are the primary caretakers of Whois access and Whois data in the gTLD namespace and have a vested interest in ensuring that it is responsibly administered within the bounds of appropriate public policy as established by ICANN.

The Registrar Constituency started formulating its position on Whois during its formative year in 1999 with a request to the ICANN Board of Directors to ensure that the public Whois service located at http://rs.internic.net remained accessible to all members of the public and did not become a specialized marketing vehicle for specific corporate interests. The Constituency position continues to grow in conjunction with its examination and discussion of the issues with the DNSO/GNSO and larger internet community.

This dialogue will continue to be important as long the internet community requires access to registrant data via publicly accessible means. The Constituency views this dialogue as an imperative component in its ongoing decisions of how to best operate this important resource in a manner that balances the interests of stakeholders in accordance with established ICANN policy. In this regard, the primary interest of Registrars is that of commercial implementer, operator and caretaker.

Balancing the interests of those who require access to accurate data and those obligated to maintain accurate data is neither an easy nor a forgiving task. On one hand, we have to satisfy those actors who legitimately require immediate access to accurate registrant data to protect the rights or assets of public and private interests from infringement or misappropriation by third parties. On the other, Registrars must be concerned with the contractual rights and obligations of those parties responsible for maintaining the accuracy of the registrant data and also those of the registrants.

The current body of policy allows Registrars to uphold their obligations in a responsible manner that does not impinge the contractual rights or obligations of other parties to these agreements. This capability is clouded by the lack of available data regarding some of the more recently enacted elements of the policy, notably the Whois Data Reminder Policy. Further, it is unclear whether or not the appropriate measurements are being taken or what reporting mechanisms exist. Timely measurement and reporting is a prerequisite to the ICANN community gauging the effectiveness and scalability of the policy it enacts.

The Registrar Constituency is a broad and diverse group of commercial providers. Registrar firms come from all parts of the world , operate in many different languages and cater to their chosen markets with every imaginable business model. Not only are Accredited Registrars required to abide by the terms of their contracts with ICANN, but also by the laws that they operate under. Resolving the conflicts between law and contracts, language, culture and differing business models is a daunting task. The Constituency recognizes that more work is required to ensure that all Registrars are equitably applying existing policy while ensuring that the competitive diversity of its Membership is fostered and promoted. ICANN's ongoing program of compliance and education is one such example of positive efforts in this direction. These programs are a necessary element of ICANN's function and its efforts should receive the full support of the community.

To these ends, the Registrar Constituency makes the following submissions to the ICANN GNSO Names Council Whois Task #3, Whois Data Accuracy.

Submission

1. The Constituency recommends that ICANN continues to develop its ongoing compliance plan to ensure that contracted parties are appropriately meeting their obligations under the various agreements.

   Specific attention must be paid to;

   • the resources assigned to managing this plan;
   • the specific elements of compliance that the internet community is primarily concerned with;
   • development and implementation of a graduated scale of sanctions that can be applied against those who are not in compliance with their obligations or otherwise infringing the contracted rights under these agreements;
   • Measurement and reporting mechanisms that allow appropriate analysis of the effectiveness of this ongoing program with specific attention paid initially to existing compliance assistance mechanisms such as ICANN's online Whois data inaccuracy reporting tools;
   • Continued outreach to and education of affected stakeholders to ensure that existing requirements and obligations are understood and met and that new requirements are captured and appropriately dealt with. This effort should ensure that ICANN advisories related to this issue are specifically brought to the attention of newly accredited Registrars and that resources be made available to the Registrar community to ensure that the impact and scope of these obligations are apparent and understood. Similar resources should be made available to new Registrants and brought to their attention via the registration agreement that all Registrants must agree to prior to the activation of their gTLD registration;
   • Ongoing development and promotion of gTLD Registry, Registrar and Registrant best practices that foster the accuracy of the Registrant data contained in the Whois database
2. The Constituency further recommends that ICANN does not ratify any policy related to Whois data accuracy that alters the balance of rights and obligations found in current policy.
3. Finally, the Constituency recommends that a specific examination of Registrar data collection and protection practices be undertaken by the GNSO Council (or another appropriate body) in order that the GNSO community has sufficient and appropriate appreciation of the policy implications of the various data protection regulations in effect in the various jurisdictions that Registrars operate.

Below is the Registry Constituency response to the call for submissions from the GNSO Names Council Whois Task Force 3: Whois Data Accuracy and the issues identified within the terms of reference for this task force.

This task force has been specifically requested to:

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

The gTLD Registry Constituency arrived at the positions described in this statement primarily through email discussions occurring from February through April 2004 supplemented to a small degree by discussions occurring as part of agendas for the in-person constituency meeting in Rome on 2 March 2004 and regular constituency teleconference meetings during March and April 2004. All constituency registry members were included in email discussions on the constituency list.

Financial Impact

Financial impact to registries of changes to Whois requirements would vary depending on what the nature of the changes are, what implementation time frames are required, etc. Until specific requirements are defined, it is not possible to quantify financial impact.

Implementation Timeframe Estimates

Because so many applications rely on Whois information, advance notice must be provided to the community at large to allow sufficient time for such applications to be modified to accommodate changes. Because of the widespread global use of Whois information, it is not unreasonable to expect that at least six months notice should be given to the Internet community for any significant changes.

Constituency Comments

We recommend that, with respect to Registrant contact data, any verification mechanisms which may be implemented in the future should be implemented at the registrar level. This enhances effective communication with the registrant and allows for a more efficient methodology for correction of any inaccurate information by the registrant.

Implementation of any data verification schemes should to be done on a “global basis” and not be applied to any gTLD on a country-by-country basis.

We concur with previous recommendations that an in-depth examination of Registrar data collection and protection practices be undertaken by the GNSO Council (or another appropriate body) in order that the GNSO community can accurately discern policy implications of the various data protection regulations in effect in various registrant jurisdictions.

We recognize that until the concerns of privacy are adequately dealt with on a regional and international basis, it will be very difficult to resolve the Whois data accuracy problem. In this regard, the gTLD Registry Constituency strongly recommends that this fact be recognized and that a concerted effort be made to address it. Until that is done, regardless of what mechanisms are put in place to improve accuracy, individuals concerned about privacy and registrars and registries operating in jurisdictions with strict privacy regulations will find ways to protect privacy, which may work against steps to improve accuracy.

One way to implement, from a technical perspective, the policy objectives of achieving accurate WHOIS information, while at the same time balancing the appropriate privacy interests, may be through the nearly completed IRIS protocol being developed by the CRISP working group. Once finalized, we recommend that ICANN comprehensively evaluate such protocol.

Summary of Task Force 3 Public Comments