Dear Team members, Thank you, again, for participating in this conference call with ICANN Staff. Below, and attached, is a summary of the Team's recommendations to help facilitate our discussion. Regards, Denise Denise Michel ICANN Advisor to the President & CEO denise.michel@icann.org +1.408.429.3072 mobile +1.310.578.8632 direct *WHOIS Policy Review Team Draft Report Recommendations* *Single WHOIS Policy* 1) ICANN's WHOIS policy is poorly defined and decentralized; Team recommends Board oversee creation and publication of a single WHOIS policy document; include gTLD WHOIS policy in Registry & Registrar contracts, GNSO consensus policies & procedures. *Policy Review – WHOIS Data Reminder Policy (WDRP)* 2) Board should ensure that Compliance develops metrics to track impact of annual data reminder notices to registrants, and that these metrics be used to develop and publish performance targets to improve data accuracy over time (if not feasible, develop & implement an alternative policy). *Strategic Priority* 3) ICANN should make WHOIS a strategic priority, allocate sufficient resources to ensure Compliance is fully resourced to take a proactive regulatory role, encourage a culture of compliance; Board should ensure a senior member of the executive team is responsible for overseeing WHOIS compliance. *Outreach* 4) ICANN should ensure that WHOIS policy issues are accompanied by cross-community outreach, including outreach to interested communities outside of ICANN. *Data Accuracy* 5) ICANN should take appropriate measures to reduce the number of unreachable WHOIS registrations (as defined by the 2010 NORC Data Accuracy Study) by 50% within 12 months and by 50% again over the following 12 months. 6) ICANN shall publish annually an accuracy report on measured reduction in “unreachable WHOIS registrations.” 7) ICANN should publish status reports (at least annually) (with figures) on its progress towards achieving goals set out by the Team, the first to be issued before next review. 8) 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 this, ICANN should ensure that clear, enforceable and graduated sanctions apply to Registries, Registrars, Registrants that don’t comply with WHOIS policies, including de-registration and/or de-accreditation for serious or serial non-compliance. 9) ICANN should ensure that requirements for accurate WHOIS data are widely and pro-actively communicated to current and prospective registrants, and should ensure that its Registrant Rights and Responsibilities document is pro-actively, prominently circulated to all new and renewing registrants. *Data Access – Privacy Services* 10) ICANN should develop and manage a system of clear, consistent and enforceable requirements for all privacy services consistent with national laws, balancing between stakeholders with competing but legitimate interests, including, at a minimum, privacy, law enforcement and industry around LE. These should include: WHOIS entry must clearly label that this is a private registration; privacy services must provide full contact details as required that are available and responsive (see above); standardized relay and reveal processes and timeframes; rules for the appropriate level of publicly available information on the Registrant; maintenance of a dedicated abuse point of contact for the privacy service provider; privacy service provider shall conduct periodic due diligence checks. 11) 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 *Data Access - Proxy Services* 12) 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 these providers. 13) Registrars should be required to disclose to ICANN their relationship with any Affiliated Retail proxy service provider. 14) ICANN should develop a set of voluntary best practice guidelines for appropriate proxy services consistent with national laws, striking a balance between stakeholders with competing but legitimate interests, including, at a minimum, privacy, law enforcement and industry around LE. Voluntary guidelines may include: proxy services provide full contact details as required; publication by the proxy service of its process for revealing and relaying information; standardization of reveal/relay processes & timeframes, consistent with national 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) The published WHOIS Policy 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* 17) To improve access to the WHOIS data of .COM & .NET gTLDs (the Thin Registries), ICANN should set-up a dedicated, multilingual interface website to provide thick WHOIS data for them. (An “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” to provide thick WHOIS data for all gTLD domain names. *Internationalized Domain Names* 18) The ICANN Community should task a working group (WG) 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 WG should report no later than one year from formation, using existing IDN encoding. The WG should aim for consistency of approach across gTLDs and – on a voluntary basis – the ccTLD space. 19) The final data model and services should be incorporated and reflected in Registrar and Registry agreements within 6 months of adoption of the WG’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 case for adoption of consensus policies). 20) Requirements for registration data accuracy and availability in local languages should be finalized (following initial work by IRD-WG and 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.