ICANN has published a DRAFT of final report of the “Whois Policy Review Team’s”, whose mission was to “review the extent to which ICANN’s Whois policy and its implementation are effective, meet the legitimate needs of law enforcement, and promote consumer trust.”
“Comprehensive and straightforward, the report lays out systematically what the team found lacking with Whois policy and what they think should be done about it.”
Here are the recommendations from the DRAFT final report:
Single WHOIS Policy
1. ICANN’s WHOIS policy is poorly defined and decentralized The ICANN Board should oversee the creation of a single WHOIS policy document, and reference it in subsequent versions of agreements with Contracted Parties. In doing so, ICANN should clearly document the current gTLD WHOIS policy as set out in the gTLD Registry and Registrar contracts and GNSO Consensus Policies and Procedure.
Policy review – WHOIS Data Reminder Policy
2. The ICANN Board should ensure that the Compliance Team develop, in consultation with relevant contracted parties, metrics to track the impact of the annual WHOIS Data Reminder Policy (WDRP) notices to registrants. Such metrics should be used to develop and publish performance targets, to improve data accuracy over time. If this is unfeasible with the current system, the Board should ensure that an alternative, effective policy is developed and implemented in consultation with registrars that achieves the objective of improving data quality, in a measurable way.
3. ICANN should make WHOIS a strategic priority. This should involve allocating sufficient resources, through the budget process, to ensure that ICANN compliance staff is fully resourced to take a proactive regulatory role and encourage a culture of compliance. The Board should ensure that a senior member of the executive team is responsible for overseeing WHOIS compliance.
4. ICANN should ensure that WHOIS policy issues are accompanied by cross-community outreach, including outreach to the communities outside of ICANN with a specific interest in the issues and an ongoing program for consumer awareness.
- ICANN should take appropriate measures to reduce the number of unreachable WHOIS registrations (as defined by the NORC Data Accuracy Study, 2009/10) by 50% within 12 months and by 50% again over the following 12 months.
- ICANN shall produce and publish an accuracy report focused on measured reduction in “unreachable WHOIS registrations”, on an annual basis.
- ICANN should provide at least annual status reports on its progress towards achieving the goals set out by this WHOIS Review Team, published by the time the next WHOIS Review Team starts. This report should include tangible, reliable figures needed.
- ICANN should ensure that there is a clear, unambiguous and enforceable chain of contractual agreements with registries, registrars, and registrants to require the provision and maintenance of accurate WHOIS data. As part of these agreements, ICANN should ensure that clear, enforceable and graduated sanctions apply to registries, registrars and registrants that do not comply with its WHOIS policies. These sanctions should include de-registration and/or de-accreditation as appropriate in cases of serious or serial non-compliance.
- ICANN should ensure that the requirements for accurate WHOIS data are widely and pro-actively communicated to current and prospective Registrants. As part of this
effort, ICANN should ensure that its Registrant Rights and Responsibilities document is pro-actively and prominently circulated to all new and renewing registrants.
Data Access – Privacy Services
- ICANN should develop and manage a system of clear, consistent and enforceable requirements for all privacy services consistent with national laws. This should strike an appropriate balance between stakeholders with competing but legitimate interests. At a minimum this would include privacy, law enforcement and the industry around law enforcement.
- WHOIS entry must clearly label that this is a private registration
- Privacy services must provide full contact details as required by the WHOISwhich are available and responsive as required by the framework mentionedabove.
- Standardized relay and reveal processes and timeframes.
- Rules for the appropriate level of publicly available information on theregistrant
- Maintenance of a dedicated abuse point of contact for the privacy serviceprovider
- Privacy service provider shall conduct periodic due diligence checks onregistrant contact information
- ICANN should develop a graduated and enforceable series of penalties for privacy service providers who violate the requirements with a clear path to de-accreditation for repeat, serial or otherwise serious breaches.
Data Access- Proxy Service
- ICANN should facilitate the review of existing practices by reaching out to proxy providers to create a discussion that sets out current processes followed by proxy service providers.
- Registrars should be required to disclosure their relationship with any Affiliated Retail proxy service provider to ICANN.
14. ICANN should develop and manage a set of voluntary best practice guidelines for 10
appropriate proxy services1 consistent with national laws. These voluntary guidelines should strike an appropriate balance between stakeholders with competing but legitimate interests. At a minimum this would include privacy, law enforcement and the industry around law enforcement.
Such voluntary guidelines may include:
- Proxy services provide full contact details as required by the Whois
- Publication by the proxy service of its process for revealing and relaying information
- Standardization of reveal and relay processes and timeframes, consistent withnational laws
- Maintenance of a dedicated abuse point of contact for the proxy service provider
- Due diligence checks on licensee contact information.15. ICANN should encourage and incentivize registrars to interact with the retail service providers that adopt the best practices.
16. For the avoidance of doubt, the WHOIS Policy, referred to in Recommendation 1 above, should include an affirmative statement that clarifies that a proxy means a relationship in which the Registrant is acting on behalf of another. The WHOIS data is that of the agent, and the agent alone obtains all rights and assumes all responsibility for the domain name and its manner of use.
Data Access – Common Interface
1 As guidance to the Community and as useful background for the Proxy Service Recommendations, the Review Team provides its working definitions of proxy service and different types of proxy service providers:
– Proxy Service – a relationship in which the registrant is acting on behalf of another. The WHOIS data is that of the agent and the agent alone obtains all rights and assumes all responsibility for the domain name and its manner of use.
– Affiliated Registrar – another ICANN accredited registrar that operates under a common controlling interest (2009 Registrar Accreditation Agreement, Section 1.20)
– Affiliate retail proxy service provider – entity operating under a common controlling interest of a registrar.
– Retail proxy service provider – proxy service with little or no knowledge of the entity or individual requesting the service beyond their ability to pay and their agreement to the general terms and conditions.
– Limited proxy service provider – proxy service for an entity or individual in which there is an ongoing business relationship bound by a contract that is specific to the relationship.
17. To improve access to the Whois data of .COM and .NET gTLDs, the only remaining Thin Registries, ICANN should set up a dedicated, multilingual interface website to provide thick WHOIS data for them.
ALTERNATIVE for public comment:
To make WHOIS data more accessible for consumers, ICANN should set up a dedicated, multilingual interface website to allow “unrestricted and public access to accurate and complete WHOIS information”. Such interface should provide thick WHOIS data for all gTLD domain names.
Internationalized Domain Names
- ICANN Community should task a working group within 6 months of publication to finalize (i) encoding, (ii) modifications to data model, and (iii) internationalized services, to give global access to gather, store and make available internationalized registration data. Such working group should report no later than one year from formation, using existing IDN encoding. The working group should aim for consistency of approach across the gTLD and – on a voluntary basis – the ccTLD space.
- The final data model and services should be incorporated and reflected in Registrar and Registry agreements within 6 months of adoption of the working group’s recommendations by the ICANN board. If these recommendations are not finalized in time for the next revision of such agreements, explicit placeholders for this purpose should be put in place in the agreements for the new gTLD program at this time, and in the existing agreements when they come up for renewal (as is the case for adoption of consensus policies).
- Requirements for registration data accuracy and availability in local languages should be finalized (following initial work by IRD-WG and other similar efforts, especially if translation or transliteration of data is stipulated) along with the efforts on internationalization of registration data. Metrics should be defined to measure accuracy and availability of data in local languages and (if needed) corresponding
data in ASCII, and compliance methods and targets should be explicitly defined accordingly.