Registrars, Whois TF3 is voting on the following "best practices" during the next 24 hours. I do not believe that these recommendations are fully formed, nor that the report is complete. The proposal includes several last minute additions by the chair (Brian Darville, IPC) that were not discussed by the task force. Despite my best efforts, I have been unable to convince the chair that this is an unfinished proposal and he is pushing forward with a vote on these statements for inclusion into the Preliminary Report of the task force. Once they have been included in the Preliminary Report, the report will be published for Public Comment. It is not clear whether or not we will have the opportunity to revise these proposals before they are taken to a vote of the GNSO Council. Unless I hear otherwise, I will be voting "no" on each recommendation in this proposal for the reasons outlined above (I'd be happy to clarify further if anyone is *really* interested.) I apologize for the short-time frame for review that this time-frame gives you, but this is what I have been given to work with and is generally indicative of the quality of the processes employed by this task force. Comments welcomed here or in private email (or call if you are feeling chatty :-) ---- 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 list of preliminary recommendations relating to best practices, which are set forth below. 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. 2) In developing such a program, ICANN should consider: a) 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; b) The specific elements of compliance that the internet community is primarily concerned with; c) development and implementation of 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; d) 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; e) 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. f) 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; g) 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 3) 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. 4) 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. 5) ICANN should also consider including the last verified date" and "method of verification" as Whois data elements, as recommended by the Security and Stability Advisory Committee. See Whois Recommendation of the Security and Stability Advisory Committee, available at http://www.icann.org/committees/security/sac003.htm. (“Whois data must contain a "Last Verified Date" that reflects the last point in time at which the information was known to contain valid data. It must also contain a reference to the data verification process.”). 6) With input from the relevant contracted parties and other interested stakeholders, ICANN should solicit direct input from each registrar relating to its current level of compliance with existing agreements, and plans to improve the accuracy of Whois data that it collects. The plans will be made publicly available except to the extent that they include proprietary data, and registrars that fail to submit plans by a date certain would be publicly identified. The plans should state specific steps for improving WHOIS data accuracy, including: • Identification and public disclosure of a designated contact point for receiving and acting upon reports of false Whois data; o Plans to work with ICANN to train employees and agents regarding the Whois data accuracy requirements; o 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; • 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; o Steps to improve the accuracy of contact data submitted to it through re-sellers or other agents o Measurements for improving performance of the quality of the registrar’s Whois data 7) ICANN should require domain name registrants to update and correct Whois data on an annual basis including, for example, clear instructions to domain name registrants of this obligation and special email addresses for expedited and priority handling of such updates. 8) ICANN should consider requiring Registrars to verify at least two of the following three data elements provided by domain name registrants – phone, facsimile and email – and ensure that these elements function and that the Registrar receives a reply from these means of communication. Where none of the three data elements works, than 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. 9) Where a domain name registration is cancelled due to the non-functionality of WHOIS data elements – phone, facsimile, and email – the domain name can be reconnected for a fee to be set by the registrar. Upon reconnection of any domain name in circumstances where the domain name had been placed on hold or was immediately cancelled, the Registrar shall verify all data elements before reconnecting the domain name. The Registrar should ensure that the reconnection charge it imposes is sufficient to cover the costs of the heightened verification it must perform in reconnecting a previously cancelled domain. 10) 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. -- -rwr "Don't be too timid and squeamish about your actions. All life is an experiment. The more experiments you make the better." - Ralph Waldo Emerson Got Blog? http://www.blogware.com My Blogware: http://www.byte.org