Dear WHOIS Policy Review Team:
This email responds to the WHOIS Policy Review Team's request that ICANN Staff provide input on clarifications and potential paths to implementation for the Review Team's draft Recommendations. A cross-functional ICANN Staff group is reviewing the draft recommendations and offers the following initial input for the Review Team's consideration.
Recommendation 1. Single WHOIS Policy -- ICANN's WHOIS policy is poorly defined anddecentralized; 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.
Staff understands the Review Team’s intention to be collection and posting of all current gTLD WHOIS policies and procedures, and can implement the Recommendation expeditiously.
Recommendation 2. Policy Review – WHOIS Data Reminder Policy (WDRP) -- 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).
As Staff recently discussed with the Review Team, the Recommendation may be based on a misunderstanding of the WDRP requirements, as ICANN currently has no contractual authority to require registrars to track changes or provide ICANN with the necessary data for the recommended metrics. Staff is exploring ways to help achieve significant improvements in gTLD WHOIS accuracy. Potential paths to implementation include: changes to the Registrar Accreditation Agreement (RAA), which is currently under negotiation; adoption by Registrars of best practices that improve WHOIS accuracy; and/or creation of a new GNSO consensus policy that modifies the WDRP or creates a new policy to achieve improvements in WHOIS accuracy. In addition, ICANN is involving additional levels of management in this area, increasing Compliance staffing levels, and building additional compliance tools. Staff is also assessing the costs and utility of measuring WHOIS accuracy on an annual basis, so that efforts to improve accuracy can be measured systematically over time, using a clear baseline to assess the effectiveness of enhancements that may be implemented.
Based on feedback from the Review Team, the 2011 WDRP audit questionnaire (the audit was conducted in early 2012) was amended to obtain information from registrars on how they verify WHOIS contact information upon registration and on an on-going basis. The audit results will be published soon to inform policy debate on effectiveness of the WDRP and WHOIS metrics.
Recommendation 3. Strategic Priority -- ICANN should make WHOIS a strategic priority, allocate sufficient resources to ensure Compliance is fully resourced to take a proactive regulatory role, and encourage a culture of compliance; Board should ensure that a senior member of the executive team is responsible for overseeing WHOIS compliance.
Staff agrees that WHOIS is a strategic priority and designating a senior member of the executive team to be responsible for overseeing WHOIS is feasible. With input from the community and guidance from the Board, Staff develops ICANN's strategic plans and fiscal year budgets for Board approval, and WHOIS remains a strategic priority that has been allocated increased resources. This annual budget development process would be followed to maintain this priority and budgetary support. In October 2010, ICANN's John Jeffrey,ICANN’s General Counsel and Secretary assumed responsibility for overseeing the Compliance function. Mr. Jeffrey is an Officer of ICANN and is a senior member of ICANN’s Executive Team. The General Counsel oversees three distinct departments, Board Support, Compliance and Legal. They have separate managers but report to the executive team through Mr. Jeffrey. Staff understands the phrase “proactive regulatory role” to mean that Compliance and its Executive leader should be taking the initiative to identify and vigorously address contract violations, focusing on the most serious in a systematic and rigorous way, and is committed to doing so.. ICANN is increasing staff levels and creating new tools to assist in identifying contract violations more effectively.
Recommendation 4. Outreach -- ICANN should ensure that WHOIS policy issues are accompanied by cross-community outreach, including outreach to interested communities outside of ICANN.
Staff would welcome additional guidance from the Team on its recommended outreach goals and targets. The Recommendation seems consistent with ICANN’s current global outreach strategies – including new initiatives for Stakeholder outreach, Compliance’s new outreach efforts, and the outreach required in the GNSO's new policy development process (PDP) – and it can be implemented expeditiously. Staff also agrees that outreach to additional stakeholders, such as national data protection authorities and consumer communities is both valuable and feasible.
Recommendation 5. Data Accuracy -- 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.
Staff is pursuing the goal of increased WHOIS accuracy, and exploring new approaches to working with contracted parties outside the confines of the contract to increase WHOIS accuracy. It would be useful to have more information from the Team on the Recommendation to enable Staff to further investigate public policy, legal issues and implementation options. In particular, clarification on the following elements of the Recommendation would be helpful:
· It is Staffs understanding that the Team means “undeliverable” (there is no way to reach the registrant) when it uses the term “unreachable” in the Recommendation. In determining whether a registrant cannot be reached, the legal and privacy implications would need to be fully explored.
· Does the Team intend for Staff to determine the extent of a study based on what is a statistically valid sample size given the overall market? The NORC Accuracy Study involved a sample size of 1400 registrations, and cost ICANN approximately US$200,000.
· What level of accuracy is desired? Achieving 100% accuracy may involve intrusive verification methods that can raise privacy and cost concerns, and might be better addressed through a policy development process (PDP) that could solicit the input of the community.
Advancing the goal of the Recommendation is feasible, assuming that the RAA can be amended through the negotiations underway or through a GNSO PDP. Amending the RAA to include additional accuracy or verification requirements is important because the current RAA does not require registrars to verify a registrant’s WHOIS information at the point of registration. Improving accuracy is a key ICANN request in the ongoing negotiations with registrars to amend the RAA. In these negotiations, ICANN has proposed including an appendix to the RAA that commits registrars to enhancing WHOIS accuracy through various phases, including gradual improvements that can be updated from time to time. Should these WHOIS verification obligations not be included in the amended RAA, a GNSO PDP would need to be initiated to create appropriate consensus policies to be enforceable on the registrars. Consultations with the GNSO constituencies, especially the registrars, on the Recommendation would be helpful.
Recommendation 6. & 7. Data Accuracy -- ICANN shall publish annually an accuracy report on measured reduction in “unreachable WHOIS registrations.” ICANN shall 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.
As noted above, Staff is pursuing the goal and is investigating the public policy, legal issues and implementation options available to improve accuracy. ICANN is reviewing how to report WHOIS inaccuracy complaints, measure reduction overtime, and proactively engage with non-compliant registrars by leveraging thecomplaint intake system and resources currently available. As noted above, Staff analysis is ongoing, and changes to improve accuracy are under discussion in the RAA negotiations, which also should be factored in. Community discussion also would be helpful on how the Recommendation can best be implemented.
Recommendation 8. Data Accuracy -- 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.
Staff is pursuing the goal of increasing clarity on WHOIS accuracy obligations, and steps to better inform registrars, registrants, and users of the Internet at large could be beneficial. Staff also is pursuing the use of graduated penalties, which should be helpful to improving WHOIS accuracy while not unfairly punishing parties for misunderstandings or mistakes. Staff needs to investigate public policy, legal issues and implementation optionsinvolved in the Recommendation. Under current agreements, registrars and registrants already have obligations to help ensure WHOIS data accuracy. Moreover, most agreements already have actual or implicit provisions for “graduated sanctions” for breaches of the agreements, generally. It would be helpful to understand, then, whether this is largely a request for better community education or if there is a perceived need for additional contractual tools.
Considerable work is already underway as part of the current round of RAA negotiations to strengthen and clarify WHOIS data accuracy obligations applicable to both registrars and registrants. Inaddition, ICANN and registrars have already agreed in principle that WHOIS data will require some form of data verification as a condition of registration and at other relevant times. Because this discussion is active, the framework for the verification requirement is still under development. It is anticipated that this new regime may require efforts by ICANN to help educate registrars andregistrants. Accordingly, it is anticipated that the Recommendation will besubstantially implemented upon adoption of a revised RAA, making at least theapparent aim of the Recommendation feasible to accomplish.
Currently, registrars and registrants are primarily responsible for maintaining WHOIS data accuracy. As noted, the 2009 version of the RAA provides for graduated sanctions for breaches, short of termination of the RAA.[1] This contractual framework generally allows registrars some flexibility in addressing inaccurate WHOIS data; for example, registrars may suspend a registration instead of deleting it or allow extra time for a registrant response if extenuating circumstances warrant it. If there were a desire by the community to require registrars to conform to a particular course of action in remedying WHOIS data inaccuracy, the RAA could be amended or a consensus policy (GNSO PDP) could be developed to specify, precisely, the steps a registrar must take. Enhanced WHOIS accuracy provisions also could be introduced through additional provisions in the New gTLD Program, such as through the Registry-Registrar Agreements, or a new RAA that would apply solely to New GTLDs.
Recommendation 9.Data Accuracy -- 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 and prominently circulated to all new and renewing registrants.
Staff is engaged in advancing this goal, as a better understanding of WHOIS data among registrants can be expected to help improve data accuracy and help registrants avoid loss of the use of registrations caused by their (potentially unintended) failure to maintain accurate WHOIS data.
In terms of registrant education efforts, there are several educational resources available today For example, Section 3.15 of the 2009 RAA currently requires registrars to post links on their websites to the “Registrant Rights and Responsibilities” document developed by ICANN that is intended to describe the RAA in plainlyunderstood, non-legalistic language. Moreover, registrars are required to post the link “at least as clearly as [their] links to policies or notifications required to be displayed under ICANN Consensus Policies.” Our initial studies have indicated that a vast majority of registrars have satisfied this requirement. Also, in addition to the registration agreement requirement that registrants provide accurateWHOIS data (Sections 3.7.7.1 and 3.7.7.2), the WDRP requires registrars to remind registrants on an annual basis to verify the accuracy of their WHOISdata and that “provision of false WHOIS information can be grounds forcancellation of their domain name registration.” Is it the Review Team’s opinion that this is not an adequate communication to renewing registrants?Additionally, because this recommendation suggests communication of WHOIS obligations to prospective registrants (who have no WHOIS obligation nor presumably, much interest in WHOIS data until they become registrants), it would be helpful to understand the extent to which ICANN and registrars should, in the Review Team’s view, engage in educational efforts.
The RAAcould be amended or a GNSO consensus policy adopted to require registrars tocommunicate the Registrant Rights and Responsibilities document even more prominently, but some investigation should be undertaken as a part of the initiative to ascertain first whether the current scheme is ineffective. Additional educational efforts are feasible and could be initiated, but the costs and resources needed to perform this work will depend on the extent and scope of efforts expected by the Review Team. In addition, the creation of a Registrar “Code of Conduct” as referenced in the RAA (3.7.1) might be another way of implementing these recommendations if they are supported by a consensus of ICANN-accredited registrars.
Recommendation 10.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, balancing between stakeholders with competing but legitimate interests, including, at a minimum, privacy, law enforcement and industry around law enforcement. These should include:
· WHOIS entry must clearly label that this is a private registration.
· Privacy services must provide full contact details as required by the WHOIS that are available and responsive as required by the framework mentioned 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 on registrant contact information.
Staff is exploring measures to help achieve clear, consistent, and enforceable requirements for privacy services, and has made this topic a priority in the RAA negotiations. Specifically, Staff has proposed creating an accreditation program for privacy services, which could provide a framework for implementing the Recommendation.
Although the Recommendation is in line with objectives being pursued by Staff, it will be difficult to ensure that all privacy services are covered by the proposed system. Since ICANN does not have direct contracts with registrants, ICANN has limited ability to identify all privacy services in use. However, by including an obligation in the RAA that a registrar may not knowingly accept registrations from unaccredited privacy services, a substantial portion of the privacy registrations available today could be covered by the obligations described in the Recommendation. Creation of an ICANN accreditation program for privacy services will have significant budgetary and operational impact, as it would likely require ICANN to hire additional resources to meet these new obligations. Also, implementation would involve amendments to the RAA, or the adoption of consensus policies by theGNSO, in order to create enforceable obligations against registrars.
Staff continues to analyze the elements of an accreditation program for privacy services, and community discussion of the Recommendation will be useful.
Recommendation 11. Data Access -- Privacy Services -- 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.
If an accreditation program were established by ICANN for privacy services, Staffwould expect that graduated and enforceable series of penalties for privacyservice providers who violate the requirements would be an integral part ofthis program. Community input will be needed on various aspects of the Recommendation, including the following:
· What types of penalties should apply?
· If a privacy service is de-accredited, what should happen to the customers of the service? Would their underlying information be unmasked? Since there is no obligation to escrow information of privacy services, it may be difficult to protect the customers of such privacy providers.
ICANN’s ability to implement this recommendation is dependent upon entering into direct contracts with privacy service providers. Without contracts, there may be no applicable enforcement mechanism.
Staff continues to analyze the elements of an accreditation program for privacy services, and community discussion of the Recommendation will be useful.
Recommendation 12. Data Access - Proxy Services -- 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.
Staff can engage in voluntary discussions with proxy providers about their current processes, and use a variety of outreach mechanisms (including ICANN meetings) to advance such conversations. If the Review Team has additional guidance for Staff on intended targets, that would be useful. Proxy accreditation is being explored in the current RAA negotiations. The Recommendation may require amendments to the RAA, or adoption of a GNSO consensus policy, as Staff’s role with proxy services currently is limited. Staff continues to analyze the elements of an accreditation program for proxy services, and community discussion of the Recommendation will be useful.
Recommendation 13. Data Access - Proxy Services -- Registrars should be required to disclose to ICANN their relationship with any Affiliated Retail proxy service provider.
Staff is pursuing this objective, which is being addressed in the current RAA negotiations. While the Recommendation is feasible, Staff also needs to explore the various ways registrars can be affiliated with retail proxy service providers (and registrar input would be useful).
Recommendation 14. Data Access - Proxy Services -- ICANN should develop a set of voluntary best practice guidelines for appropriate proxy services[2] consistent with national laws, striking a balance between stakeholders withcompeting 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 by WHOIS;
· Publication by the proxy service of its process for revealing and relaying information;
· Standardization of reveal and relay processes and 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.
Staff is pursuing a similar goal – relay and reveal issues are being addressed in the RAA negotiations. These efforts will be factored into Staff’s work on the Recommendation. Staff continues to analyze potential implementation of the Recommendation, and the GNSO may beable to assist with implementation analysis.
Recommendation 15. Data Access - Proxy Services -- ICANN should encourage and incentivize registrars to interact with the retail service providers that adopt the best practices.
Staff continues to explore implementation details for the Recommendation, including addressing liability, auditing, and other issues, as well as implementation resource needs. Input from registrars, in particular, would be useful here.
Recommendation 16. Data Access - Proxy Services -- 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.
The current RAA holds the Registered Name Holder responsible for adhering to registrantobligations regardless of whether the registration was made on behalf of a third party. A draft Registrar Advisory was issued for consideration on 14 May 2010 to provide community guidance and clarification of this provision, but was never finalized. It would be helpful for Staff to receive community input on reconsidering this advisory. RAA negotiations also may affect implementation of the Recommendation.
Recommendation 17. Data Access – Common Interface -- 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” also is provided: 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.
The Recommendation seems feasible and Staff looks forward to further investigating implementation once the Recommendation is finalized.
A “single point of access” to domain name registration data is similar in objectives to the Centralized Zone File Access solution developed by Staff and the ICANN community to facilitate access to TLD zone file data, but different in technical, operational, business, and contractual aspects. Staff is prepared to study these implementation issues and offers the following comments and observations.
Currently, Staff and the Internet technical community are studying several of the technical implementation aspects that would define the technical framework for an improved WHOIS service. These include multilingual interfaces (internationalized registration data, through the IRD WG, a collaborative effort of the GNSO, SSAC, and CCNSO), normalization of data (analysis of query, response, display and error messages by the SSAC), the development of standard protocols (by both name and address registry members of the Internet community through IETF processes), and consideration of service requirements by the GNSO. Several of these participants, including Staff, have and continue to run technical experiments with this framework, and “proof of concept” as well as production services at ARIN offer promising results. These are necessary but may not be sufficient conditions to implementing the Team’s Recommendation.
The operation of a dedicated, multilingual WHOIS web site has technical and business implications. ICANN would require budget approval for acquisition of access bandwidth andinfrastructure, and for hiring of Staff sufficient to meet the demands of acommon entry point to a distributed database currently accessed through infrastructure provided by hundreds of registry and registrar WHOIS services. Capacity planning for an enterprise of this scale can only properly be doneafter a detailed implementation framework and plan is approved.
One technical solution is to have this web site act as a proxy that would relay queries between WHOISusers and registries or registrars. An alternative solution would be for ICANN to collect registration data from registries and registrars and maintain these locally, either cached or in permanent storage. Existing registry and registrar WHOIS services must change to satisfy the “back end” requirements for either solution. For example, if a relay model is chosen, registry and registrar WHOIS services must satisfy availability and throughput requirements (and not rate limit), whereas if a cache or storageoption is chosen, a method for maintaining data synchronization and consistency must be developed. Lastly, any operational solution Staff is asked to consider must be evaluated and demonstrated to scale better than the existing solution.
Independent of the operational solution selected, the ICANN community may need to undertake a consensus policy development or engage in contractual negotiations to establish new registry and registrar contractual obligations that do not exist today.
Recommendation 18. Internationalized Domain Names -- The 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 oneyear from formation, using existing IDN encoding. The working group should aim for consistency of approach across gTLDs and – on a voluntary basis – the ccTLD space.
Staff is pursuing the Recommendation -- with some clarifications. Specifically, it is not within ICANN’s remitto select what encoding should be applied, or what signal mechanism should be established to support those encodings; this is the role of the IETF. From a technical perspective, mandating that encodings say UTF-8 would cause serious backward compatibility issues for the majority of the WHOIS clients today and Staff is not certain that is the right a to take. The approach Staff suggests is to defer this issue to the IETF, and ask that they create a protocol that supports internationalized registration data. This falls within IETF’s remit, and this group has the necessary technical expertise and broader participation from all of the relevant technical stakeholders.
Staff proposes the following revision to the Review Team’s Recommendation: “The ICANN Community should develop, in cooperation with the IETF and other technical standards organizations as needed, (i) a unified registration data model, and (ii) a solution for offering internationalized services.” In addition, the draft report states, “Such working group should report no later than one year from formation, using existing IDN encoding.” Staff is not sure what “using existing IDN encoding” means and would appreciate clarification.
Recommendation 19. Internationalized Domain Names -- 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 case for adoption of consensus policies).
As noted above, the Recommendation could be implemented if the IETF takes the necessary action. Implementation would require incorporation into the RAA and existing registry agreements, which would require negotiations and/or a GNSO PDP. An increase in resources and expertise alsowould be needed. Staff has put a “placeholder” for internationalized services on the discussion list for the current RAA negotiations, and Staff has suggested that, if the IETF develops a new protocol, it should be automatically implemented. This recommendation also could be introduced through additional provisions in the New gTLD Program, such as through the Registry-Registrar Agreements, or a new RAA that would apply solely to New GTLDs.
Recommendation 20. Internationalized Domain Names -- 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.
As noted above, Staff is pursuing the Recommendation -- with some clarifications/corrections. Staff continues to analyze the details involved in the Recommendation’s potential implementation.
[1] See RAA Section 2.1, allowing ICANN to suspend a registrar’s ability to create new registrations and initiate inbound transfers for up to a 12-month period, and Section 5.7, requiring payment by the registrar of ICANN’s enforcement costs or sanctions of up to five times ICANN’s enforcement costs for repeated willful material breaches. Section 3.7.7.1 of the RAA obligates registrars to include in their registration agreements a provision requiring registrants to provide accurate and reliable registration contact details. Section 3.7.7.2 of the RAA obligates registrars to include in their registration agreements a provision making it a material breach for a registrant to willfully provide inaccurate or unreliable information, willfully fail to promptly update contact information provided to the registrar, or fail to respond for over 15 calendar days to inquiries from the registrar concerning the accuracy of contact details. Section 3.7.8 of the RAA requires registrars to take “reasonable steps” to investigate and correct allegedly inaccurate WHOIS data.
[2] As “guidance to the community” and as useful background for the Proxy Service Recommendations, the Team provides its working definitions of proxy service and different types of proxy service providers.