Combined WHOIS Task Force (1, 2, 3) of the GNSO Council

Date

12 September 2005

Preliminary task force report on a policy recommendation and advice on a procedure for handling conflicts between a registrar/registry's legal obligations under privacy laws and their contractual obligations to ICANN

For public comment from 12 September 2005 to 02 October 2005

Table of contents

1 Introduction & background
1.1 Text of recommendation and advice on a procedure
1.2 Summary of Task Force voting on the recommendation

2 Constituency statements

    2.1 Commercial and Business User Constituency
    2.2 Non-Commercial User Constituency
    2.3 Intellectual Property Constituency
    2.4 Registrar Constituency
    2.5 Registry Constituency
    2.6 Internet Service Providers & Connectivity Providers Constituency

Annex

1 Relevant provisions of the Registrar Accreditation Agreement

1 Introduction & background

Article X, Section 1 of the ICANN Bylaws (http://www.icann.org/general/bylaws.htm#X ) states "the Generic Names Supporting Organization (GNSO), (which) shall be responsible for developing and recommending to the ICANN Board substantive policies relating to generic top-level domains." This preliminary task force report and the consensus policy recommendation therein refers only to the generic top level domain space.

This document is the Preliminary Task Force Report on a consensus policy recommendation and advice on a procedure for handling WHOIS conflicts with local or national privacy laws. It is comprised of the proposed recommendation and advice, background information, the task force vote and the constituency statements. This report was the subject of a task force vote held on Tuesday, 6^th September, 2005.

In December 2003, WHOIS Task Force 2 was tasked with "document(ing) examples of existing privacy laws in regard to display/transmittal of data". (Task Force 2 terms of reference, point 4 of 'tasks and milestones';available at http://gnso.icann.org/issues/whois-privacy/tor2.shtml).

Task Force 2's preliminary report was published for public comment in June 2004 (available at http://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html#P…). The report found, in section 2.3, that:

"After documenting and reviewing the examples of local privacy laws it is the Task Force's finding that different nations have very different privacy laws and that the determination whether they are applicable to the gTLD WHOIS situation is not an easy one. However, situations have arisen in which privacy laws or regulations have conflicted with WHOIS-related contractual obligations with ICANN.

...

The Task Force believes that there is an ongoing risk of conflict between a registrars' or registries' legal obligations under local privacy laws and their contractual obligations to ICANN.

Since the variety of the existing local privacy laws does not allow for a one-size-fits-all solution, the registrars and registries encountering such local difficulties should be allowed an exception from the contractual WHOIS obligation for the part of the WHOIS data in question by the local regulation, after proving the existence of such a conflict with a law or regulation. In addition, a procedure should be established for seeking to resolve such conflicts with local authorities as new regulations evolve in a way that promotes stability and uniformity of the WHOIS system. Such steps will undoubtedly achieve a greater legal certainty and foster the international competition on the domain name market."

The report recommended (section 3.3) that ICANN:

"...develop and implement a procedure for dealing with the situation where a registrar (or registry, in thick registry settings) can credibly demonstrate that it is legally prevented by local mandatory privacy law or regulations from fully complying with applicable provisions of its ICANN contract regarding the collection, display and distribution of personal data via Whois. The goal of the procedure should be to resolve the conflict in a manner conducive to stability and uniformity of the Whois system."

The report gave details for the steps to be included in such a procedure:

"Written notification by the affected registrar/registry to ICANN with a detailed report which includes but is not limited to:
- The law or regulation that causes the conflict.
- The part of the Whois obligation in question.
- The steps that will have to be taken to cure the conflict.
If data elements are removed this must be notified to the requester by the insertion of standardized notice in the Whois results advising the requester of the problem and, if possible, directing requester to another or alternative procedure for obtaining access to this data element.
Prompt notification from ICANN to the public informing it of the change and of the reasons for ICANN's forbearance from enforcement of full compliance with the contractual provision in question.
The changes must be archived on a public website for future research.

Except in those cases arising from a formal complaint or contact by a local law enforcement authority that will not permit consultation with ICANN prior to resolution of the complaint under local law, the procedure should be initiated using the following steps:

prompt notification by the affected registrar/registry to ICANN with detailed summary of the problem arising including:
- the law or regulation that causes the conflict.
- the part of the Whois obligation in question.
consultation by the registrar/registry with ICANN and other parties (which include government agencies) to try to resolve the problem / remove the impediment to full compliance with contract."

On 30 November 2004, the WHOIS Task Forces 1 and 2 produced Recommendation 1 — A Procedure for conflicts, when there are conflicts between a registrar's of registry's legal obligations under local privacy laws and their contractual obligations to ICANN (available at http://gnso.icann.org/issues/whois-privacy/whois-tf-conflict-30nov04.pdf). This recommendation was presented to the GNSO Council during the GNSO public forum at the ICANN meeting in Capetown in December 2004.

On February 17, 2005, the WHOIS task forces 1, 2 and 3 were combined into a single combined WHOIS Task Force. (http://www.gnso.icann.org/meetings/minutes-gnso-17feb05.html). On 2nd June 2005, the combined WHOIS task force was chartered by the GNSO Council with terms of reference and a set of tasks that required it to conclude its work on the 'conflicts' policy recommendation:

"(5) Determine how to resolve differences between a Registered Name Holder's, gTLD Registrar's, or gTLD Registry's obligation to abide by all applicable laws and governmental regulations that relate to the WHOIS service, as well as the obligation to abide by the terms of the agreements with ICANN that relate to the WHOIS service. [Note this task refers to the current work in the WHOIS task force called 'Recommendation 2', A Procedure for conflicts, when there are conflicts between a registrar's of registry's legal obligations under local privacy laws and their contractual obligations to ICANN." (available at http://gnso.icann.org/policies/terms-of-reference.html)

Accordingly, Task force members continued to develop the recommendation through June 2005. The task force voted on May 24, 2005 to divide its work into a recommendation for consensus policy accompanied by advice for a procedure. Constituency statements on the recommendation were solicited by 21 July 2005.

1.1 Text of recommendation and advice on a procedure

This is the final version of the recommendation and advice voted on by the task force. The constituency statements responded to an earlier version of this text.

WHOIS Task Force policy recommendation and advice on Whois conflicts with national and local privacy laws

Preamble

Task Force 2 spent over a year collecting data and working on the conflict between a registrar/registry's legal obligations under privacy laws and their contractual obligations to ICANN. Its report included the statement: "The Task Force believes that there is an ongoing risk of conflict between a registrar's or registry's legal obligations under local privacy laws and their contractual obligations to ICANN. TF2 Report, Section 2.3, http://www.gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html.

By vote of the Task Force, now merged, on May 24, 2005, the work of Task Force 2 is hereby divided into a recommendation for "consensus policy" accompanied by "well-developed advice for a procedure."

I. Task Force Policy for WHOIS Conflicts with Privacy Law

CONSENSUS POLICY RECOMMENDATION

In order to facilitate reconciliation of any conflicts between local/national mandatory privacy laws or regulations and applicable provisions of the ICANN contract regarding the collection, display and distribution of personal data via Whois, ICANN should:

Develop and publicly document a procedure for dealing with the situation in which a registrar or registry can credibly demonstrate that it is legally prevented by local/national privacy laws or regulations from fully complying with applicable provisions of its ICANN contract regarding the collection, display and distribution of personal data via WHOIS.
Create goals for the procedure which include:
1. Ensuring that ICANN staff is informed of a conflict at the earliest appropriate juncture;
2. Resolving the conflict, if possible, in a manner conducive to ICANN's Mission, applicable Core Values and the stability and uniformity of the Whois system;
3. Providing a mechanism for the recognition, if appropriate, in circumstances where the conflict cannot be otherwise resolved, of an exception to contractual obligations to those registries/registrars to which the specific conflict applies with regard to collection, display and distribution of personally identifiable data via Whois; and
4. Preserving sufficient flexibility for ICANN staff to respond to particular factual situations as they arise.

II. Text of Recommended Procedure

WELL-DEVELOPED ADVICE ON A PROCEDURE FOR HANDLING WHOIS CONFLICTS WITH PRIVACY LAW

Based on extensive research and negotiation among Task Force 2, together with the merged Task Force and ICANN staff, the following procedure for handling the policy recommendation set out in Section I above is set out as a Recommended Step-by-Step Procedure for Resolution of WHOIS Conflicts with Privacy Law. We encourage ICANN staff to use this Recommended Procedure as a starting point for developing the procedure called for in the Consensus Policy Recommendation above.

Step One: Notification of Initiation of Action

Once receiving notification of an investigation, litigation, regulatory proceeding or other government or civil action that might affect its compliance with the provisions of the RAA or other contractual agreement with ICANN dealing with the collection, display or distribution of personally identifiable data via Whois ("Whois Proceeding"), a Registrar/ Registry must within thirty (30) days provide ICANN's General Counsel (or other staff member as designated by ICANN) with the following information:

Summary description of the nature and status of the action (e.g., inquiry, investigation, litigation, threat of sanctions, etc.)
Contact information for the responsible official of the registrar/registry for resolving the problem.
Contact information for the responsible territorial government agency or other claimant and a statement from the registrar/registry authorizing ICANN to communicate with those officials or claimants on the matter. If the registrar/registry is prevented by applicable law from granting such authorization, the notification should document this.
The text of the applicable law or regulations upon which the local government or other claimant is basing its action or investigation, if such information has been indicated by the government or other claimant.

Meeting the notification requirement permits Registrars/Registries to participate in investigations and respond to court orders, regulations, or enforcement authorities in a manner and course deemed best by their counsel.

Depending on the specific circumstances of the Whois Proceeding, the Registrar/Registry may request that ICANN keep all correspondence between the parties confidential pending the outcome of the Whois Proceeding. It is recommended that ICANN respond favorably to such requests to the extent that they can be accommodated with other legal responsibilities and basic principles of transparency applicable to ICANN operations.

Step Two: Consultation

Unless impractical under the circumstances, we recommend that the ICANN General Counsel, upon receipt and review of the notification and, where appropriate, dialogue with the registrar/registry, consider beginning a process of consultation with the local/national enforcement authorities or other claimant together with the registrar/registry. The goal of the consultation process should be to seek to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its contractual obligations to the greatest extent possible.

The Registrar should attempt to identify a solution that allows the registrar to meet the requirements of both the local law and ICANN obligations. The General Counsel can assist in advising the registrar on whether the proposed solution meets the ICANN obligations.

If the Whois proceeding ends without requiring any changes and/or the required changes in registrar/registry practice do not, in the opinion of the General Counsel, constitute a deviation from the R.A.A. or other contractual obligation , then the General Counsel and the registrar/registry need to take no further action.

If the registrar/registry is required by local law enforcement authorities or a court to make changes in its practices affecting compliance with Whois-related contractual obligations before any consultation process can occur, the registrar/registry shall promptly notify the General Counsel of the changes made and the law/regulation upon which the action was based. The Registrar/Registry may request that ICANN keep all correspondence between the parties confidential pending the outcome of the Whois Proceeding. It is recommended that ICANN respond favorably to such requests to the extent that they can be accommodated with other legal responsibilities and basic principles of transparency applicable to ICANN operations.

Step Three: General Counsel analysis and recommendation

If the local/national government requires changes (whether before, during or after the consultation process described above) that, in the opinion of the General Counsel, prevent full compliance with contractual WHOIS obligations, ICANN should consider the following alternative to the normal enforcement procedure. Under this alternative, ICANN would refrain, on a provisional basis, from taking enforcement action against the registrar/registry for non-compliance, while the General Counsel prepares a report and recommendation and submits it to the ICANN Board for a decision. Such a report may contain:

A summary of the law or regulation involved in the conflict;
Specification of the part of the registry or registrar's contractual WHOIS obligations with which full compliance if being prevented;
Summary of the consultation process if any under step two; and
Recommendation of how the issue should be resolved, which may include whether ICANN should provide an exception for those registrars/registries to which the specific conflict applies from one or more identified WHOIS contractual provisions. The report should include a detailed justification of its recommendation, including the anticipated impact on the operational stability, reliability, security, or global interoperability of the Internet's unique identifier systems if the recommendation were to be approved or denied.

The registrar/registry should be provided a copy of the report and provided a reasonable opportunity to comment on it to the Board. The Registrar/Registry may request that ICANN keep such report confidential prior to any resolution of the Board. It is recommended that ICANN respond favorably to such requests to the extent that they can be accommodated with other legal responsibilities and basic principles of transparency applicable to ICANN operations.

Step Four: Resolution

Keeping in the mind the anticipated impact on the operational stability, reliability, security, or global interoperability of the Internet's unique identifier systems, the Board should consider and take appropriate action on the recommendations contained in the General Counsel's report as soon as practicable. Actions could include, but are not limited to:

Approving or rejecting the report's recommendations, with or without modifications;
Scheduling a public comment period on the report; or
Referring the report to GNSO for its review and comment by a date certain.

Step Five: Public Notice

The Board's resolution of the issue, together with the General Counsel's report, should ordinarily be made public, along with the reasons for it, and be archived on a public website (along with other related materials) for future research. Prior to release of such information to the public, the Registry/Registrar may request that certain information (including, but not limited to, communications between the Registry/Registrar and ICANN, or other privileged/confidential information) be redacted from the public notice. In the event that such redactions make it difficult to convey to the public the nature of the actions being taken by the Registry/Registrar, the General Counsel should work with the Registry/Registrar on an appropriate notice to the public describing the actions being taken and the justification for such actions.

Unless the Board decides otherwise, if the result of its resolution of the issue is that data elements in the registrar's Whois output will be removed or made less accessible, ICANN should issue an appropriate notice to the public of the resolution and of the reasons for ICANN's forbearance from enforcement of full compliance with the contractual provision in question.

Step Six: Ongoing Review

With substantial input from the relevant registries or registrars, together with all constituencies, there should be a review of the pros and cons of how the process worked, and the development of revisions designed to make the process better and more efficient, should the need arise again at some point in the future.

1.2 Summary of Task Force voting on the recommendation

The task force vote on the recommendation and advice for a procedure was held during a task force conference call on 6 September 2005. The recommendation and advice for a procedure were supported unanimously.

In favour	Opposed	Abstained
Commercial and Business Users Constituency (Marilyn Cade, David Fares, Sarah Deutsch)	None	Jordyn Buchanan (Co-Chair)
Intellectual Property Constituency (Steve Metalitz, Niklas Lagergren)
Non Commercial Users Constituency (Milton Mueller, proxy for all NCUC task force members)
Internet Service Providers and Connectivity Providers Constituency (Tony Harris)
Registrars Constituency ( Ross Rader, proxy for all registrars constituency task force members)
Registry Constituency (David Maher, Ken Stubbs, Tuly Day)

2 Constituency statements

2.1 Commercial and Business User Constituency

Background
Constituencies have been invited to provide input on the Whois Task Force Terms of Reference Items 1 (Purpose) and 2 (Purpose of WHOIS contacts). This statement has been prepared in accordance with the GNSO policy development process criteria for "Constituency Statements". (see annex).
Related documents:
Call for constituency statements on Tasks 1&2 of Whois Task Force
Terms of Reference, (available at http://forum.icann.org/lists/gnso-dow123/msg00416.html).
Terms of Reference (available at http://gnso.icann.org/policies/terms-of-reference.html)
1. Purpose of the Whois Database.
The Internet has evolved from its early days of technical experimentation and has become a key medium for commerce and a rich source of information and resources for users. The purpose of the Whois database as the primary resource of contact information must therefore reflect this evolution.
ICANN's responsibility for stability and security are highly relevant to an accurate Whois.
The Registrar Accreditation Agreements (RAA) maintained by ICANN require, as a pre-requisite to the registration of a domain name, the inclusion of the administrative, technical and contact details into a publicly accessible Whois database. The RAA also mandates that registrants receive notification of the public accessibility of this information.
The BC supports having clear and easy to find "notice" of both the collection and the display of data.
The BC also notes that registrants are able to use agents as contact points should anonymous registration be desired. In any case, the correct data should be collected, and maintained by the agent, for provision upon legitimate request.
With the above in mind, the BC proposes the following purpose of the Whois database:
A database of contact information sufficient to contact the registrant or their agent(s) to enable the prompt resolution of technical, legal and other matters relating to the registrant's registration and use of its domain name.
Effect on the Constituency, including financial impact
BC members rely on accurate WHOIS data to engage in a number of important actions, including: verification of who holds a particular name; trademark/domain name portfolio management; contacting a registrant due to network or phishing attacks originating from a particular domain; engaging in trademark protection, cooperation with law enforcement and consumer protection authorities when investigation of illegal activity in a domain; contacting a registrant to make an offer to purchase an existing registration, etc.
The BC believes that this policy will have a positive impact on the Constituency, and will help to limit the costs to business users. We do not believe that there is any cost associated with this policy since it is essentially maintaining the status quo.
Analysis of the period of time that would likely be necessary to implement the policy
Little time would be needed for implementation, since this is essentially the status quo.
2. Purpose of WHOIS contacts
The BC believes there is a need to clarify the information that should be provided in the three categories defined in the Transfers Policy and to use consistency of terminology.
Terminology
The Transfers policy uses the term "domain holder" in place of "Registered Name Holder". The BC recommends that these two terms are treated as interchangeable with each other.
a. Registered Name Holder
The Registered Name Holder is the registrant and thus responsible for the domain name registration generally, including for canceling or transferring a name. This individual's or the organisation's name and contact should be provided in this category.
b. Technical Contact
The technical contact is responsible for responding to inquiries related to the technical functioning of the web site and to deal with any technical problems. An individual competent to respond to those kinds of inquiries should be provided in this category.
(If a registrant chooses to use their ISP or other third party as the technical contact, that changes in no way the need for accurate data for the Registered Name Holder).
c. Administrative Contact
The Administrative Contact may be responsible for dealing with the content on the web site and is responsible to the registered name holder, unless they are the same person. The BC supports the definition in the Transfers policy:
The Administrative Contact is: "an individual, role, or organization authorized to interact with the Registry or Registrar on behalf of the Domain Holder. The administrative contact should be able to answer non-technical questions about the domain name's registration and the Domain Holder. In all cases, the Administrative Contact is viewed as the authoritative point of contact for the domain name, second only to the Domain Holder."
Note: the holder, technical and administrative contacts may be one and the same.
Effect on the Constituency, including financial impact
This policy will have a positive impact on the BC and more broadly for all Internet users who need to check Whois data for policing domain names, deal with network problems and phishing attacks; check out a web site to see with whom they are doing business, or where their children are finding information, etc. by enhancing the accuracy and usability of the Whois database.
There should be no financial impact on the constituency as a result of this policy. It is possible that there may be minimal costs to the Registrars if they are not fully complying with the present RAA. Any costs would be related to the provision, in automated form, of descriptive information of what is recommended to fill each separate category.
An analysis of the period of time that would likely be necessary to implement the policy.
An implementation working group, to include representation from the user constituencies, but largely to include Registrars, should be established. The implementation time frame should be short.
3. Outreach process
The ICANN bylaw that outlines the GNSO policy development process (section 7.d) states:
"1. Constituency Statements. The Representatives will each be responsible for soliciting the position of their constituencies, at a minimum, and other comments as each Representative deems appropriate, regarding the issue under consideration. This position and other comments, as applicable, should be submitted in a formal statement to the task force chair (each, a "Constituency Statement") within thirty-five (35) calendar days after initiation of the PDP. Every Constituency Statement shall include at least the following:
(i) If a Supermajority Vote was reached, a clear statement of the constituency's position on the issue;
(ii) If a Supermajority Vote was not reached, a clear statement of all positions espoused by constituency members;
(iii) A clear statement of how the constituency arrived at its position(s). Specifically, the statement should detail specific constituency meetings, teleconferences, or other means of deliberating an issue, and a list of all members who participated or otherwise submitted their views;
(iv) An analysis of how the issue would affect the constituency, including any financial impact on the constituency; and
(v) An analysis of the period of time that would likely be necessary to implement the policy."
With respect to (i), (ii) and (iii) the BC approval process allows for a 14 day comment period for a position to be adopted combined where appropriate with meetings and member calls.
Statement on purpose
The BC members were notified of the new terms of reference for the combined Task Force on 19 May 2005
The TF reps prepared a draft purpose statement and posted it to the Constituency on 19 July 2005.
The statement and the issues were discussed at the Luxembourg meeting 11 July 2005.
A conference call was held on 26 July 2005
The draft statement on Purpose was posted to the BC list on 2 August 2005 and adopted after a 14 day period.
Statement on purpose of contacts
The BC members were notified of new terms of reference for the combined Task Force on 19 May 2005
The forthcoming draft statement on Purpose of Contacts was discussed at the Luxembourg meeting 11 July 2005.
BC members were asked to participate in a Contacts survey on 22 July 2005
A conference call was held on 26 July 2005.
The draft statement on Purpose of Contacts was posted to the BC list on 2 August 2005 and adopted after a 14 day period.

2.2 Non-Commercial User Constituency

NCUC Statement on "Whois Task Force Policy Recommendation and Advice on Whois Conflicts with National and local Privacy Laws."
The NCUC supports passage and quick implementation of the "Whois Task Force Policy Recommendation and Advice on Whois Conflicts with National Privacy Laws." The NCUC views this procedure as a stop-gap measure that needs to be implemented pending a more comprehensive reform of the Whois service to make it conform to ICANN's mission, national privacy laws and international privacy norms.

2.3 Intellectual Property Constituency

This statement responds to the request for constituency input on the Whois Task Force recommendations regarding conflicts between local law and Whois requirements. (The call for constituency statements is available at http://forum.icann.org/lists/gnso-dow123/msg00415.html).
Pursuant to requirements of the GSNO policy development process, outlined by the ICANN bylaws, see Annex A, Sec. 7(d), (available at http://www.icann.org/general/archive-bylaws/bylaws-19apr04.htm) the IPC came to the following conclusion.
The Intellectual Property Interests Constituency (IPC) generally supports the "Policy/Advice Recommendation on conflicts between national privacy laws and registries' or registrars' contractual obligations to ICANN."
While we agree with the statement by Whois Task Force 2 that "there is an ongoing risk of conflict between a registrar's or registry's legal obligations under local privacy laws and their contractual obligations to ICANN," we believe this risk is generally low in the gTLD environment. Public access to Whois and local privacy laws have coexisted for many years, and the likelihood is that this will continue to be the case in the future. The main reasons for this are (1) under ICANN's contracts, no domain name may be registered in a generic Top Level Domain until the registrant has been notified of, and consented to, the uses and disclosures that may be made of personally identifiable data submitted in connection with the registration; and (2) Whois data has historically been, and continues to be, collected for the broad purpose of enabling contact with the entities responsible for a given Internet resource. Current ICANN agreements and long-standing registrar practices make clear that public access is one of the purposes for which Whois data is collected. Indeed, the contractual obligations of the Registered Name Holder depend on the public's ability to access the information and use it.
However, because the risk of conflict between RAA obligations and national law, while probably very low, is not zero, we support the idea that ICANN should have a procedure in place for handling claims of such conflicts. The alternative, to have no formal procedure in place for this eventuality, could have adverse consequences. Registrars and registries might simply unilaterally change their policies and practices so that they fail to comply with ICANN agreements, and wait for compliance action from ICANN, if any. This could create uncertainty, insecurity and instability in the domain name system, and reduce uniformity of Whois policies. The result could be confusion and frustration of the purposes of the Whois database, to the detriment of intellectual property owners, businesses, consumers, parents, law enforcement agencies, and others who rely upon access to it.
The goals for the procedure, set out in item 2 of the Consensus Policy Recommendation, are critical:
ICANN should be made aware of a potential or asserted conflict as soon as possible, and where appropriate ICANN should actively assist in efforts to resolve the issue in a way that allows full compliance with both local law and contractual obligations. For example, local law may require that the registrar do more than the ICANN contract requires in order to obtain a consent from the registrant, which is legally valid under that jurisdiction's laws, for a use of Whois data. In such a circumstance, the registrar should be required to take those extra steps to obtain such consent, if it is practical to do so, and if consent obtained simply by following the contractual obligations would make the use problematic under local law.
The mechanism for recognizing an exception to contractual obligations should be exercised only in extraordinary circumstances, and should not be mandatory or automatic whenever efforts at resolution meet an impasse. Recognizing exceptions could have adverse impacts on the security and stability of the current system, and on the competitive playing field among registrars. Conceivably, the application of some local law could be so rigid or demanding that a registrar or registry subject to that law simply cannot fulfill its contractual obligations to ICANN and thus the contractual relationship must be phased out.
Finally, flexibility is critical, since we cannot now anticipate the specific contours of a future potential conflict, and the legal issues — beginning with which jurisdiction's law is even applicable — may be extremely complex.
In general, IPC believes the Recommended Procedure meets these goals and forms a good starting point for development of the policy. The General Counsel (or some other ICANN staff person) should be designated to receive notifications of potential conflicts, to engage in consultation efforts to help resolve them, and to inform the Board and ultimately the ICANN community of any action that needs to be taken. While this may include, in an extraordinary case, forbearance from full enforcement of contractual obligations, it may also include enforcement action to compel compliance.
IPC offers a few specific comments regarding the Recommended Procedure, which it urges the ICANN staff to consider in formulating its own procedure:
We are concerned that the confidentiality provisions in Steps One, Two, and Three could, as a practical matter, foreclose the ability of interested parties to question or rebut the need for a departure from the RAA on a case-by-case basis. Such an ability to question a registrar's assertion of a conflict in a specific case is particularly important in light of the sparse or non-existent history of insurmountable conflicts between national laws and the RAA. Although we agree there could be circumstance in which confidentiality might be necessary, the policy should not favor such requests, and in fact should specify that they would be granted only in unusual circumstances.
The statement near the end of Step One that "Meeting the notification requirements permits Registrar/Registries to participate in investigations and respond to court orders, regulations, or enforcement authorities in a manner and course deemed best by their counsel" is ambiguous. This language may be intended to provide an incentive for registrars to comply with the notification requirements set out in Step One. However, the consequence of failing to meet the notification requirements is not specified. On the other hand, it may be that this sentence is intended as an explanatory comment only.
"Step Four: Resolution" should re-emphasize the goal of achieving uniform Whois disclosure requirements. Therefore, we suggest amending the first sentence to read as follows: "Keeping in the mind the anticipated impact on the operational stability, reliability, security, or global interoperability of the Internet's unique identifier systems, and the value of uniform Whois requirements applying to all Registrars/Registries to the extent possible, the Board should consider and take appropriate action on the recommendations contained in the General Counsel's report as soon as practicable."
The Public Notice portion of the Procedure should include information about how information made less accessible can be accessed through other sources. For example, if a departure from the RAA resulted in the registrant's name but not address being made available, the notice should include information on alternative ways in which such information might be obtained. Therefore, the final sentence of the recommendation should be amended as follows: "Unless the Board decides otherwise, if the result of its resolution of the issue is that data elements in the registrar's Whois output will be removed or made less accessible, ICANN should issue an appropriate notice to the public of the resolution and of the reasons for ICANN's forbearance from enforcement of full compliance with the contractual provision in question, including relevant contact information for how such data might be accessed in appropriate circumstances."
i) If a Supermajority Vote was reached, a clear statement of the constituency's position on the issue;
See above.
(ii) If a Supermajority Vote was not reached, a clear statement of all positions espoused by constituency members;
N/A
(iii) A clear statement of how the constituency arrived at its position(s). Specifically, the statement should detail specific constituency meetings, teleconferences, or other means of deliberating an issue, and a list of all members who participated or otherwise submitted their views;
The IPC membership was notified of the request for a constituency statement on June 22. A draft constituency statement was circulated on July 8. The statement and the issue were discussed at the IPC meeting in Luxembourg on July 11. A revised version of the statement was circulated on July 20 and discussed on an IPC membership call on July 22. At that meeting, on a motion, which was seconded, it was agreed without objection to approve the constituency statement, subject to minor drafting changes.
(iv) An analysis of how the issue would affect the constituency, including any financial impact on the constituency;
As noted above, a sound policy in this area would benefit the constituency, whose members rely upon public access to Whois data to manage their domain name portfolios, enforce their rights against copyright and trademark infringers, and combat cybersquatting, among other purposes. The lack of a policy in this area could ultimately reduce this access to Whois data, make access less uniform and predictable, reduce transparency and accountability, and encourage infringers and other violators to utilize particular registrars or registries in order to evade detection or enforcement efforts. This would have an adverse financial impact on constituency members.
(v) An analysis of the period of time that would likely be necessary to implement the policy
While this question should be directed to ICANN staff, IPC believes that the recommended procedure is a sufficiently good starting point that a formal procedure could be promulgated within a short time after approval of this recommendation.

2.4 Registrar Constituency

A marked copy of the edits to the proposal recommended by the Registrar Constituency position is included below. These recommendations have been reviewed by the Registrar Constituency and ratified by a super-majority vote conducted in accordance with the Registrar Constituency Bylaws.
A summary of the recommended changes is as follows:
Section II should be positioned as guidance for the staff in establishing recommended procedures for handling WHOIS conflicts with national law. Section II therefore would be a non-exhaustive, non-binding suggestion rather than a consensus policy recommendation that must be implemented as written.
Section II, Step 2 should include additional language that ensures that the registrar in question has worked with staff to identify whether or not a solution exists that satisfies the requirements of local law and the ICANN policy in question.
There are other minor stylistic edits redlined throughout the document.
N.B. Additional text in section 2.4 is marked in italics and bold. Text that is suggested for deletion is marked in strikethrough mode.
"CONSENSUS POLICY RECOMMENDATION
In order to facilitate reconciliation of any conflicts between local/national mandatory privacy laws or regulations and applicable provisions of the ICANN contract regarding the collection, display and distribution of personal data via Whois, ICANN should:
Develop and publicly document a procedure for dealing with the situation in which a registrar or registry can credibly demonstrate that it is legally prevented by local/national privacy laws or regulations from fully complying with applicable provisions of its ICANN contract regarding the collection, display and distribution of personal data via WHOIS.
Create goals for the procedure which include:
Ensuring that ICANN staff is informed of a conflict at the earliest appropriate juncture;
Resolving the conflict, if possible, in a manner conducive to stability and uniformity of the Whois system;
Providing a mechanism for the recognition, in appropriate circumstances where the conflict cannot be otherwise resolved, of an exception to contractual obligations for all registrars with regard to collection, display and distribution of personally identifiable data via Whois; and
Preserving sufficient flexibility for ICANN staff to respond to particular factual situations as they arise.
II. <strikethrough> Text of Recommended </strikethrough> Guidance on Procedure
WELL-DEVELOPED ADVICE ON A PROCEDURE FOR HANDLING WHOIS CONFLICTS WITH PRIVACY LAW
Based on extensive research and negotiation among Task Force 2 together with the merged Task Force and ICANN staff, the following procedure for handling the policy recommendation set out in Section I above is set out as a Recommended
Step-by-Step Procedure for Resolution of WHOIS Conflicts with Privacy Law. We encourage ICANN staff to use this Recommended Procedure as a starting point for developing the procedure called for in the Consensus Policy Recommendation above.
Step One: Notification of Initiation of Action
Once receiving notification of an investigation, litigation, regulatory proceeding or other government or civil action that might affect its compliance with the provisions of the RAA or other contractual agreement with ICANN dealing with the collection, display or distribution of personally identifiable data via Whois ("Whois Proceeding"), a Registrar/ Registry must within thirty (30) days provide ICANN's General Counsel (or other staff member as designated by ICANN) with the following information:
Summary description of the nature and status of the action (e.g., inquiry, investigation, litigation, threat of sanctions, etc.)
Contact information for the responsible official of the registrar/registry for resolving the problem.
Contact information for the responsible territorial government agency or other claimant and a statement from the registrar/registry authorizing ICANN to communicate with those officials or claimants on the matter. If the registrar/registry is prevented by applicable law from granting such authorization, the notification should document this.
The text of the applicable law or regulations upon which the local government or other claimant is basing its action or investigation, if such information has been indicated by the government or other claimant.
Meeting the notification requirement permits Registrars/Registries to participate in investigations and respond to court orders, regulations, or enforcement authorities in a manner and course deemed best by their counsel.
Depending on the specific circumstances of the Whois Proceeding, the Registrar/Registry may request that ICANN keep all correspondence between the parties confidential pending the outcome of the Whois Proceeding. It is recommended that ICANN respond favorably to such requests to the extent that they can be accommodated with other legal responsibilities and basic principles of transparency applicable to ICANN operations.
Step Two: Consultation
Unless impractical under the circumstances, we recommend that the ICANN General Counsel, upon receipt and review of the notification and, where appropriate, dialogue with the registrar/registry, consider beginning a process of consultation with the local/national enforcement authorities or other claimant together with the registrar/registry. The goal of the consultation process should be to seek to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its contractual obligations to the greatest extent possible.
The Registrar should attempt to identify a solution that allows the registrar to meet the requirements of both the local law and ICANN obligations. The General Counsel can assist in advising the registrar on whether the proposed solution meets the ICANN obligations.
If the Whois proceeding ends without requiring any changes and/or the required changes in registrar/registry practice do not, in the opinion of the General Counsel, constitute a deviation from the R.A.A. or other contractual obligation , then the General Counsel and the registrar/registry need to take no further action.
If the registrar/registry is required by local law enforcement authorities or a court to make changes in its practices affecting compliance with Whois-related contractual obligations before any consultation process can occur, the registrar/registry shall promptly notify the General Counsel of the changes made and the law/regulation upon which the action was based. The Registrar/Registry may request that ICANN keep all correspondence between the parties confidential pending the outcome of the Whois Proceeding. It is recommended that ICANN respond favorably to such requests to the extent that they can be accommodated with other legal responsibilities and basic principles of transparency applicable to ICANN operations.
Step Three: General Counsel analysis and recommendation
If the local/national government requires changes (whether before, during or after the consultation process described above) that, in the opinion of the General Counsel, prevent full compliance with contractual WHOIS obligations, ICANN should consider the following alternative to the normal enforcement procedure. Under this alternative, ICANN would refrain, on a provisional basis, from taking enforcement action against the registrar/registry for non-compliance, while the General Counsel prepares a report and recommendation and submits it to the ICANN Board for a decision. Such a report may contain:
A summary of the law or regulation involved in the conflict;
Specification of the part of the registry or registrar's contractual WHOIS
obligations with which full compliance if being prevented;
Summary of the consultation process if any under step two; and
Recommendation of how the issue should be resolved, which may include whether ICANN should provide an exception for <strikethrough> the </strikethrough> all registrars/registries from one or more identified WHOIS contractual provisions. The report should include a detailed justification of its recommendation, including the anticipated impact on the operational stability, reliability, security, or global interoperability of the Internet's unique identifier systems if the recommendation were to be approved or denied.
The registrar/registry should be provided a copy of the report and provided a reasonable opportunity to comment on it to the Board. The Registrar/Registry may request that ICANN keep such report confidential prior to any resolution of the Board. It is recommended that ICANN respond favorably to such requests to the extent that they can be accommodated with other legal responsibilities and basic principles of transparency applicable to ICANN operations."
End of proposed changes to the recommendation and advice.
The Registrar Constituency proposed no changes to the remaining sections of the procedure: Step Four: Resolution and Step Five: Public Notice

2.5 Registry Constituency statement

Pursuant to requirements of the GSNO policy development process, the Registry Constituency (RyC) has concluded:
I. Constituency position
The RyC supports the general principles of the Policy/Advice Recommendation 2 on conflicts between national privacy laws and registries' or registrars' contractual obligations to ICANN. The RyC further believes that the recommended procedures should deal with the possibility of the following:
If exceptions to contractual requirements are made to accommodate local law(s) for one registrar or registry in a local jurisdiction, should the same exceptions be extended to other registrars and registries in that jurisdiction and, if so, how should that take place; and
If exceptions to contractual requirements are made to accommodate local law(s), it is possible that the variation in requirements for different registrars or registries will begin to create a fragmented experience for users and therefore create a need to revisit the contractual requirement in a broader way.
The RyC also believes that the WHOIS Combined Task Force should include in its final recommendation a further recommendation that affording tiered access to WHOIS data be available to registrars and registries as a means of complying with local legal requirements when applicable.
II. Method for Reaching Agreement on RyC Position
The RyC drafted and circulated via email a constituency statement, soliciting input from its members. RyC members suggested edits and additions to the draft which were subsequently incorporated into the final constituency statement. The statement was adopted by a unanimous vote. One constituency member, RegistryPro did not take part in the vote.
III. Impact on Constituency
The Policy/Advice Recommendation 2 in its present form would assist the members of the RyC in fulfilling their legal obligations in their respective jurisdictions. It should be noted, however, that the Policy/Advice Recommendation 2 does not purport to provide complete assurance that potential conflicts can be avoided or resolved.
IV. Time Period Necessary to Complete Implementation
We anticipate that the Policy/Advice Recommendation 2 supported by this statement would not require an extensive time period to implement.

2.6 Internet Service Providers & Connectivity Providers Constituency

Introduction
The Internet Service Providers & Connectivity Providers Constituency (ISPCP Constituency) herein provides input to the combined Whois Task Force on its recommendations on policies related to the Whois database as required by the ICANN GNSO policy development process. Specifically, the task force has put forth a recommendation on procedures to be followed in the event of a conflict between national privacy laws and registry/registrar contractual obligations to ICANN
The ISPCP constituency views on conflict of law resolution process
The ISPCP is generally supportive of the task force recommendations on how conflicts shall be addressed in the event of a conflict between the national laws of a registrar or registry's home base and its ICANN contract.
The ISPCP does not deem such conflicts to be a common occurrence in the gTLD or ccTLD space and further, we do not see any indicators that this trend is likely to change in the foreseeable future. We are guided in our belief by the examination of the record over the course of the past several years where, in the gTLD and ccTLD space, registries and registrars have rarely had reason to challenge their contractual obligations related to Whois disclosures as a result of conflicting national or local privacy laws.
This was further evidenced by the previous Whois Task Force 2 findings during a survey completed in 2004. Within the EU member states' ccTLD operators, those who submitted survey responses indicated that they work closely with their respective country's data protection authorities and are in full compliance with their respective privacy laws.
ISPCP Position
The majority of established privacy regimes throughout many regions of the world require that actual information use and disclosure practices be limited to the list of intended use and disclosure practices that are provided to the data subject at the time of data collection. Accordingly, once more conspicuous disclosure is provided and consent obtained, the subsequent use of the registrant data for Whois purposes, pursuant to the ICANN contract, is not likely to be in conflict with local or national laws.
The ISPCP believes that once registrants receive notice of the intended uses of their registration data as it relates to the Whois database, there is little reason for future use in accordance with the contract terms to somehow come in conflict with applicable privacy laws. The likelihood of a conflict is further reduced once the more conspicuous notice requirements go into affect, and registrants are better alerted to the possible uses of the personally identifiable registration data they provide.
Nevertheless, if a scenario arises whereby such conflict does arise, the ISPCP strongly favors the implementation of a process, clearly defined and transparent, that sets forth the steps in resolving any possible conflict. In reviewing the proposal set forth by the Whois task force, the ISPCP finds it to be well thought out, neutral and respectful of the needs and interests of the ICANN community and the registry/registrar organizations. Our constituency believes that no organization should be placed in a situation where it must choose between breaking its contractual obligations or violate applicable law, and we do not believe that any of the ICANN RAA terms are likely to do that.
Based upon the forgoing values, we strongly urge the Whois task force to consider the following concepts prior to finalizing its policy recommendations related to conflict of law issues.
Transparency is paramount. It is not only a major tenet of the ICANN policy development process, it is also an implicit aspect of most privacy laws. Without full disclosure and transparency in the manner that information is collected and used, there can hardly be a viable notion of privacy protection. While confidentiality of actions, negotiations and discussions may be necessary in some instances, it is not always a requirement or the most useful manner in which to resolve conflict. Thus, the ISPCP believes that to the extent possible, the ICANN community be notified when the resolution process is begun and as much as possible throughout the process as well.
Outcomes should be uniform. Some have indicated that legal obstacles will be used by registries or registrars to obtain competitive advantages, resulting in forum shopping. The ISPCP has not seen any evidence that this is in fact reality. Nevertheless, in order to remove the perception that this may be happening, the recommendation should emphasize the importance of uniformity and consistency of handling conflicts should they arise.
It is worthy to note that transparency of the process will inevitably lead to more uniformity and better consistency among conflicts that do arise.
Review should be ongoing. The ISPCP believes that there will be some lessons learned from the first instance where this process is implemented. With substantial input from the relevant registry or registrar, together with all constituencies, there should be a review of the pros and cons of how the process worked, and the development of revisions designed to make the process better and more efficient, should the need arise again at some point in the future.
Again, we'd like to highlight the fact that this goal will be easier met when there is transparency and uniformity throughout the process.
Accuracy is the goal. If this and other recommendations do not work towards improved accuracy, the system will remain substantially flawed. The ISPCP task force members have participated in good faith to achieve the improved privacy protections that are important to community. The constituency expects that all members of the task force, and the chair and ICANN staff especially, show commitment to improved accuracy and quickly move on to developing changes aimed at the same.
Conclusion
The ISPCP hereby thanks the task force for its work in this matter and looks forward to seeing a better Whois experience for all stakeholders who develop, populate, oversee and use the Whois databases.
Annex 1
Relevant provisions of the Registrar Accreditation Agreement
"3.7.2 Registrar shall abide by applicable laws and governmental regulations."