FINAL TASK FORCE REPORT ON WHOIS SERVICES

12 March 2007

GNSO WHOIS TASK FORCE

STATUS OF THIS DOCUMENT

This is the Final Task Force Report on Whois Services of the GNSO Whois Task Force. It is being submitted to the GNSO Council, in conclusion of section 9c (Annex A) of the ICANN Bylaws, and for the consideration of the Council.

SUMMARY

This report concludes the work of the Whois Task Force on the GNSO policy development process (PDP) on Whois which seeks to build consensus on policy issues in the generic top level domain (gTLD) space.

1 Contents

1 Contents.. 2

2 Executive Summary.. 4

3 Introduction and Acknowledgments.. 6

Introduction. 6

Acknowledgments. 6

4 Task Force Recommendation.. 7

5 Minority Recommendation of the Task Force.. 11

"Special Circumstances" Model for Whois Policy. 11

6 Success Metrics.. 16

7 Summary of public comments.. 17

7.1.1 Table 7.1?OPoC proposal: issues raised. 17

7.1.2 Table 7.2 ?OPoC proposal: suggestions for development 22

7.1.3 Table 7.3? Special Circumstances Proposal: issues raised. 23

7.1.4 Table 7.4?Special Circumstances Proposal: suggestions for development 25

7.2 Summary by topic. 27

7.2.1 Proxy registrations. 27

7.2.2 Data accuracy. 27

7.2.3 Privacy. 28

7.2.4 Distinguishing between commercial and individual/non-commercial registrants 29

7.2.5 Technical or other restrictions to data access. 30

7.2.6 Other points raised. 31

7.3 Summary of support for the proposals. 32

8 Summary of voting on the Task Force Recommendation.. 35

8.1 Table 8.1? Summary of voting. 35

9 Historical Background to this Report.. 37

10 Staff comparison of policy recommendation and minority proposal 40

10.1 Term of Reference 2: Purpose of the contacts. 40

Summary of task force discussion. 42

10.2 Term of Reference 3: Public Access to Data. 44

Summary of task force discussion (including proposal for access to data) 45

10.3 Term of Reference 4: Inaccurate Data. 48

Summary of task force discussion. 49

11 Constituency Statements.. 50

11.1 Requirements for constituency statements. 50

11.2 Statement of the Commercial and Business Users Constituency. 51

13.3 Statement of the Intellectual Property Constituency (IPC)

13.3 Statement of the Registrar Constituency. 64

13.4 Statement of the Registry Constituency. 66

13.5 Statement of the Non Commercial Users Constituency. 72

13.6 Statement of the Internet Service Providers and Connectivity Providers Constituency 75

Appendix A ? Full Task Force Terms of Reference.. 78

Appendix B ? Proposal to the Task Force by Avri Doria, Milton Mueller, Robin Gross and Wendy Seltzer.. 82

Appendix C ? Proposal to the Task Force by Marilyn Cade.. 85

Appendix D ? Work Processes and Outreach Activities of the Task Force, 2005-2007 89

Appendix E ? Relevant GNSO Council Resolutions.. 91

2 Executive Summary

This is the Final Task Force Report on Whois Services. This report is intended to conclude the work of the Whois Task Force on the GNSO policy development process (PDP) on Whois which seeks to build consensus on policy issues in the generic top level domain (gTLD) space.

This report sets out the key findings of the Whois Task Force since it was convened in February 2005 (amalgamating three task forces on different aspects of Whois).

The task force has reached agreement on the following issues:

• Many registrants do not understand the meaning or purpose of the different Whois contacts (billing contact, administrative contact, technical contact).
• If changes are made to the Whois service, awareness-raising for registrants will be needed.
• New mechanisms to restrict some contact data from publication should be adopted to address privacy concerns.

The Task Force did not arrive at Supermajority support for any of the proposals it considered. The Task Force Policy Recommendation below was supported by a simple majority of Task Force members during a Task Force email vote concluded on 10 March. It is favoured by the following Task Force constituencies/members:

-          Registry Constituency

-          Registrar Constituency

-          Non Commercial User Constituency

-          Nominating Committee appointee.

The Task Force Policy Recommendation was also supported by the non-voting At Large liaison to the Task Force.

Other proposals discussed by the Task Force are contained in Section 5 as well as Appendices B and C of this document. The "Special Circumstances" proposal in Section 5 was supported by a minority of Task Force members from the following constituencies:

-          Commercial and Business User Constituency

-          Intellectual Property Constituency

-          Internet Service Providers and Connectivity Providers Constituency

Summary of the Task Force Policy Recommendation to the GNSO Council

The policy recommendation supported by a majority of Task Force members is the OPoC (Operational Point of Contact) proposal submitted by the Registrar Constituency and subsequently developed by the Task Force.

The OPoC (Operational Point of Contact) proposal (full text in Annex A) was circulated by the registrar constituency on 29 November 2005, and a revised version was submitted to the WHOIS Task Force for further development on 18 January 2006. It proposed to deal with the issue that "the amount of data that ICANN requires registrars to display in the Whois is facilitating all sorts of undesirable behaviours like renewal scams, data-mining, phishing, identity theft, and so on." The OPoC proposal aimed to "rationalize the Whois data output and implement a new contact type called the 'Operational Point of Contact'". (Email from Ross Rader to the task force and the registrar constituency, 29 November, 2005).

• The OPoC proposal was the subject of task force development work from January to October 2006. It includes input and revisions from all constituencies participating in the Task Force.

The OPoC proposal envisages requiring registrants to use an OPoC in place of the current administrative and technical contact details in the published Whois. This would allow registrants to only publish the contact details of the OPoC, rather than the administrative and technical contact details. In the case of an issue with the domain name, the OPoC would contact the registrant.

The OPoC proposal also includes a mechanism for notifying and correcting inaccurate Whois data. It does not include any new mechanism for access to data not published in Whois by, for example, law enforcement agencies or intellectual property rights holders. In task force discussions, proponents of the OPoC proposal have said that continuing the current practice whereby law enforcement agencies and other data requestors work directly with Registrars to arrange for access to specific contact data on a case by case basis provided that such practices are backed up with a statement of best practices that all registrars could employ. The Registry Constituency, which voted in favor of the OPOC proposal, believes that considerable work still needs to be done to address the issue of access to non-public Whois information by law enforcement and others with a legitimate need for access.

Summary of public comments

A public comments period on the Preliminary Task Force report ran from 24 November, 2006 to 15 January, 2007.

Public comments were particularly invited on:

• The Operational Point of Contact (OPoC) proposal
• The Special Circumstances proposal

Some broad directions for development of the Task Force policy recommendation that were raised through the public comments:

• The OPoC should ensure contact with the registered name holder in a defined and short period of time.
• OPoCs should have specified responsibilities for passing communications, including legal notifications, to the registered name holder.
• There need to be clear, consistent, timely and predictable procedures for obtaining access to unpublished data.

The proponents of each proposal provided responses to the public comments received (see section 7 of this report). The proposals have not subsequently been revised.

Next steps

This Task Force Report will be considered by the GNSO Council during the first and/or second quarter of 2007. The Council will then make a policy recommendation to the ICANN Board.

3 Introduction and Acknowledgments

Introduction

This document is the Final Task Force Report on the Whois Service. This report addresses the three remaining items in the terms of reference of the Whois Task Force (set by the GNSO Council on 2 June, 2005, see http://gnso.icann.org/policies/terms-of-reference.html or Annex C of this document):

• purpose of the Whois contacts (e.g. administrative or technical contact);
• public access to data;
• improvement of notification of inaccuracy of data.

The Whois Task Force has completed its work on two other items in the original terms of reference; a procedure for conflicts between Whois contractual requirements and national or local privacy laws, and defining the purpose of the Whois service. The Final Task Force Report on the Purpose of Whois and the Whois Contacts (15 March, 2006; http://gnso.icann.org/issues/whois-privacy/tf-report-15mar06.htm) included constituency statements on the purpose of the Whois contacts, but the subsequent discussion in the GNSO Council did not yield a conclusion on this topic. This report re-considers the purpose of the contacts in the light of the subsequent task force work.

The GNSO Council passed the following resolution regarding the definition of the purpose of Whois, on 12 April, 2006, (http://gnso.icann.org/meetings/minutes-gnso-12apr06.shtml, item 3):

"The GNSO Council recommends that the WHOIS task force use the following definition: "The purpose of the gTLD WHOIS service is to provide information sufficient to contact a responsible party for a particular gTLD domain name who can resolve, or reliably pass on data to a party who can resolve, issues related to the configuration of the records associated with the domain name within a DNS name server." as a working definition to allow the task force to proceed on terms of reference (2), (3), and (4)

This definition has been used by the task force as its working definition. This definition has been adopted as a working definition for the Task Force, and the Council intends to consider improving the wording of the WHOIS service definition so that it is broadly understandable.

This report includes constituency statements from each of the GNSO constituencies, and also a summary of public comments received during the public comment period from 24 November, 2006 to 15 January, 2007. At the end of the public comment period, the task force considered the public comments received, and the constituency statements.

Acknowledgments

This document has been created in the course of the work of the Whois Task Force.

The Whois Task Force is comprised of the following members:

Chair: Jordyn Buchanan (formerly of the Registry and Registrar Constituencies/appointed by Council as independent expert, without voting status; reelected as chair)

Commercial and Business Users Constituency

David Fares

Marilyn Cade

Sarah Deutsch

Internet Service Providers and Connectivity Providers Constituency

Tony Harris *

Greg Ruth*

Maggie Mansourkia

Intellectual Property Constituency

Steve Metalitz

Niklas Lagergren

Ute Decker

Non-Commercial Users Constituency

Milton Mueller

Robin Gross

Registrars Constituency

Paul Stahura

Ross Rader*

Tom Keller*

Tim Ruiz (alternate)

Registry Constituency

David Maher

Ken Stubbs *

Simon Sheard

Appointed by Council as independent expert with voting rights:

Avri Doria*

At Large Advisory Committee Liaison (non-voting)

Wendy Seltzer

Bret Fausett

(Task force members whose names are marked with a * are also members of the GNSO Council.)

4 Task Force Recommendation

The task force proposes the following as its policy recommendation to the GNSO Council:

Proposal for Implementing an Operational Point of Contact

There are four main areas of consideration dealt with by this proposal;

1. The type of contact data published by Registrars via Whois

2. The type of contact data published by Registries via Whois

3. The mechanism by which inaccurate data is dealt with and corrected

4. The mechanism by which prospective gaining registrars obtain the underlying contact information from prospective losing registrars at the time of domain name transfers.

This proposal pre-supposes that 1) domain name contact data not be available through any sources other than those discussed by this proposal, unless by Registrars, and in that case at the Registrar's option, and that 2) regardless of the information displayed, that the domain name contact data collected by registrars remain as specified in the RAA ("Underlying Whois Contact Data").

Scope

This proposal encompasses the Whois services (commonly referred to as "port 43 whois" and "web whois" or "port 80 whois") operated by all ICANN accredited registrars and all gTLD registries (including .aero, .biz, .com, .coop, .info, .jobs, .museum, .name, .net, .org, .pro and .travel as of January 18., 2006).

Purpose of the Points of Contact

1. Purpose of the Registered Name Holder

The registered name holder is the individual or organization that registers a specific domain name. This individual or organization holds the right to use that specific domain name for a specified period of time, provided certain conditions are met and the registration fees are paid. This person or organization is bound by the terms of the relevant service agreement with the Registry operator for the TLD in question.

2. Purpose of the Administrative and Technical Contacts

Under this proposal, the administrative and technical contacts would no longer be displayed within the Whois system. As a result, they would no longer have a purpose within the context of Whois.

3. Purpose of the Operational Point of Contact

This proposal introduces the Operational Point of Contact, which would be collected by registrars and displayed in response to Whois queries regarding specific domain names. The purpose of the operational point of contact is to resolve, or to reliably pass on data to resolve, operational issues relating to a domain name. At a minimum, this must include the resolution of issues relating to the configuration of the records associated with the domain name within a DNS nameserver. The operational point of contact may also be capable of resolving additional types of issues based on an agreement with the registered name holder to do so.

4. Notifying Registrants of the Purpose of the Points of Contact

ICANN will develop a user guide describing the various contacts and the changes in information provided as part of the Whois service. This guide should provide information for both registrants as well as users of the Whois service. At the time the registrar sends its annual Whois Data Reminder Policy notice to each registrant, it must include a link to the ICANN-developed guide on the purpose of each contact.

The Type of Contact Data Published by Registrars;

Accredited Registrars will publish three types of data pertaining to the domain name registration in their respective gTLD Whois repositories;

1. The name of the Registered Name Holder

2. The country and state/province of the Registered Name Holder

3. The contact information for the primary operational point of contact (oPOC), which must include, but is not limited to;

1. The contact name of the oPOC

2. The contact address of the oPOC

3. The contact telephone number of the oPOC

4. The contact email address of the oPOC

4. The date of the initial registration of the domain name (creation date)

5. The date of the expiration of the current term of the domain name (expiry date)

6. The following registry level data:

1. The Registered name

2. The identity of the Sponsoring Registrar

3. The URI of the authoritative Whois server

4. All authoritative nameserver names associated with the domain name registration record

5. The status of the Registered Name (LOCK, HOLD, EXPIRED, or any other Registry specified value)

Registrars must allow a Registrant to provide a minimum of two operational points of contact. As a condition of registration, Registrants must provide a minimum of one operational point of contact. If a Registrant provides a second operational point of contact, the Registrar must pubish this data via whois. If the Registrant has not specified a second operational point of contact, the Registrar is not obligation [ad: obligated] to publish a null or empty record via the Whois service. Registrars may choose to allow Registrants to specify additional operational points of contact beyond the second operational point of contact. If the Registrant exercises this option, the Registrar must publish these additional records in the record of delegation for the domain name in question in a manner consistent with the publication of multiple nameservers in other areas of this same record.

This proposal does not require the publication of any additional data; however Registrars may choose to provide additional data at their discretion.

The Type of Contact Data Published by Registries;

gTLD Registries will publish a limited data set concerning each Registered Name. Registries must not publish or provide any additional data. This Registry Level data is solely limited to;

1. The Registered name

2. The identity of the Sponsoring Registrar which shall consist of separate fields indicating;

3. the Registrar Name and;

4. the corresponding IANA Registrar Identification Number

5. The URI of the authoritative Whois server

6. All authoritative nameserver hostnames and corresponding IP addresses associated with the domain name registration record

7. The status of the Registered Name (LOCK, HOLD, EXPIRED, or any other Registry value specified in the EPP RFC)

8. The date of the initial registration of the domain name (creation date)

9. The date of the expiration of the current term of the domain name (expiry date)

Correcting Inaccurate Whois Data;

In addition to preserving the existing requirement for Accredited Registrars to promptly update registration records when a Registered Name Holder provides them with updated information , Registrars must also positively respond to notices of alleged inaccuracies in a timely manner. Specifically, when a Registrar receives notice of an alleged inaccuracy in the whois record for a particular domain name;

1. the Registrar must notify the Operational Point of Contact or the Registered Name Holder in a timely manner.

2. The oPOC or the Registered Name Holder must correct the alleged inaccuracy or defend the accuracy of the data, also in a timely manner.

3. If the oPOC or the Registered Name Holder does not update the contact record with corrected information within this time period, the Registrar must either place the domain name on "hold" or revoke the registration.

4. Before accepting the new information, the Registrar must verify that the oPOC or the Registered Name Holder is contactable using the new email address provided.

5. If the basis for the original complaint of inaccurate data included data elements other than the e-mail address, the Registrar must take reasonable steps to validate corrections to these other data elements before accepting them.

A standardized mechanism should be used to convey notices of alleged inaccuracy from the internet community and distribute them to the relevant registrar.

Facilitating Inter-registrar Domain Name Transfers

In order to ensure continued domain name portability, Registrars must continue to be able to transfer detailed contact records between one another at the request of the Registered Name Holder or oPOC. Therefore, this proposal recommends that the Sponsoring Registrar must make the data outlined in section 3.3.1 of the RAA be made available to the prospective gaining registrar upon request for the purpose of confirming the Registrant/oPOC identity and validating the authenticity of the domain name transfer request. This proposal further recommends that this mechanism be augmented, when appropriate, by the use of EPP AUTH-INFO tokens/codes.

Finally, this proposal recommends that the existing Inter-registrar Transfer policy be amended to recognize the authority of the Operational Point of Contact and sunset that of the Administrative, Technical and Billing Contacts.

5 Minority Recommendation of the Task Force

This section contains a proposal considered by the task force that did not receive sufficient votes to emerge as the majority policy recommendation to the GNSO Council.

"Special Circumstances" Model for Whois Policy

This paper describes an alternative model for modifying current gTLD Whois policy. It calls for a procedure to accommodate the needs of certain individual non-commercial registrants for special treatment with regard to restricting public access to some of their contact data. It draws upon the system that has been place for some time in the Dutch country code Top Level Domain, .NL, with adaptations necessary for translating that system to the gTLD environment.

Main elements of the Special Circumstances proposal:

1. An independent third-party vendor processes and decides upon "Special Circumstances" applications. ICANN would choose a trusted independent third-party vendor to receive, process and decide upon requests from individual gTLD registrants to curtail public access to their Whois data based on special circumstances. The vendor would be required to apply the criteria developed below, to process applications online, and to render a decision in a very short time frame (e.g., 5 days). It would also be required to carry out these tasks within a budget negotiated with ICANN.

NOTE: In one variant on the proposal, ICANN would choose five independent vendors, one in each of ICANN's global regions, each applying a common set of criteria for considering "special circumstances" applications from individual registrants within that region. For simplicity only, the rest of this proposal will refer to a single vendor.

2. Eligibility criteria for "Special Circumstances." The "special circumstances" option would be open only to individual registrants who are using or will use the domain name for non-commercial purposes, and who can demonstrate that they have a reasonable basis for concern that public access to specific data about themselves (e.g., name, address, e-mail address, telephone number) that would otherwise be publicly displayed in Whois would jeopardize a concrete and real interest in their personal safety or security that cannot be protected other than by suppressing that public access. An individual would be able to hold special circumstance designation for only a limited number (e.g., 5) gTLD domain names at a time. Social service agency providers serving qualifying individuals (e.g., abused women's shelters) could also apply for the designation.

3. Further development of criteria. Beyond the general requirements set forth in paragraph 2, the specific criteria and procedures to be applied for adjudicating such requests would be developed in one of two ways:

the selected third-party vendor would propose criteria which would then be reviewed by a working group consisting of GNSO and GAC representatives; or

a joint GNSO-GAC working group would develop the criteria in consultation with the third-party vendor.

4. Funding administration of the Special Circumstances system. To defray the costs of administering the system, a pre-set proportion of one or more existing volume-sensitive (i.e., per registration transaction) fees currently paid by registrars and/or registries to ICANN would be budgeted for the third-party vendor's operations. Under this model, neither registrants, registrars nor registries would incur additional costs.

5. Application for Special Circumstances at the point of registration. Once the system is operational, registrars would be obligated to advise individual registrants at the time of registration of the option to seek a "special circumstances" designation, and to provide a standard application form issued by the vendor, which registrants could then complete and submit via the registrar.

NOTE: As a variant, registrars could provide registrants a link to the site of the third-party vendor.

6. Provision of data to registrars. Current requirements for registrants to provide registrars with full and accurate contact data and to keep it current, as a condition of registration, would continue to apply to all registrants, including those who have been determined qualified for special circumstances status. Registrars would continue to hold all data. Existing proxy registration services operated by or in connection with registrars would be phased out, and individual registrants participating in such services would be provided with an opportunity to apply under the "special circumstances" mechanism.

7. Display of data and operation of the domain are withheld pending determination of a Special Circumstances application. The registrant's data would be publicly displayed (in accordance with the Registrar Accreditation Agreement) unless and until the third-party vendor notified the registrar (or confirmed) that a special circumstances application by that registrant had been received for the domain name in question. In the case of a new registration, during the (5-day) pendency of the application, the contact information of the registrar would be displayed in publicly accessible Whois rather than the contact information of the registrant, but the domain would be placed in a status that would not allow it to resolve.

NOTE: The preceding paragraph describes the process in a "thin registry" environment. In a "thick registry," notification of receipt of the application, and of the vendor's action upon it, would also be communicated to the registry for purposes of its Whois service.

8. Response to Whois queries for Special Circumstances registrations. If the third-party vendor decides that the applicant has shown the requisite special circumstances, it will notify the registrant, registrar and (in a thick registry environment) the registry. During the life of the special circumstances designation, the contact data for the registrar would continue to be displayed in lieu of the registrant data for all data elements that are the subject of the special circumstances application.

9. Enforcement of non-commercial use criteria. During the life of the special circumstances designation, the third-party vendor would be responsible for spot-checking Internet resources tied to the domain name (e.g., website) to ensure that the use remained non-commercial during the life of the designation (under specific criteria established under paragraph 3 above). If commercial use is observed, the vendor would notify the registrant and registrar and terminate the special circumstances designation.

10. Term and renewal of Special Circumstances designation. The Special Circumstances designation would remain in effect for a set time period (e.g., one year). Special circumstances designations would not be transferable. As part of the Whois Data Reminder Policy, registrars would notify registrants who hold special circumstances designations of the scheduled expiration date of their designation, and provide a link to the vendor so that a registrant could apply for renewal of the designation if s/he still qualified for it.

11. Challenges to Special Circumstances designation. Procedures would be developed for the following: (a) appeal by the registrant of an adverse decision by the vendor on the registrant's special circumstances application; and (b) methods for law enforcement and others with a legitimate complaint of abuse to seek from the third-party vendor access to contact information held by the registrar on registrants in the "special circumstances" category. The latter procedures would be coordinated to the extent feasible with existing procedures such as the UDRP.

12.              Renewal of vendor contract and reporting on system operation. The third-party vendor would report within six months, and annually thereafter, on the operation of the "special circumstances" mechanism, and its contract to operate the mechanism would be subject to renewal or re-competition every 5 years. The specific criteria and procedures developed under point 3 would be subject to review and adjustment on an annual basis, and ad hoc, under the auspices of the working group described there.

Background Information

The .NL Model

.NL is a very large registry, ranking seventh in the world (and third among the ccTLDs). It has over 1.9 million domain names registered. The Netherlands also has a strong privacy/data protection law which is based upon the EU Data Protection Directive. The operator of .NL (called SIDN) has taken great pains to ensure that its Whois policy complies with the Dutch data protection law.

.NL provides a very robust publicly accessible Whois service, very similar to what is currently available in the gTLDs. Article 23.2 of the "Regulations for registration of .nl domain names"[1] provides:

"The public section of the SIDN Register shall include the following details, among others, for each Domain Name or Personal Domain Name, except when the Applicant for a Domain Name or the Holder of a Personal Domain Name has requested SIDN to replace certain details by the details of the Participant:

- the Domain Name or Personal Domain Name;

the name and address of the Holder of the Domain Name (and the address provided in the Netherlands, if applicable);

- the name, telephone number and e-mail address of the Administrative Contact Person for the Holder of the Domain Name;

- the name, telephone number and e-mail address of the technical contact person for the Holder of the Domain Name and/or the Participant concerned;

the Participant concerned;

technical details."

Article 23.3 of the same document provides:

"The public section of the Register shall be open to public electronic consultation."

Under the .NL system, a registrant can ask that some data be withheld from public access (or that the "Participant's"[2] data be substituted). The holder or applicant must submit a written request for data to be withheld from the public section of the register.[3] This request must be made via the Participant acting for the holder/applicant and needs to explain why the holder/applicant believes the data should not appear in the public section of the register. The request will only be granted if special circumstances are deemed to exist. To this end, SIDN weighs up the various interests at stake. If SIDN rejects such a request, an appeal may be made to the Complaints and Appeals Body.[4]

Another SIDN document[5] gives more details about the "special circumstances" criterion:

"For each individual opt-out request the consideration has to be made whether ? and if so, to what extent ? there are special circumstances justifying the granting of the opt-out request. SIDN uses the criterion that granting of the request may be justified if it can be demonstrated that (a) there is a concrete and real interest at stake and that (b) a report has been filed with the police and/or (c) other precautions/measures have been taken, for instance protection of the data in question with other bodies or organisations.

"A general fear, not specified or motivated in further detail, of receiving spam, of any invasion of privacy or of any individual with malicious intent (a possibility that in principle always exists) is in itself insufficient ground for granting an opt-out request."

The document states that an opt-out request should be granted only when "the specific conditions have been met that make the granting of this request an absolute requirement and that there is no other way to achieve this."

The .NL system demonstrates that a publicly accessible Whois with a broad range of data can be maintained, even in a jurisdiction with strict privacy laws, and that even a relatively large registry can effectively operate a system of evaluating limited "special circumstances" under which data may be kept hidden on a case-by-case basis.

Adapting the .NL Model to the gTLD Environment

For the so-called "thin" registries, notably .com and .net, it would be relatively simple for the registrar simultaneously to collect an application for Special Circumstances at the point of registration, and to configure the domain not to resolve and for information not to be displayed in the Whois database, pending decision on the Special Circumstances application. This is because , in the "thin" registries, the registrar is both the entity responsible for the registration of domains and the entity responsible for maintaining public access to the Whois database. In the "thick" gTLD registries (e.g., .info), it would be only slightly more involved for the registrar and registry to set up a system for the registry's receipt and processing of requests to suppress public access to contact data based on "special circumstances."

The main challenge in adapting the .NL model to the gTLD environment involves who operates the system. Although the registrar remains the sole (in thin registries) or primary provider of complete Whois data, registrar operation of a "special circumstances" system for suppressing public access to Whois data raises two problems: cost and consistency/integrity.

Of course the cost of operating such a system would depend to some extent on the volume of requests, but there would be some fixed costs. Presumably, registrars could be allowed to charge for this service in order to recover their costs, but this could raise perception concerns (requiring vulnerable registrants to bear additional costs); and competitive pressures from larger registrars, or from those that can cross-subsidize this cost from other non-registration services, could make it impractical for many registrars to recover their costs. (At the same time, many registrars already operate proxy or "private" registration services, none of which is free, so perhaps these competitive pressure and perception concerns are less powerful than some fear.)

A more difficult problem is consistency and integrity. The "special circumstances" that would justify curtailing public access can never be precisely defined in advance, and inconsistent decisions about who does or does not qualify for this status seem inevitable if multiple entities are responsible for deciding applications for Special Circumstances. More significantly, particularly if registrars can recover their costs or even treat the "special circumstances" mechanism as a profit center, there are strong incentives to grant every request, no matter what the merits. That would defeat the purpose of the "special circumstances" mechanism, and it would become almost indistinguishable from the proxy services that currently abound, except that each registrar will be obligated to offer one.

This proposal involves centralizing the processing of "special circumstances" in an independent third party, in order to ameliorate these concerns over consistency, integrity, and cost. The preceding proposal reflects this model.

6 Success Metrics

The following success metrics have been developed by the task force to provide guidance for the GNSO and ICANN staff in measuring the success of Whois policy recommendations as and when they are implemented. They will be supplemented by feedback from ICANN staff as detailed policy recommendations are finalized.

Terms of Reference #1 and #2:

1) ICANN should report back periodically on the steps that it has taken to make people aware of any changes to the Whois system as well as the purpose of Whois and the contacts contained in Whois.

2) ICANN should gather data and report back on the awareness of the purpose of Whois as well as the purpose of the contacts contained in Whois.

Term of Reference #3:

1) ICANN should track and compare the number of privacy related complaints received regarding Whois, over time, by month or by quarter.

2) ICANN to measure ability to contact responsible parties for a sampling of domains both before changes go into effect and afterwards.

3) ICANN to survey users of Whois to determine whether contactability improves.

TERMS OF REFERENCE #4:

1) ICANN to evaluate accuracy of a sampling of domains both before and after policy changes to determine whether they improve accuracy.

2) ICANN to report periodically on compliance with policies requiring that registrars disable domains if data is inaccurate and is not updated.

7 Summary of public comments

The public comments period on the Preliminary Task Force report ran from 24 November, 2006 to 15 January, 2007. Seventy seven comments were received. Of these, forty three were on-topic and not duplicates.

The Task Force appreciates the significant effort that went into preparing thoughtful and detailed inputs on the issues and proposals in the Preliminary Task Force Report.

Public comments were particularly invited on:

• The Operational Point of Contact (OPoC) proposal
• The Special Circumstances proposal
• The five proposals in the discussion on access to data

The public comments are archived at;

http://forum.icann.org/lists/whois-services-comments

The Preliminary Task Force Report on Whois Services is available at;

http://gnso.icann.org/issues/whois-privacy/prelim-tf-rpt-22nov06.htm

The four tables below group the comments received into a first column, their support by specific organizations into a second, and a response or discussion of the points raised by the initiators of each proposal. The response to public comments regarding the OPoC proposal was prepared by Ross Rader, of the Registrars Constituency of the GNSO. The response to public comments regarding the Special Circumstances proposal was prepared by Steve Metalitz, of the Intellectual Property Constituency of the GNSO.

7.1.1 Table 7.1?OPoC proposal: issues raised

7.1.2 Table 7.2 ?OPoC proposal: suggestions for development

7.1.3 Table 7.3? Special Circumstances Proposal: issues raised

7.1.4 Table 7.4?Special Circumstances Proposal: suggestions for development

7.2 Summary by topic

The following section summarises comments on cross-cutting themes that are not solely related to the two proposals but were the subject of significant public comment.

7.2.1 Proxy registrations

Proxy registrations should be forbidden/phased out: eBay Inc., American Heart Association, March of Dimes Birth Defects Foundation, Motion Picture Association.

Several rights holders said they encounter difficulties today in accessing unpublished data regarding proxy registrations: The Walt Disney Company, eBay Inc.

7.2.2 Data accuracy

OPoC provisions on data accuracy are a step forward; The Walt Disney Company, eBay, The American Intellectual Property Law Association said the segment of the OPoC proposal regarding accuracy "is (the) one segment of the OPoC proposal that we could support, but only in the context of maintaining the status quo of an open Whois system, such as would occur under the Special Circumstances proposal."

Registrars should be required to pro-actively verify the accuracy registrant contact data: eBay Inc., The Walt Disney Company, However, one commenter said verifying the accuracy of contact data is hardly achievable on a general basis.

Registrars should be obliged to terminate registrations with inaccurate Whois data: Special Task Force on Counterfeiting and Piracy Committee of the Intellectual Property Owners Association, American Intellectual Property Law Association, Best Western International Inc.

Rights holders encounter inaccurate Whois data frequently and are unsatisfied that registrars do enough to correct inaccurate data. Some called for better enforcement of existing provisions in the Registrar Accreditation Agreement on registrars' obligations regarding inaccurate Whois data.

Best Western International Inc. raised the question that "it is unclear how a brand owner would be able to request correction of such data if it cannot access the registrant's WHOIS information in the first place."

7.2.3 Privacy

Several commenters from the rights holder perspective said the existing publication of Whois data strikes a balance between privacy rights and other concerns. CAUCE (the Coalition Against Unsolicited Commercial E-mail) said that allowing criminals to obfuscate their activities by cloaking Whois data "will lead to increased levels of privacy violations by way of spam, viruses and spyware. Removing Whois data might provide marginally more privacy to the relatively small number of individuals who register domains, at a disproportionate cost to Internet users at large."

Two commenters noted that the report did not include a study of privacy laws around the world, and that the absence of such an analysis has an impact on the ability to develop a policy that meets national laws. One of these commenter noted that the OPoC proposal was the only way to meet different national privacy laws. Patrick Vande Walle said that "Rather than looking at what we can agree on within the narrow ICANN community, we should be looking at what is realistically feasible within the existing legal frameworks and agree on a common denominator."

The Electronic Privacy Information Center said that the Whois policies conflict with national privacy laws. The original technical purpose of Whois should be adhered to, and that access to Whois data for concerns other than technical issues should be subject to due process. EPIC said anonymous registration of domain names "may be critical for political, artistic and religious expression." Chuck Wilson raised a similar concern regarding the damage Whois can do "to the Internet as a forum for free speech and public information." The New York State Office of the Attorney General Internet Bureau said:

"We are sensitive to the privacy interests of individuals who wish to use a domain name for non-commercial purposes, such as speech; especially those who wish to do so anonymously. However, ... we believe that maintaining a publicly available database of contact information for registrants of commercial websites does nto violate any privacy law, rule, directive, or individual privacy interest."

7.2.4 Distinguishing between commercial and individual/non-commercial registrants

Several commenters suggested distinguishing between different types of registrants, e.g. individuals, non-commercial and commercial registrants, and offering proxy registrations to individuals using domain names for non-commercial purposes. Matt Scholl noted that "Nowadays, many websites are owned by individuals for individual purposes. Just as there is no requirement to disclose private name and address information for telephone owners, there should be no requirement to disclose private name and address information for website owners."

Danny Younger submitted the following proposal:

The New York State Office of the Attorney General Internet Bureau said it believes "maintaining a publicly available database of contact information for registrants of commercial websites does not violate any privacy law, rule, directive, or individual privacy interest." The New York State Office of the Attorney General Internet Bureau proposed that "holders of commercial domain names" continue to be required to submit their contact information for public access via Whois. Noting a 2003 OECD report that said commercial name holders intent on fraud may falsely use a non-commercial registration, the AG office supported further empowering registrars by requiring them to put a domain name on hold or revoke it if inaccurate Whois data regarding the name holder's status is not corrected.

The Electronic Privacy Information Center drew attention to the operation of Australia's TLD, .au, which does not disclose individual registrants' names, addresses and telephone and fax numbers.

7.2.5 Technical or other restrictions to data access

There are two types of 'public access'; web publication of Whois (the current system) and 'on request' confirmed access by request to registrar/thick registry with response on additional confirmation. Neither restricts access to data, but 'on request' access is considered less vulnerable to data harvesting.

The Whois Subcommittee of the International Trademark Association said that "'hybrid' proposals to the task force that "condition access to full Whois information on the searcher clearing technical security measures and/or contractually agreeing not to use the information for a list of specified improper uses" merit further discussion.

Mr. C.A. Fontein of OPTA, the Dutch Post and Telecommunications Authority, asked the task force to take enforcement tasks into consideration when setting boundaries to the access to Whois. He said: "Whether direct access to Whois data is granted to enforcers through some way of tiered or encoded access or in any other way, it is crucial to make the Internet a safer place". OPTA suggested a distinction between 'Type 1' requests for Whois data and 'Type 2' requests:

Volkswagen AG said:

"From our point of view it would not unduly restrict users or users' legitimate interests if sign-on verification were to be required before submitting a query, or if other technical means are used to prevent an automated reading/downloading of whois database data. Contractual restrictions on the use of whois data such as those practiced by the German Registry DENIC eG, that require electronic acceptance of the use restrictions before each request is answered, would not constitute an impairment of our legitimate interests. The state data protection commissioner has confirmed that this practice complies with the strict requirements of the German Data Protection Law."

Patrick Vande Walle said that "accuracy of the whois data will improve when it will become less public and proper checks are made on who requests the data nd for what purpose."

Karl Auerbach called attention to previous proposals that "anyone who asks to view whois data should be required to submit to a permanent and publicly visible ledger the following information:

- Identity (i.e. name, contact information) of the person requesting access

- A short but factual statement describing, with particularity, what specific rights of the person making the inquiry are believed to have been violated by the data subject described in the whois record being accessed."

Dominik Fillip said that; "At minimum, the (rights) Holder should be allowed to hide direct access to the data (name, state and country only) and be allowed the 'on-request' public access".

7.2.6 Other points raised

RE/MAX International Inc., a real estate franchiser, did not support the OPoC proposal because it uses Whois to determine if it will take legal action against domain name registrants who may or may not be its own franchisees.

Referring to the adopted purpose of Whois, several rights-holders asked whether concerns regarding fraud or trademark infringement would be considered by an OPoC to be an 'operational issue relating to a domain name'. Two rights-holders said that 'operational issues' did not include rights holder issues, or would not be interpreted as such by registrars.

A small number of commenters raised the concern that if Whois changes significantly, there will be a consequence for the UDRP (Uniform Dispute Resolution Procedure; http://www.icann.org/udrp). This might mean that the UDRP would have to be altered. The National Arbitration Forum said the following points would be consequences of adopting the OPoC proposal:

"First, if the complainant to a domain name dispute is unable to ascertain who the actual registrant of a domain name is, it could become difficult or impossible to make a fair assessment of the complainant's case with respect to the elements of the various Policies.

Second, under the current UDRP (and other Policies), a respondent has 20 days from commencement of a case to respond to a UDRP complaint. If the National Arbitration Forum and other providers are obligated to serve respondent through an OPoC, it is not only possible, but likely, that delivery of important commencement documents would be at best, delayed and at worst, withheld. We are aware that some registrars do not pass on mail received on behalf of their clients.

Third, ICANN has made it clear that the Whois database is the authoritative source for determining the identity of the Respondent and for where to send case documents. If the information in the database is replaced with OPoC information, we ask that the Task Force consider the implications on the UDRP and related Policies and consider that some of the Rules would become moot or impossible to follow."

Those who prefer the 'Special Circumstances' proposal tended to do so because it represents no significant change to Whois for the vast majority of Internet users. Elman Technology Law, P.C. said the situations giving rise to the use of the Special Circumstances process "should be the rare exception rather than a general rule."

While most /supporters of the 'Special Circumstances' proposal said mechanisms for access to unpublished data should be developed, one commenter said this data should only be available subject to the applicable judicial proceedings.

7.3 Summary of support for the proposals

This section draws out the support of commenters for each of the two proposals. It distinguishes between commenters who support the proposals as published in the Preliminary Task Force Report, and those who said the proposals would benefit from further development. Not all commenters supported either or both proposals. For example, OPTA, the Dutch Post and Telecommunications Authority, did not make a recommendation for either proposal.

Commenters who support the 'Special Circumstances' proposal unreservedly:

• Mars Inc.
• Laurie Self (on behalf of various companies and organizations)
• Whois Subcommittee of the International Trademark Association
• American Society of Composers, Authors and Publishers
• Intercontinental Hotels Group
• BITS Financial Services Round Table

Commenters who broadly support the 'Special Circumstances' proposal but with reservations, modifications or suggestions* for further work:

• eBay Inc.
• Special Task Force on Counterfeiting and Piracy Committee of the Intellectual Property Owners Association
• Electronic Arts
• American Heart Association
• Recording Industry Association of America and the International Federation of the Phonographic Industry (joint letter)
• Motion Picture Association
• American Intellectual Property Law Association
• The International Anti-Counterfeiting Coalition

*The specific reservations/modifications differed, but all were from organisations that broadly supported the 'Special Circumstances' proposal and believed it should be explored further; most raised implementation issues which might be resolved with further work, and a small number were concerned that any data at all would be withheld from public access.

Commenters who support the 'OPoC proposal unreservedly:

• Matt Scholl
• Markus Hanauska

Commenters who support the OPoC proposal with some reservations/suggestions for further work:

• Anti-Counterfeiting and Piracy Committee of the Intellectual Property Owners* Association*
• Rod Dixon
• Patrick Vande Walle
• Electronic Privacy Information Center

* The Anti-Counterfeiting and Piracy Committee of the Intellectual Property Owners said that "the use of operational points of contact could be an effective means for providing owners with sufficient contact information to enable them to contact domain name owners without providing information which can be put to use in illicit scams and activities". This organisation supported "a combination of the two proposals", on the condition of timely transmission of notices from OPoCs to registered name holders.

Final summary of public comments

It is possible to summarise some broad directions for development of the two proposals that were raised through the public comments:

• The OPoC should collect contact information for the registered name holder.
• The OPoC should ensure contact with the registered name holder in a defined and short period of time.
• OPoCs should have specified responsibilities for passing communications, including legal notifications, to the registered name holder.
• The cost allocation model, status, credibility and global scale-ability of the mechanism to consider applications in the Special Circumstances need further consideration.
• If either proposal is adopted, there need to be clear, consistent, timely and predictable procedures for obtaining access to unpublished data.

8 Summary of voting on the Task Force Recommendation

8.1 Table 8.1? Summary of voting

This table summarizes the Task Force vote on the Task Force Recommendation, i.e. the OPoC proposal. The vote was carried out be email, beginning on 7 March, 2007, and the final votes were received on 10 March, 2007.

There were two votes per constituency, and one vote for the Nominating Committee member of the Task Force, Avri Doria. As several constituencies used alternate Task Force members, their votes are note counted in the total, but captured in the following form; (X).

The result of the vote was a simple majority of 7:6 in favour of the OPoC Proposal. The OPoC proposal was therefore adopted as the Task Force Recommendation to the GNSO Council.

9 Historical Background to this Report

This section of the report outlines the procedural background of the policy development process on Whois, outlining the key developments since this process began in 2003. The GNSO Council resolutions of direct relevance to this policy development process are reproduced in Annex G of this report, and are also available at http://gnso.icann.org/resolutions.

Pre-dating the creation of the GNSO, the Domain Name Supporting Organisation (DNSO) Names Council initiated a task force to "consult with community with regard to establishing whether a review of ICANN's WHOIS policy is due, and, if so, how best to address" it. (http://www.dnso.org/dnso/notes/20010602.NCstockholm-minutes.html) This task force did research, including a survey carried out during the summer of 2001. It prepared a report ('Draft Final Report of the DNSO Council's WHOIS Task Force on the Survey Regarding WHOIS'; (http://www.dnso.org/dnso/notes/whoisTF/20020625.TFwhois-report.htm) which the DNSO Council presented to the Board at the ICANN meeting in Bucharest, June 2002. (http://icann.org/bucharest/captioning-morning-27jun02.htm#DomainNameSupportingOrganizationReport) The WHOIS Task Force was then ended, as it had completed its Terms of Reference.

The GNSO Council decided on 25 March 2003 (http://www.dnso.org/clubpublic/council/Arc12/msg00247.html) to request that the staff produce an issues report on privacy. Louis Touton produced the 'Staff Manager's Issues Report on Privacy Issues Related to Whois' on 13 May 2003. (http://www.icann.org/gnso/issue-reports/whois-privacy-report-13may03.htm) This report constituted an Issues Report according to Item 2 of the GNSO Policy-Development Process (PDP), adjusted to accommodate the ongoing transition to the New Bylaws' procedures. In the report, staff recommended 'that the GNSO Council not initiate a PDP on any of the Whois/privacy issues until significant additional work is done on investigating the factual background, in analyzing interrelationships of the issues, and in more clearly delineating the issues to be pursued."

The GNSO Council decided on 22 May 2003 (http://www.dnso.org/dnso/notes/20030522.GNSOteleconf-minutes.html) to initiate a workshop on Whois for the Montreal ICANN meeting on 24/25 June 2003 which incorporated the GNSO constituencies as well as the Government Advisory Committee and other groups.( http://www.icann.org/montreal/whois-topic.htm#Tuesday24June2003)

Also on 22 May 2003, the GNSO Council decided to create a Whois Steering Group to:

"- to take the Issues Report
- to take the outcome of the Montreal ICANN workshop
- to develop a set up terms of reference for one or more task forces on the critical issues
- to make recommendations to the GNSO Council."

The steering group met representatives from the GNSO, Governmental Advisory Committee (GAC), Addressing supporting organization (ASO) and the Internet Engineering Task Force (IETF) to identify the priority areas. (http://gnso.icann.org/meetings/minutes-gnso-25sep03.shtml)

On 29 October, 2003 during the ICANN meeting in Carthage,

(http://gnso.icann.org/meetings/minutes-gnso-29oct03.shtml) the GNSO Council voted to agree terms of reference for the policy work on Whois in the following areas:

(1)   Restricting access to WHOIS data for marketing purposes
(2) Review of data collected and displayed
(3) Improving accuracy of collected data

Terms of Reference:

area 1 http://gnso.icann.org/issues/whois-privacy/tor.shtml
area 2 http://gnso.icann.org/issues/whois-privacy/tor2.shtml
area 3 http://gnso.icann.org/issues/whois-privacy/tor3.shtml

The GNSO Council formed three task forces to work respectively on these issue areas, to communicate with each other and "to come back to the council with a timetable for achieving their work and that it will be in the context of the ICANN bylaws process." On 19 February, 2004, the GNSO Council approved timelines for the each of the three Whois task forces' policy development process work. (http://gnso.icann.org/meetings/minutes-gnso-19feb04.shtml)

On 20 July 2004, the GNSO Council decided to combine Whois Task Forces 1 and 2 to look at tiered access and develop further up-front advice to registrants about their obligations. (http://gnso.icann.org/meetings/minutes2-gnso-20jul04.htm) The Council asked Whois Task Force 3 to clearly identify its recommendations for new policy and work on determine the implementation issues for work done by ICANN and work done by registrars. Finally, it directed that the work of the task forces be combined before going out to public comment.

At the GNSO Council meeting during the ICANN meeting in Capetown, December 2004, it was reported that the Whois Task Force 1 & 2 had developed consensus around two positions:
1. Recommendations relating to improving notification and consent for the use of contact data in the Whois system.
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.
(http://gnso.icann.org/meetings/minutes-gnso-03dec04.htm)

The Council directed the development of an initial report based on these recommendations which would include constituency impact statements and financial impacts before putting out the recommendations for the first public comment period. A preliminary report on the first of these recommendations was posted on 22 April 2005 (http://gnso.icann.org/issues/whois/whois-tf123-final-rpt-22apr05.shtml#Footn). The Final Task Force Report on Recommendations for improving notification and consent for the use of contact data in the Whois system was forwarded to the GNSO Council on 26 May, 2005 (http://gnso.icann.org/mailing-lists/archives/council/doczrURNmmTyl.doc). The Final 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 was sent to the GNSO Council on 25 October 2005. (http://gnso.icann.org/issues/tf-final-rpt-25oct05.htm)

On 2^nd June 2005, the GNSO Council agreed the terms of reference for the combined Whois Task Force. Five issue areas for policy development were specified in the terms of reference (see Annex C of this document). (The resolution on the terms of reference is here; http://gnso.icann.org/policies/terms-of-reference.html, the meeting minutes are here; http://gnso.icann.org/meetings/minutes-gnso-02jun05.shtml)

The task force completed its work on item 4 of the terms of reference, a procedure on conflicts between ICANN contractual requirements and national or local privacy laws in November 2004. Its report was the subject of a GNSO policy recommendation on 18 January 2006

(http://gnso.icann.org/issues/whois-privacy/council-rpt-18jan06.htm) and was adopted by the ICANN Board on 10 May 2006.

(http://www.icann.org/minutes/minutes-10may06.htm)

The Whois Task Force concluded its work on term of reference item 2, the purpose of Whois, in the Final Task Force Report on Purpose of Whois and the Whois Contacts on 16 March 2006. (http://gnso.icann.org/issues/whois-privacy/prelim-tf-rpt-18jan06.htm) The report was submitted to the GNSO Council on 18 March 2006. On 12 April, 2006, the GNSO Council recommended "that the WHOIS task force use the following definition:

"The purpose of the gTLD Whois service is to provide information sufficient to contact a responsible party for a particular gTLD domain name who can resolve, or reliably pass on data to a party who can resolve, issues related to the configuration of the records associated with the domain name within a DNS name server."

as a working definition to allow the task force to proceed on terms of reference (2), (3), and (4) (see: http://gnso.icann.org/policies/terms-of-reference.html)". (See Annex G. for the full resolution.)

10 Staff comparison of policy recommendation and minority proposal

This section is a comparison of how the policy recommendation and the minority proposal address the terms of reference of this task force set by the GNSO Council on 2^nd June, 2005. (See Appendix A for the full terms of reference.) This report deals with terms of reference 2, 3 and 4.

10.1 Term of Reference 2: Purpose of the contacts

Define the purpose of the Registered Name Holder, technical, and administrative contacts, in the context of the purpose of WHOIS, and the purpose for which the data was collected.

Use the relevant definitions from Exhibit C of the Transfers Task force report as a starting point:
(from http://www.icann.org/gnso/transfers-tf/report-exhc-12feb03.htm ):

"Contact: Contacts are individuals or entities associated with domain name records.

Typically, third parties with specific inquiries or concerns will use contact records to determine who should act upon specific issues related to a domain name record. There are typically three of these contact types associated with a domain name record, the Administrative contact, the Billing contact and the Technical contact. Contact, Administrative: 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.

Contact, Billing: The billing contact is the individual, role or organization designated to receive the invoice for domain name registration and re-registration fees.

Contact, Technical: The technical contact is the individual, role or organization that is responsible for the technical operations of the delegated zone. This contact likely maintains the domain name server(s) for the domain. The technical contact should be able to answer technical questions about the domain name, the delegated zone and work with technically oriented people in other zones to solve technical problems that affect the domain name and/or zone.

Domain Holder: The individual or organization that registers a specific domain name. This individual or organization holds the right to use that specific domain name for a specified period of time, provided certain conditions are met and the registration fees are paid. This person or organization is the "legal entity" bound by the terms of the relevant service agreement with the Registry operator for the TLD in question."

Summary of task force discussion

The task force generally agreed that many registrants do not understand the meaning or purpose of the different contacts; administrative, technical and billing. The original rationale for the distinction between some contacts is no longer clear. The task force generally agreed that awareness of registrants about the contacts should be improved, especially if a different type of contact ? the OPoC ? was introduced. Task force members differed somewhat on how awareness should be improved, whether notices to customers should be standardised, and whose responsibility it is to improve awareness.

There was considerable discussion regarding the OPoC proposal and the purpose of the contacts. The task force discussed whether the OPoC proposal meets an acceptable definition of the purpose of the contacts. Task force members who did not affirm that it did so said it depends on the function the OPoC fulfils, i.e. if the OPoC provides all the necessary functions in 'a timely manner'. (There was considerable discussion and little agreement on what constitutes 'timely'.)

The task force also discussed in detail whether the OPoC should be obliged to pass on important communications such as 'cease and desist' letters to the registered name holder, and, if so, how quickly. The Registrar Constituency did not agree that the OPoC be required to pass on letters, comparing the OPoC to the generic mailing address used by some corporations. Use of these addresses does not guarantee that communications will ultimately be delivered to the responsible individual. The Registrar Constituency said the onus was on the Registered Name Holder to ensure he/she receives important notices, comparing this obligation to individuals' responsibilities to receive and act on tax notices. The IPC and the BC were concerned that the OPoC would be slower, less efficient and less reliable at passing on important notices than addressing them directly to the registrant, and that a clear "job description" of the oPoC had not been developed.

The task force broadly agreed that improving contactability of the contacts was a worthwhile goal. Proponents of the OPoC proposal said the OPoC would increase contactability. The IPC said it would judge the OPoC proposal on whether it improved contactability. The OPoC proposal was modified to allow registrants to designate two OPoCs, to improve contactability.

The task force had agreed that the name of the Registered Name Holder should continue to be published in the Whois, along with their country and state/province. This would indicate the jurisdiction of the registered name holder, and be helpful to third parties considering or pursuing enforcement actions. Following the introduction of the Special Circumstances Proposal in September 2006, the Nominating Committee Councilor Avri Doria withdrew her support for this point. Avri Doria said she had agreed to the publication of this data "as a compromise with the IPC and others, e.g. BC, interests", and that "full access to the OPoC is sufficient to meet the intended purpose for Whois data". (email from Avri Doria to the Task Force, 27 October, 2006) The majority of task force members still appear to agree that if the OPoC proposal was adopted, the name and jurisdiction of the registered name holder should be published in the Whois.

Broadly, the Registrar, Registry and Non Commercial Users constituencies, Nominating Committee member and ALAC liaison agreed with removing the postal address fields from the published Whois. The Intellectual Property, Business and ISP constituencies disagreed with removing this data from publication.

During the course of discussion, the Nominating Committee member and ALAC liaison also said the registered name holder's name should be removed from the published Whois.

10.2 Term of Reference 3: Public Access to Data

Determine what data collected should be available for public access in the context of the purpose of WHOIS. Determine how to access data that is not available for public access. The current elements that must be displayed by a registrar are:

- The name of the Registered Name;

- The names of the primary nameserver and secondary nameserver(s) for the Registered Name;

- The identity of Registrar (which may be provided through Registrar's website);

- The original creation date of the registration;

- The expiration date of the registration;

- The name and postal address of the Registered Name Holder;

- The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the Registered Name; and

- The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the Registered Name."

Summary of task force discussion (including proposal for access to data)

Several proposals have been presented to the task force for access to data that is removed from display in Whois as a result of other policy recommendations.

(1) Representatives of the registrar constituency proposed that such data could be made available by contacting the registrar of record for the domain name, without any new rules or policies, but be made subject to best practices. Today, registrars handle many requests for other information not published in the Whois, and they expect to handle requests to data removed from the Whois in a similar manner. 

Ross Rader of the Registrar Constituency prepared the following information to inform the task force's deliberations:

(2) UDRP mechanism: The special circumstances proposal calls for procedures in this area to be "coordinated to the extent feasible with existing procedures such as the UDRP," to which only minor adaptations would be needed. When the "legitimate complaint of abuse" that gives rise to the need to access actual registrant data is a claim of bad faith registration and use of the domain name, the customary notification by the dispute resolution provider to the registrar of the filing of a UDRP complaint could also include a directive for the registrar to provide to the complainant the contact information that it holds on a registrant in the special circumstance program. Under the UDRP, the registrar is contacted only after review of the complaint for administrative compliance, which is a safeguard against abuse.  Of course, where the legitimate complaint of abuse concerns behavior not covered by the UDRP, a separate procedure may be needed.

(3) The task force chair proposed a mechanism that would allow Whois users to request access to the removed data elements if the reason the information was removed was no longer valid, or if the domain was being used illegally or to harm the security or stability of other Internet resources.  A third party would evaluate the request, and allow the release of the data if the party making the request proved that one of these conditions had been met.

(4) Representatives of the IP constituency suggested that one element of another of the task force chair's proposals be considered in this area.  That proposal would allow the data to be accessed by anyone entering into a contract agreeing to (as yet undefined) limitations on the use of the data.  Under this proposal, a third party would handle the contracting process and would also supply a set of credentials that could be used to access the data.  A number of specific technical mechanisms for accessing the data were also presented.

(5) In lieu of having data corrected or revealed, registrant shall have the option of allowing the domain name to lapse. Where the registrant requests the "lapse" option, the domain name shall be stopped from resolving and registrant's identifying information shall not be turned over to the requesting party. Registrant may request suspension pending resolution of the dispute in a "John Doe" (anonymous) proceeding, or cancellation (where registrant does not respond or challenge the request). In either case, registrant's information shall not be turned over [unless that is specifically ordered in a judicial proceeding].

Finally, the task force initially discussed which data collected should be published in the context of the Registry Constituency proposal regarding the practices of the .name registry introduced on 7 February 2006. This proposal was not made in the form of a written document but was a presentation to the task force by GNR, the .name registry. The .name proposal was discussed by the TaskForce on 14 February 2006. The .name practices are the result of extensive consultations with the UK data protection authority and with industry, and are said to be compatible with the UK data protection law. (The UK data protection authority does not give affirmative declarations that an organisation's activities are compliant with legislation.) The .name registry is a 'thick' registry and is aimed at individual registrations only. It does not publish all Whois data, but makes it available following the registration of the requester, and signature by the requester of an agreement regarding use of the data, or execution of a click-through license and a small payment. Task force members raised questions about the scalability of the model. There was no further discussion or development of this proposal.

10.3 Term of Reference 4: Inaccurate Data

Determine how to improve the process for notifying a registrar of inaccurate WHOIS data, and the process for investigating and correcting inaccurate data. Currently, a registrar "shall, upon notification by any person of an inaccuracy in the contact information associated with a Registered Name sponsored by Registrar, take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with a Registered Name it sponsors, it shall take reasonable steps to correct that inaccuracy."

Summary of task force discussion

The task force broadly agreed that the OPoC proposal included an improved process for responding to complaints about inaccurate Whois data.[6] The OPoC process is summarised below:

The task force agreed broadly on the steps of this process. However, there was not agreement on what 'a timely manner' is, in number of days, and whether it might be interpreted differently when applied to the OPoC or the registered name holder.

11 Constituency Statements

11.1 Requirements for constituency statements

Constituency statements were solicited in parallel with the public comments period held from November 2006 to January 15^th, 2007.

According to the ICANN bylaws (Annex A, paragraph 7.d.1; http://www.icann.org/general/bylaws.htm#AnnexA), each Task Force Report must include:

"1. A clear statement of any Supermajority Vote position of the task force on the issue;

2. If a Supermajority Vote was not reached, a clear statement of all positions espoused by task force members submitted within the twenty-day timeline for submission of constituency reports. Each statement should clearly indicate (i) the reasons underlying the position and (ii) the constituency(ies) that held the position;

3. An analysis of how the issue would affect each constituency of the task force, including any financial impact on the constituency;

4. An analysis of the period of time that would likely be necessary to implement the policy; and

5. The advice of any outside advisors appointed to the task force by the Council, accompanied by a detailed statement of the advisors' (i) qualifications and relevant experience; and (ii) potential conflicts of interest. "

11.2 Statement of the Commercial and Business Users Constituency

I. Improvements to the Final Report of the Task Force

Recommendations to Improve the TF Final Report:

A. A brief summary of the various processes and events undertaken by the TF, including participation in workshops, outreach via conference calls to external parties, etc. should be added to the Background section, under a suitable heading describing the work processes of the TF.

B. Full wording of the GNSO Council resolutions should be added as appendices and links to the resolutions be inserted into the Background section of the Final Task Force Report. This will provide a fuller record when the Final report is considered by the GNSO Council, and eventually, the ICANN Board. The relevant resolutions are 20060720-02 and 20060720-03 and can be found at www.gnso.icann.org/resolutions.

II. BC Comments specific to the Preliminary Task Force Report

The BC comments in general support Special Circumstances Proposal over OPOC, provide input and recommendations to improve the two proposals under consideration by the TF; propose additional steps, in lieu of either proposal, that will improve the WHOIS service, curtailing harvesting of emails and telephone numbers from publicly displayed WHOIS data, and limiting any marketing uses of WHOIS data. The BC also recommends a study by an independent third party of the characteristics of gTLD registrants in non sponsored gTLDs, as well as the uses and perceived misuses of WHOIS data.

A. Comments of the BC related to the OPOC Proposal

The BC highlights the following concerns and questions related to the OPOC proposal:

As presently drafted, the OPOC Proposal does not provide a clear definition of the roles and responsibilities of an OPOC. The only statement in the proposal related to the obligations of the OPOC is: "The purpose of the operational point of contact is to resolve, or to reliably pass on data to resolve, operational issues relating to a domain name. At a minimum, this must include the resolution of issues relating to the configuration of the records associated with the domain name within the DNS server."[7] Any other obligations are optional between the OPOC and the registered name holder.

Recommendation: An agreed set of responsibilities should be included, and published as part of the registrant agreement, which should be reviewed and accepted as part of the registration process.

The OPOC eliminates the postal address of the registered name holder, but does not provide certainty of how such registered name holder will be contacted by the OPOC, in the event of problems, legal issues, etc.

The BC opposes the elimination of the postal address of the registered name holder. Registered name holders are ultimately the parties responsible for registering a name, and any misuse, or use related to the name registration.

If there is a change that creates a new designation such as 'OPOC', there should be a range of options to the registered name holder in how that function is fulfilled including self provision of these functions.

The tasks and purposes of the OPOC must therefore be defined, and at a minimum must include:

Agreement to provide accurate and complete contact details for a 24/7 contactability, and to maintain published and accurate data

Agreement to accept all kinds of contacts, ranging from technical, administrative, IP conflict, legal notices, contact from law enforcement, on behalf of the registered name holder

The ability to address and resolve technical or operational issues or problems.

Responsibility for forwarding, within an appropriate timeframe*, correspondence and requests to contact the registrant and/or the technical resource for the registrant.

*The TF has discussed but not resolved what an appropriate time frame may be. Some issues that are encountered are urgent, such as network attacks, phishing, pharming incidents, etc.

Recommendation: The BC recommends that the 'defined purpose and functional tasks to be performed by the OPOC' should be established by consensus policy. This should include a requirement that Registrars ensure that registrants read and accept or delegate to an identified third party or to the registrar, if acting as the OPOC, the responsibilities of the OPOC, at the time of registration/renewal.

As presently drafted, the OPOC proposal does not provide a standardized mechanism for access to non-public contact data for legitimate stakeholders, upon the implementation of an OPOC by a registered name holder.

The proponents of the OPOC proposal acknowledged this deficiency during the Public Forum at the ICANN meeting in Sao Paulo.

Recommendation: Any proposal to modify the existing WHOIS policy related to data displayed and access to data must include a process for access to non displayed data before changes in the existing practices are introduced.

The BC welcomes hearing from proponents of OPOC regarding recommendations for how to address access to non displayed data.

One approach that could merit study is the recognition that there are hundreds of accredited registrars, and that any approach needs to take into account the burden on legitimate users of WHOIS. It may be appropriate to examine the creation of a "white list" for legitimate stakeholders who need access to deal with "legitimate" purposes, such as network attacks; phishing; pharming attacks; trademark collisions, etc. This 'white list' should be developed and maintained by ICANN, based on criteria that are broadly agreed upon, and published for public comment. The cost to become 'accredited' should be borne by the applicant. ICANN should publish the 'white list' on the ICANN web site. Accredited ICANN Registrars /registries should be required to recognize the status of those on the 'white list'. A form of unique standard identification and sanctions by ICANN will be needed to prevent abuse of this status.

At present, the OPOC proposal does not address accuracy improvement. If OPOC were to be adopted and thus even less data were to be made publicly available the accuracy of the OPOC's contact data becomes even more important.

Recommendation: The OPOC proposal should be elaborated to include a pre validation of the completeness and accuracy of contact details of the OPOC at the time of registration. The RAA should also provide for periodic checking of the OPOC details and a standardized notice to the registrant, to remind them to verify the accuracy of their OPOC details, and of consequences of providing inaccurate, or failing to correct such data, such as suspension/loss of registered name.

The issue of a 'system-wide' change of this nature, encompassing tens of millions of records for registered names needs to be examined for its implications. In addition, if such a change in envisioned, the TF should schedule a further discussion with relevant parties related to the role and implications of IRIS/CRISP and whether there is a consideration of a longer term evolution to a new protocol for WHOIS. A detailed discussion with ICANN Operational staff is needed to examine implementation issues.

Conclusion: The BC does not support the OPOC Proposal as presently drafted, and remain doubtful that these issues will be satisfactorily resolved.

B. THE SPECIAL CIRCUMSTANCES PROPOSAL (SCP)

Although the Special Circumstances Proposal has areas of improvement needed, and the BC suggests that other mechanisms, such as are described in IV, are in need of further examination by the TF, in general the BC supports the Special Circumstances objectives.

The Special Circumstances Proposal (SCP) addresses a specific need that has been identified by a number of ICANN stakeholders, and that the BC recognizes: that there are a limited number of registrants who are indeed acting purely as individuals in their use of a domain name, or who have a legitimate need for a private registration due to the nature of the services that they provide, such as a service for abused spouses or children.

The SCP assumes that for the most part, those who register domain names are holding themselves out to communicate with the public, and that, given proper notice and choice of whether they use a domain name registered from an ICANN accredited registrar and build and maintain a unique web site, versus utilizing a web hosting service that can provide similar functions, hosting of information, etc. the registrant can make an informed choice of how to proceed.

In the registration and use of domain names, the BC believes that the public at large has a right to know with whom they are interacting and communicating.

The BC recognizes that there are instances where a registrant has a legitimate need for a private registration. While the BC believes that such registrations are limited, and should be validated, the BC can support the development of a model similar to that of the 'unlisted numbers' used in certain national telecommunications jurisdictions, including the US and certain countries in Europe.

Therefore BC supports the concept of establishing a process whereby an individual, or appropriate non commercial service entity can apply for an opt-out for the inclusion of their contact data in a publicly accessible WHOIS if their safety and security cannot be protected otherwise, as provided by the Special Circumstances Proposal.

The BC can support the Special Circumstances Proposal in principle, but has identified some improvements and questions yet to be addressed.

B. 5. Improvements and enhancements that the BC would like to see elaborated on for the SCP are:

Purpose of the registered Name Holder: The BC notes that the present SCP does not provide a definition.

Purpose of the Technical Contact and Administrative Contact.

Recommendation: The BC supports the definitions from Exhibit C of the Transfers Task Force and suggests that they be incorporated in the SCP.

Access to Data: Since the majority of registered names will have all data displayed, there is less demand for new procedures for access to non displayed data. The BC proposes other changes in how data is displayed, in Section IV.

However in the SCP area, for the registration contact data not displayed due to approval for SCP the BC suggests that there needs to be an improved procedure for access to data not displayed. The BC would like to see this area elaborated.

The SCP does not provide discussion of steps needed to improve accuracy of registrant, technical, and administrative contact data in registration and renewal of domain names.

Recommendation: The SCP should be elaborated to include a pre validation of all contact details at the time of registration for any party determined to be eligible for SC. The third party who holds the data should be required to provide accurate data for themselves and to attest that they have verified and maintain accurate contact data for the registrant. The RAA should also provide for periodic checking of the SC registrant data and procedures to require updates, or corrections.

The BC agrees that the proposal needs to be examined for scalability to the gTLD non sponsored space. In general, the BC supports the concepts provided in the SCP to rely upon outsourcing of the special circumstances application process to independent third-party vendor(s), possibly on a regionalized basis, ensuring adequate funding and outlining a simple and clear process for the application, designation and appeal of "special circumstances" request(s). This will require support from the ICANN operational staff, and should be explored, keeping in mind the lessons learned from the .nl service.

III. Additional Recommendations on other steps the Task Force should consider:

Neither the special circumstances proposal nor the OPOC proposals address concerns related to the mining of WHOIS data for marketing purposes, a use that the BC has consistently opposed. The BC therefore endorses steps that can assist in limiting misuses or abuses of publicly accessible WHOIS data.

The steps recommended by the BC are supplemental to, but consistent with the concerns and issues now being addressed by the TF; for instance, the recommendation to rely only on web based display of WHOIS data, with adequate IVC addresses the TOR's question about access to data; since the majority of registrant data would still be displayed, but with limits on any other uses of the data, e.g. for marketing.

Recommendation A. Study related to Facts about gTLD Registrants; Uses of Domain Names, Misuses of WHOIS Data; Uses and Users of WHOIS Data

It is time for a comprehensive study which should address the characteristics of registrants and of users of WHOIS data in the non sponsored gTLD registry space. This study should be undertaken by a neutral third party, retained and funded by ICANN, and study such issues as the characteristics of registrants; whether a domain name is actually in use [live DNS], uses and misuses/abuses of WHOIS data. Comments related to the development of the elements and scope of the study should be sought from the GNSO's Constituencies, the Advisory Committees, including At Large and GAC, and the SSAC.

The BC calls for a study of non sponsored gTLDs and WHOIS, to encompass at least the following issues and questions:

Characteristics of registrants in the non sponsored/open gTLDS,

e.g.: numbers of registrants who: 1) use the domain name for personal use; 2)for 'speculation/holding/resale; 3)for traffic aggregation; 4)for non commerce; and 5)for commerce online and 6) governmental or related purpose 7) other [to be identified]

Identify the percentage/number of sites that are registered, but do not have 'live DNS' versus those that are actually in use

Uses, misuses and abuses of WHOIS data, as publicly displayed

Identify the percentage of inaccurate data, and undertake a sample examination of why data is inaccurate ? e.g. a) aged data; b) typo/registrant error c) purposeful provision of inaccurate data d) other [to be identified]

Recommendation B. Steps to eliminate 'data mining'

Over the history of GNSO work on WHOIS, concerns have been raised about 'data mining' of publicly available WHOIS data; and misuses of port 43 and bulk access to WHOIS data. Steps have been taken in the past to attempt to curtail marketing uses of bulk access data. However, the BC recommends further changes that can curtail, if not eliminate data mining and harvesting of email and telephone numbers and limit any misuses of bulk access data. In addition, the BC proposes strict limits to how bulk access and Port 43 access to WHOIS data is granted, and the creation of a 'white list' of authorized uses, and users.

All WHOIS access should be changed in all WHOIS publicly available services to web based access. Such web based services should include an Image Verification Check (IVC) of sufficient security strength so that the random letters generated are not easily machine readable.

All bulk access should be moved to ICANN developed contractual terms for access, with an accreditation process for parties allowed to have such contracts. ICANN should develop standard terms and conditions and enforcement them when they are violated. These standard terms and conditions should be applied to all gTLDs; and a standardized range of cost recovery fees can be established. In general, parties who need bulk access for legitimate purposes are trademark and other firms that provide trademark defense or portfolio management services, or services utilized by law enforcement authorities.

This approach does need further exploration with law enforcement and consumer protection authorities to ensure how best to address their need for port 43 access or bulk access.

Summary:

In summary, the BC does not believe that the recommendations presented by the WHOIS Task Force are yet complete, nor do they represent full consideration of the full range of issues and implications with system wide changes, nor do they address balanced consideration of the full range of public policy implications.

The Task Force has not yet given sufficient consideration to options for addressing changes in the display of data, nor in how to deal with the non display of data, if changes are made in the public display of data elements.

In the OPOC, the issues of a system wide change that will implicated tens of millions of registrations has to be considered, and examined for how it might cause registrant confusion or even add extreme burdens of customer complaints during an implementation. Discussions of phased implementation, with changes occurring at the time of renewal have to be undertaken, while recognition of multiple year registrations and the need for co-existence of dual systems has not been a topic of discussion.

In the SCP, there is a need for further examination of how to implement the recommendation, including the development of criteria for the 'special circumstances' status. However, in this instance, some historical success of country codes who have undertaken similar approaches can be studied and drawn upon.

The BC again notes that in general, they can support the Special circumstances over the OPOC proposal.

The BC's additional recommendations should be explored and implemented as first steps to limit some of the areas of concern that are often expressed by parties who object to public display of data because of abuse of bulk access, or data mining.

IV. Process followed:

According to the ICANN bylaws (Annex A, paragraph 7.d.1) the Task Force Reports must include constituency statements. The BC has provided earlier Constituency Statements related to the "Purpose of WHOIS and of the WHOIS Contacts". The earlier constituency statement was requested before the level of detailed recommendations presented in this Preliminary Report. The BC's comments are provided in detail in the previous sections.

Relevant section from ICANN bylaws: Annex A, Paragraph 7.d.

1. Constituency Statements:

(i) if a Supermajority Vote was reached, a clear statement of the constituency's position on the issue - the constituency's position is detailed in the submission.

(ii) if a Supermajority Vote was not reached, a clear statement of all positions espoused by constituency members: Non applicable.

(iii) a clear statement of how the constituency arrived at its position(s)

The BC has three representatives to the WHOIS Task Force: Marilyn Cade, David Fares, and Sarah Deutsch. Throughout the work of the Task Force, the representatives have maintained interaction with the membership, including postings and briefings by BC TF members on the work of the WHOIS Task Force. BC members are generally quite concerned and interested in WHOIS, and are actively engaged in this topic, when it is raised within the BC, or is the subject of ICANN public forums/workshops.

As an example, members were briefed on both of the proposals; and discussions took place in the face to face ICANN meetings, as well as on the BC list.

The BC Rapporteur and fellow Task Force members forwarded the draft Constituency comments to the BC list on December 28. BC members had 14 days to provide comments and edits to the Comments, and were specifically asked to show their support to the report, and to identify any areas of disagreement. The BC TF members edited the Comments, and prepared this final submission, taking into account all responses received, and discussions that have taken place on the BC list and face to face meetings and workshops.

(iv) Analysis of how the issue would affect the constituency; including any financial impact on the constituency

The BC's interests are harmed by the lack of accurate WHOIS data and will be harmed by lack of access to WHOIS data, if public access to WHOIS data is changed, and if there is no suitable substitutes to ensure that legitimate users have timely access to accurate WHOIS contact data, so that they can deal with network attacks, trademark infringements; phishing and pharming attacks, as well as undertake normal use of the WHOIS database related to checking for availability of registerable names for use in setting up new web sites.

The BC expects the impact of the OPOC proposal and the Special Circumstances Proposal to have significant financial and resource impact on registrants, including business users during the time to incorporate a system wide change. As users of WHOIS data to address problems, the BC anticipates significant resource demands as new procedures are developed, disseminated, and incorporated widely.

The OPOC proposal is anticipated to have an ongoing negative financial impact to users of WHOIS data, who rely on access to WHOIS data to quickly identify and contact the party responsible for cyber squatting, phishing, pharming, network attacks, and trademark infringements.

A move to web based access coupled with improved contractual terms for bulk access will represent the least invasive change to users, but will curtail data mining in displayed data. Thus, this change, as recommended by the Business Constituency, provides improvements to WHOIS but without the associated harms to the interests of the Business Constituency's members.

(v) An analysis of the period of time that would likely be necessary to implement the policy(ies):

The time frames to implement any of these changes is significant. If improved and adopted, the OPOC proposal would take extensive time to finalize and implement, since it is dependent upon changes in operation that affect all registrants of domain names. An implementation team should include broad representation from ISP/Connectivity providers, business users and At Large, since it is registrants who will have to first understand and undertake the changes needed to identify an OPOC, and then incorporate this change in their registration process. In the past, implementation teams have been dominated by registrars and/or registries. In this situation, it is imperative that full attention be given to the challenges that registrants will face as they are asked to incorporate possible changes in their operation in order to identify an 'OPOC'; establish such a role internally, or reform how they manage their domain name portfolio to take into account 'outsourcing' of these functions now managed internally.

While the impact on small companies who typically rely upon their ISP or registrar already for such services may be minimal, larger more distributed corporations may take more time to assimilate a change in functional assignment of responsibilities typically managed internally.

Implementing changes involving several tens of millions of registrations as required if OPOC moves forward, is a major change and one not yet achieved in the history of an ICANN with the number of registered domain names under management in the non sponsored gTLDs.

The BC notes that the TF has not discussed the scope and scale of such changes, nor the details related to educating and creating awareness among registrants, although the topic has been raised in the TF. Therefore, until such discussion takes place, the BC cannot estimate the length of time, but does call for an examination of how the registrant population will be educated about changes, both in OPOC, and in SCP.

The SCP is more limited in the number of registrations affected, since it is limited to those registrations determined to have a need for privacy. The time challenges for SCP will be related to the creation of a process to determine who should be eligible; and identifying and retaining an entity(ies) that can accept applications. The BC acknowledges that the SCP process can be modeled upon the .nl model, but the issues of scalability need to be addressed.

ICANN staff resources are implicated for both proposals, and a discussion of the feasibility and implementation details are needed for both proposals. These should be scheduled and completed during the public comment period so that the TF can take this consideration into account as part of the preparation of the Final Report.

The BC's recommendations related to a study and to other changes also deserve further consideration in terms of time to implement. Just like the OPOC and Special Circumstances Proposal, the change to web based access would require work by an implementation team that should include representatives from all constituencies and the operational staff. And, similarly to the other two proposals, an outreach and awareness 'campaign' by ICANN that announces substantive changes to WHOIS access would be needed.

Once ICANN agrees to fund a study, the terms of reference for a study can be defined, and posted for public comment. It is conceivable that with commitment to undertaking the study, and with assigned staff working with the relevant expert parties to solicit input and feedback, a well documented and statistically valid survey instrument; coupled with a series of data interviews of representative users, registrants, registrars, etc., can be developed within a matter of a few weeks. The study will probably require both public data gathering, and solicitation of subjective data, describing misuses or abuses of WHOIS data, and also misuses and abuses of domain names, where WHOIS data has been used to address and provide investigatory resources to curtail or end abuses.

The design, preparation, and conducting of such a study should become a priority in order to guide and inform policy making. Once agreed, the study could even proceed in stages, with interviews and statistically oriented questionnaires proceeding simultaneously. The study could be developed and implemented in parallel to the rest of the work on WHOIS needed at the GNSO Council, in its further outreach and consultation with the advisory committees.

Submitted on behalf of the Business Constituency WHOIS Task Force members:

Marilyn Cade

Sarah Deutsch

David Fares

15 Jan 2007

13.3 Statement of the Intellectual Property Constituency (IPC)

The Intellectual Property Constituency (IPC) submits the following statement for inclusion in the Whois Task Force Preliminary Report, dated 22 November 2006.

I. Re: OPOC Proposal (Annex A)

Annex A of the Report lists the "four main areas of consideration dealt with" by the OPOC proposal, which we address seriatim below.

1. The IPC does not support point 1 of the OPOC proposal (regarding the type of contact data to be published by registrars via Whois). Adoption of this proposal would have a serious negative impact on members of the constituency.

The many legitimate uses that constituency members make of Whois data are well documented in previous submissions. For most of these uses, especially those regarding protecting the intellectual property rights of companies, non-profit institutions, trade associations, and individuals, ready access to the full range of Whois data is critical. This access enables intellectual property owners to quickly contact the party responsible for the registration or use of a domain name that involves infringement of trademark or copyright, cybersquatting, or other illegal behavior. In most cases, this quick contact leads to a prompt resolution of the problem, without the need to invoke the UDRP or more formal legal processes. In those cases which do proceed to a UDRP complaint, civil litigation, or a criminal investigation, the data currently available in Whois is often essential to effective enforcement.

Basically the same holds true when constituency members access Whois for other legitimate purposes such as combating or preventing online frauds, conducting due diligence in mergers and acquisitions, and the like: quick access to contact data on registrants and their administrative and technical agents facilitates quick resolution of problems in the great majority of cases, which is in the best economic and legal interest of all parties concerned. When a quick resolution is not possible, Whois data plays an important role in the service of legal process, further investigations, and other follow-on activities.

Under the OPOC proposal, most of the data in Whois that enables these quick contacts and that supports these follow-on activities would no longer be available to IPC members (or any other member of the public). Only the registrant's name and country/state or province would be published. Instead, the intellectual property right holder would have to work through whomever the registrant had designated as his/her/its "operational point of contact." This entity's "purpose" would be "to resolve, or to reliably pass on data to resolve, operational issues relating to a domain name." But the proposal raises far more questions than it answers about how an intellectual property right holder would achieve the quick contact with the registrant which the current system of public access facilitates. These questions include (but are not limited to):

(a) On what issues is the OPOC expected to act? "Operational issues relating to a domain name" is only minimally defined, and may not include some or all of the issues summarized above, which are the reasons why members of the IPC to seek to contact the registrant. In such cases, contacting the OPOC may be a fruitless gesture.

(b) What is the OPOC supposed to do? Its "purpose" includes "pass[ing] on data." Is this purpose fulfilled if the OPOC simply notifies the registrant of a query and does nothing more? If so, contacting the OPOC would not only be fruitless but often counter-productive, since it could alert an infringer or other wrongdoer of the existence of an investigation and prompt him to take evasive action.

(c) How quickly must the OPOC act? Even if a matter falls within the range of issues for which the OPOC has responsibility, and even if the OPOC responds by providing the requester with the contact data of the registrant (assuming that the OPOC is even authorized to do this), this process will inevitably be far slower and less efficient than the status quo, in which contact data is available via Whois almost instantaneously. If the OPOC does not put the requester into direct contact with the registrant, but instead remains in the role of a go-between through whom all communication must be channeled, delay is virtually guaranteed. Accordingly, many of the efficiencies achieved by quick contact with the registrant and prompt resolution of the matter will be lost.

(d) What if the OPOC fails to act or to act promptly? The OPOC may do absolutely nothing (indeed, there is nothing to prevent a registrant from designating an OPOC who does not even know the registrant or how to contact him/her/it). The proposal provides the requester with no recourse in this case. The OPOC would owe no contractual duty to ICANN, either, so ICANN would appear powerless as well to do anything about an OPOC that fails to act. The likely result would be more requests to the registrar/registry (whether through litigation or other channels) for actionable contact information to be divulged, thus increasing costs both for requesters and for registrars/registries.

In sum, interposing an "operational point of contact" between the Whois requester and the registrant will generally make the process of contacting the registrant slower, more difficult, and less reliable than it is today. The benefits for all parties of quick contact and prompt resolution will be largely forfeited; more cases will have to be resolved through more formal channels such as UDRP or litigation; and expense and delay will increase for all concerned. Certainly there may be some cases in which the OPOC will have the desire and capability to facilitate a resolution, but IPC is concerned that these instances will be far outweighed by the number of cases in which the opposite will occur.

2. IPC does not take a position at this time on point 2 of the OPOC proposal (the type of contact data published by registries via Whois). From our perspective, in the thick registry environment it is advantageous to have two sources ? registrars and registries ? for Whois data, because at any given time one of these sources may be unavailable. Furthermore, not all registrars live up to their obligations to make Whois data publicly available. However, we understand that there are countervailing concerns arising from discrepancies between data about the same domain name in the registry and registrar Whois services. IPC believes that more information is needed before it can take a position on this issue.

3. IPC supports in principle the third aspect of the OPOC proposal, which concerns correcting inaccurate Whois data. This proposal would clarify what registrars are supposed to do when they receive notice of inaccurate data, a point of some confusion today, and spells out that they must take reasonable steps to validate corrected information that is provided to them in response. This would certainly be an improvement over the current Whois Data Problem Reporting System, which is ineffective. Thus the effect on constituency members would be beneficial, but only to a very modest degree. This proposal would be of very limited value if the entire OPOC proposal were adopted; since only the name and country/province/state of the registrant would be made accessible, there would likely be very few reports of inaccurate data on registrants. IPC would also note that the proposal is purely reactive to complaints of inaccurate data; it lacks any proactive element in which registrars would be required to review, check or verify some or all of the contact information and take other steps to improve the overall accuracy of Whois data. IPC urges ICANN to consider setting more proactive requirements in this area, as was recommended by a predecessor to this task force in 2004. See http://gnso.icann.org/issues/whois-privacy/Whois-tf3-preliminary.html#SummaryofWork.

4. IPC takes no position on the fourth aspect of the OPOC proposal, which concerns facilitating domain name transfers.

II. Re: Special Circumstances Proposal (Annex B)

IPC supports this proposal in principle. It would remove from public access only that Whois data whose publication would represent a demonstrable threat to the personal security of a domain name registrant. Unlike the OPOC proposal, which deprives the public of access to registrant contact information even when no privacy interests are present (e.g., when the registrant, or an administrative or technical contact, is a business entity, not an individual), the special circumstances proposal ties the issue of access directly to personal privacy concerns. The determination of which data the public should be denied access to would be made by an objective third party, using transparent and consistent standards, and subject to annual review. This would be a marked improvement over the status quo. Today, with the proliferation of private and proxy registration systems, any registrant who wishes to hide this data can do so if the registrant is willing to pay a cooperative registrar for the privilege. This undermines the long-standing policy of publicly accessible Whois.

While a number of important practical and implementation issues remain to be resolved with the special circumstances proposal, IPC is aware that a similar system has functioned successfully for several years in the relatively large .NL ccTLD. We believe that the proposal in Annex B includes many of the modifications necessary to adapt the .NL model to the gTLD environment. IPC urges ICANN to pursue further development of the special circumstances proposal.

One feature of the special circumstances proposal which departs from the .NL model is the requirement that only a registrant who is using or will use the name for non-commercial purposes is eligible for special circumstances. This non-commercial criterion has been criticized, primarily on the ground that it will be difficult to apply and enforce. IPC recognizes that, at a minimum, the use of this criterion will complicate the administration of the special circumstances system. Although we feel strongly that anonymity is inappropriate in any case in which someone registers a domain name for the purpose of doing business, and that the need for transparency is at its zenith in such a situation, we would certainly support further study of this criterion and review of point 9 of the proposal, and would be prepared to modify or omit this criterion if this study demonstrates that it would be impractical to maintain it.

III. Proposals for Access to Data (pages xx-xx)

Since the two proposals before the Task Force each call for the elimination of public access to some data that is now publicly available through the Whois service, the question of how to provide an alternative mechanism through which those with a specific legitimate need can obtain this data is crucial. As the representative of a group of stakeholders who clearly have such a legitimate need, the IPC believes that neither of these proposals (nor indeed any proposal that shares the characteristic of removing any Whois data from public access) should be adopted unless or until an efficient, reliable and speedy alternative mechanism for such access is ready to be implemented.

At the same time, it must be acknowledged that the demands on this mechanism will be much greater under the OPOC proposal (or any variant that deprives the public of great quantities of contact data) than it will be under the "special circumstances" proposal (or any variant in which relatively little contact data will be suppressed, based only on an objective showing of need, and only for a limited time period). This is another compelling argument in favor of the latter over the former.

IPC does not believe that any of the five proposals mentioned in the Preliminary Report, standing alone, marks the path toward the alternative access mechanism that is needed, though several of them might contribute elements to that mechanism. At this point we would offer only the following brief comment.

The first proposal listed would essentially leave the question of access to non-public data to the unilateral decision of registrars, although "made subject to best practices." The experience of IPC members with proxy and private registration services illustrates why this is not acceptable standing alone. The preliminary report contains an "early stage statement of how registrars typically deal with" requests for data that is hidden by such services (referred to as "type 1 requests"). This statement asserts that "in a typical case, after the request has been deemed to have been made in good faith, the information is disclose [sic] to the requester." While a system operated consistently with this quotation could go far toward addressing the concern about access to data that is withheld from the public (especially if a relatively narrow set of data fell into that category), the quoted statement does not conform to the experience of many IPC members in dealing with many proxy or private registration services today. All too often, the operators of these services are unresponsive to such requests, even when they are backed up by reasonable evidence of actionable harm. See Registrar Accreditation Agreement, section 3.7.7.3.

IPC would welcome the development of best practices or other protocols that would make the treatment of these requests more consistent, more predictable, and more likely to succeed whenever a bona fide intellectual property concern exists. We would be eager to engage in such a development process, and believe that if sound best practices were successfully applied to proxy/private registration services in the current environment, it would augur well for the prospects of an alternative access mechanism of the kind that would be absolutely essential, if the Whois system were changed to withhold some publicly available data.

13.3 Statement of the Registrar Constituency

Please accept the following statement from the registrar constituency and its representatives to this TF. Section 1) was adopted by a majority vote of the constituency in January, 2006 and formally discussed, reinforced and evolved at each meeting of the constituency since (New Zealand, Morocco, Miami and Sao Paolo). This is in addition to ongoing dialogue about the work of the TF and the constituency position on the registrar constituency mailing list. The commentary included is provided in support of this formal position and includes feedback and commentary from various constituency participants.

1) Formal Position of the Registrar Constituency (ratified)

(i) The GNSO Registrar Constituency continues to support the Operation Point of Contact proposal discussed in the preliminary task force report.

2) Formal Feedback of the Constituency on the TF process, proposals and report

(i) The OPOC proposal represents a variety of compromises between a number of potentially competing interests and strikes a balance between the requirements of network operators, business interests, trademark and intellectual property holders and registration interests. (ii) We urge the task force to complete its work prior to the upcoming meetings in Lisbon, Portugal and to focus on its consideration of access to data to ensure that the proposed policies can be properly implemented by users and providers; specifically, network providers, law enforcement interests, registration interests and those seeking to protect their intellectual property rights. (iii) Without due consideration of access to data, including the important questions of "Who?" and "On what terms?" the task force cannot consider their work adequate or complete.

3) Commentary

Unlike the last minute Business Constituency and Intellectual Property Constituency proposals ("A Pragmatic Approach" and "Special Circumstances" proposals respectively) the Operational Point of Contact proposal does not advocate the irresponsible discontinuation of any aspect of the Whois service. Abolishing aspects of the service, or replacing it entirely, will undermine the stability and security of the internet's domain name system. Neither of these proposals are technically, socially or economically practical and both only serve the narrowest of interests within the business community.

Despite the mischaracterizations that came with the hand wringing and scare tactics of the IPC, BCUC and ISPC, the Operational Point of Contact proposal provides for very small improvement to the Whois system without fundamentally altering its structure or operation. This iterative improvement allows registrants a modicum of privacy without affecting *in any way* the amount of data that is available for legitimate investigative purposes. This stands in stark contrast to the position of the intellectual property lobby, in the guise of the IPC, ISPC and BCUC, which proposes to replace the entire existing whois system with a centrally administered registration database operated by an unaccountable entity according to policies specifically designed to circumvent national law on a global scale.

The policy development process is necessarily participative, consultative and consensus driven. It is also prone to abuse and gaming, as is evidenced by the tactics of those participants who have turned their back on the current set of compromises by tabling their own private proposals - proposals which may or may not even have the endorsement of the interests they purport to represent. Reaction to this type of disingenuous participation will always be swift and predictable.

In this case, compromises were fractured, perhaps irrevocably, as additional proposals were crafted as a defensive measure against the abandonment of the set of agreements that the task force participants had been working with. This type of bad faith participation undermines the foundation and integrity of the GNSO's processes and structure. It may warrant specific examination during ICANN's Board review of the GNSO. The GNSO cannot be allowed continue to function in a manner that permits narrow constituencies to push their own self-interested agenda at the expense of all other stakeholders, especially given the duplicity and overlap of the composition of the intellectual property, internet service provider and business users constituencies. Large business interests must be consolidated into one constituency and arrangements made to allow unrepresented interests to participate in the work of the GNSO.

Finally, the importance of defining which parties shall continue to have access to Whois data pursuant to any policies adopted by ICANN cannot be forgotten. All parties with a legitimate need for access to registration data must continue to have access to this data. Attention must be paid to facilitate the needs of registration (registrants, registrars and

registries) and law enforcement interests and the means by which they access the data they require.

13.4 Statement of the Registry Constituency

Pursuant to requirements of the GSNO policy development process, the Registry Constituency (RyC) submits these comments on the draft Preliminary Task Force Report on Whois Services (the "Report")[8]:

I.                    Constituency position

INTRODUCTION

The Report opens with a summary of "the key findings that have emerged during the work of the Whois Task Force since it was convened in February 2005...." According to the Report:

"The task force has reached agreement on the following issues:

·         Many registrants do not understand the meaning or purpose of the different Whois contacts (billing contact, administrative contact, technical contact).

·         If changes are made to the Whois service, awareness-raising for registrants will be needed.

·         New mechanisms to restrict some contact data from publication should be adopted to address privacy concerns

The task force has been unable to reach agreement on the following issues:

·         The purpose of the Whois contacts

·         Whether different data should be published in Whois."

The RyC concurs with this summary, and these comments will deal primarily with the need (a) to move forward on the areas where there is agreement and (b) to recognize a breakdown in the consensus building process with respect to issues where the task force has been unable to reach agreement. First, however, some general comments are needed to set the stage for the more specific comments on the open issues.

Although this task force was convened in February 2005, it is the outgrowth of proceedings that began in 2001, nearly six years ago. It is a sad commentary on the processes of the GNSO and its task forces that it has taken over six years to arrive at what are essentially two simple conclusions: 1) Most Internet users don't understand the WHOIS service, and something should be done about it; and 2) Users want to protect their personal privacy, but there is no agreement at all on how to achieve this. These blindingly obvious propositions should have been the beginning of the task force's work six years ago, not its present conclusions.

The RyC believes that, if and when this Report reaches ICANN's Board of Directors, the Board should accept the Report with the understanding that the issues involved are not so complex that six years were needed to address them.

The lofty goal of policy making by consensus has been subverted by constituencies that have a vested interested in preservation of the status quo in the WHOIS. The proceedings of this task force and its predecessors have dragged on over the years mainly because of procedural maneuvering with little or no connection to the substantive issues. These tactics were designed to avoid recognition of the simple fact that there is no consensus on the fundamental question of how to reconcile the WHOIS function with protection of personal privacy.

The London School of Economics Study of the GNSO[9] commissioned by ICANN has discussed this breakdown of GNSO procedures and has made a number of recommendations for restructuring the GNSO and its Council to enhance the consensus building process. RyC hopes that ICANN's pending proceeding to improve GNSO structures and processes will result in policy development processes that move far more swiftly than the six year odyssey of the WHOIS task forces.

THE AGREED UPON ISSUES

The RyC believes that the first two agreed issues are connected and require little comment. "Awareness raising" is hardly an issue. The arcane processes of the technical administration of the Internet are understood only by a tiny minority of Internet users. Does anyone support the position that the rest of the world should be burdened with more confusion and befuddlement on WHOIS issues?

The third agreed issue is stated in a way that masks the most serious underlying problem of the WHOIS function ? reconciling individual registrants' legitimate interests in protection of personal privacy with various parties' needs for access to the data. It is a major step in the right direction for the Report to acknowledge that there are indeed privacy concerns (even though this was transparently obvious six years ago). In the tortuous proceedings over the past six years some constituencies have taken the position that registration of a domain name demands a surrender of all expectations of personal privacy, reminiscent of Scott McNealy's infamous dictum, "You have no privacy. Get over it."

At the other extreme, there is a respectable position that anonymity should be an option for domain name registrants, although this is not a position supported by RyC. The increasing international popularity of proxy registrations shows that significant numbers of Internet users want at least partial anonymity that is offered by proxy registration. The RyC does not take a position on the availability of proxy registrations, and believes that this is an issue that is best left to the registrars as a matter of business policy and the requirements of law in their respective jurisdictions.

RyC believes that complete anonymity, even if it were possible to achieve, is not a viable option as a mechanism for privacy protection. In comments filed in the earlier proceeding on the purpose of WHOIS, RyC said:

"[The] explosive growth [of the Internet] has unfortunately attracted a minority of users who do not share the high-minded idealism of the Internet's founders. The spammers, cybersquatters, phishers and other abusers of the functions of the Internet, together with users whose intent is criminal (terrorists, et al.) have made it necessary to recognize that the WHOIS function has purposes beyond its original purpose." [10]

Recognizing this unfortunate reality, RyC believes that some mechanism should be developed that allows the WHOIS data gathered by registrars to be available to authorized law enforcement agencies and other interests with a legitimate need for access while limiting general publication of personal data. Proposals for "tiered access" are examples of mechanisms for this purpose. These appear to offer significant improvements in the protection of personal privacy, as compared to the situation today. RyC recommends that the task force direct its future efforts to finding a workable form of tiered access that might be acceptable to most, if not all, interested parties. (RyC's comments on a proposal for another mechanism, the "Special Circumstances Proposal" are set forth below.)

THE ISSUES NOT AGREED

The two issues not agreed, i.e., the purpose of WHOIS contacts, and the question whether there should be a change in data from that now published, are unlikely ever to be the subject even of rough consensus among the interested parties.

The GNSO resolution on the subject of the purpose, adopted on April 12, 2006, reads as follows:

"The purpose of the gTLD WHOIS service is to provide information sufficient to contact a responsible party for a particular gTLD domain name who can resolve, or reliably pass on data to a party who can resolve, issues related to the configuration of the records associated with the domain name within a DNS name server."[11]

This resolution is supported by RyC with the qualification that it does not preclude access to data by law enforcement and other parties having legitimate needs for access.

RyC believes that a decent respect for registrants' interests in protection of personal privacy demands a change in the type of data published in the WHOIS service. There is, of course, a difference between the types of data collected by registrars, and the types of data published in the WHOIS service. RyC generally supports the concepts underlying the Registrar Constituency's OPoC proposal (although there are some practical concerns addressed below). Registrars have their own business needs for collection of registrant data, and should be able to make decisions primarily based on these needs and on the legal requirements of the jurisdictions where they operate.

RyC strongly believes that there is no acceptable reason for publication of an individual's personal data such as home address, phone number or email address, whether by a registry or registrar. To the extent that such data is needed for law enforcement purposes or for the resolution of conflicts such as intellectual property, the appropriate means to meet these needs should be a tiered access process. RyC acknowledges that a tiered access model presents some policy implementation challenges but believes that it would be very worthwhile to confront those challenges in a constructive and diligent manner.

COMMENTS ON SPECIFIC PROPOSALS

The Report requests comments on three specific subjects:

• The Operational Point of Contact (OPoC) proposal
• The Special Circumstances proposal
• The five proposals in the discussion on access to data

The OPoC Proposal

As stated above, RyC generally supports the underlying concepts of the OPoC proposal. There are, however, special needs of some registries that are not addressed by OPoC. Sponsored registries, including .aero, .cat, .coop, .jobs, .museum and .travel must be able to determine the eligibility of registration applicants. The OPoC proposal does not adequately deal with these needs, but this can be remedied without sacrifice of the general concept that the collection of data should be based primarily on business needs, local law, and the need to escrow data, while the publication of data should be consistent with protection of personal privacy and local law.

With respect to publication of data by registrars, RyC supports that portion of the current OPoC proposal, as follows:

Accredited registrars will publish three types of data:

1) Registered Name Holder

2) Country and state/province of the registered nameholder

3) Contact information of the OPoC, including name, address, telephone number, email.

Also published by the registrar:

·         date of initial registration of the domain name (creation date)

·         expiry date,

·         registry level data as follows: registered name, sponsoring registrar, URI of the authoritative Whois server, authoritative names associated with the registration, and status of the registered name (e.g. lock, hold, expired).

With respect to publication of data by the unsponsored registries, RyC also supports the OPoC position, as follows:

Registry data published is limited to:

·         registered name

·         identity of sponsoring registrar (i.e. registrar name, registrar IANA identification number, URL of authoritative Whois server)

·         nameserver hostnames and corresponding IP addresses associated with the name

·         status of the registered name (e.g. lock, etc.)

·         and ? possibly ? the creation and expiry dates of the name.

RyC believes that the sponsored registries should be free to determine what data should be collected for their specific needs and also to determine whether any data, beyond that listed above should be published.

RyC also believes that the OPoC proposal has a major hole that needs to be filled: what happens when the non-published Whois data is requested of the OPoC? This question must be answered in sufficient detail to provide policy direction regarding what, when, how and to whom non-published Whois data must be released by the OPoC. Until that is done, the OPoC proposal provides a solution for accommodating privacy concerns, but does nothing to deal with the legitimate needs of access for non-published Whois data.

The Special Circumstances Proposal

This proposal could easily be interpreted to be another instance of the delaying tactics that have marred the WHOIS task force proceedings from their inception. It is ludicrous to believe that any registrant concerned with his or her personal privacy would jump through the hoops of this proposal.

Access to Data

The questions of access to data discussed in the Report are generally disposed of in the discussion above. So long as the issue of publication is resolved with adequate protection of personal privacy, the question of access can be dealt with separately and most appropriately by a tiered access mechanism to be developed.

II. Method for Reaching Agreement on RyC Position

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 affirmative vote of six of the seven unsponsored registries and six of the seven sponsored registries (one sponsored and one unsponsored registry did not vote.)] vote.

III. Impact on Constituency

Adoption of the positions advocated by RyC would assist the members of the RyC in fulfilling their legal obligations in their respective jurisdictions, and would be of significant benefit through lifting burdensome contractual requirements. The impact of WHOIS changes is larger for thick registries than it is for thin, and the impact on sponsored registries can be more significant than on unsponsored registries. Any major changes would likely have considerable impact on registries and especially on registrars, in time, money and resources.

IV. Time Period Necessary to Complete Implementation

Completion of the OPoC proposal to deal with policy and procedures to support access to non-published WHOIS data could involve considerable effort because questions must be answered prior to implementation such as the following: Who decides who gets access? How are requests for access authenticated?  To whom should access be given?  Who provides access?  How would access be given?

In addition, implementing a tiered access system would probably involve all registries and registrars migrating from the current WHOIS protocol to the IRIS protocol, a process that would undoubtedly take considerable time.

RyC suggests that the time spent in addressing the above and finding a workable tiered access solution is a step in the right direction and such activity presents a far better investment of time and resources of the Internet community.

13.5 Statement of the Non Commercial Users Constituency

1 The Noncommercial Users Constituency (NCUC) believes that ICANN policies governing the publication of Whois data must be reformed, and quickly. The Operational Point of Contact Proposal ("OPoC Proposal") presented in this Whois Task Force Report is not perfect, but it is the only way to bring some consensus and closure to a problem that has festered for too long.

2 The original purpose of the WHOIS protocol is well known.  When the Internet was an experimental network, the Whois contact information allowed domain administrators to identify each other for the purpose of solving technical problems. This original purpose, according to the GNSO Names Council, was consistent with ICANN's current mission of operational stability, reliability, security and interoperability when it defined the Purpose of Whois on April 12, 2006: "The purpose of the gTLD Whois service is to provide information sufficient to contact a responsible party for a particular gTLD domain name who can resolve, or reliably pass on data to a party who can resolve, issues related to the configuration of the records associated with the domain name within a DNS nameserver."

3 NCUC believes that the Operational Point of Contact (OPoC) Proposal is a judicious compromise that feasibly balances constituency input with the original purpose of Whois, ICANN's Mission and Core Values, and the GNSO Council's April 12 decision. We note again that the OPoC proposal is not what NCUC thinks is the optimal solution. We believe that "Anonymous pamphlets, leaflets, brochures and even books have played an important role in the progress of mankind" and should, in an ideal world, be allowed for political, religious and personal domain name registrants (quote from U.S. Supreme Court decision McIntyre v. Ohio Elections Commission, 514 U.S. 334 (1995)).  But this is not the ideal world.  Accordingly, NCUC representatives have worked hard and in good faith with other Whois Task Force members for a year to review and edit the OPoC proposal.  OPoC incorporates significant review, work, input and edits from all constituencies and creates a balance that ICANN can live with.  Domain name registrants will have some privacy; law enforcement and intellectual property will have access consistent with policies to be established. This is the closest we will ever get to agreement among the existing constituencies.

4 In addition, NCUC believes that the OPoC proposal is much less confusing than the legacy combination of administrative, technical and billing contacts. Under the OPoC proposal it would no longer be necessary to display all of these contacts; the functions would be combined into one. We agree with the idea of permitting or encouraging registrants to list two OPoCs as a form of reliability-enhancing redundancy.

5. Under ICANN's current approach to Whois there are tremendous problems that OPoC would clearly correct.  Today ICANN offers only a contract of adhesion that forces all domain name registrants to supply sensitive and personal contact information, and then allows this sensitive data to be indiscriminately published, in complete form, on the Internet for anyone to harvest and exploit. This global publication of the Whois database serves the special interests of trademark and copyright holders.  It has imposed major costs on registries and registrars while subjecting millions of domain name registrants to spamming, and the risk of stalking, identity theft, and unjustified harassment and surveillance by intellectual property lawyers. It is time for a change. 

6 NCUC believes that the combination of nameserver data and Operational Point of Contact are sufficient to meet the stated purpose for the publication of Whois data, and therefore does not believe that the name and jurisdiction of the registered name holder need to be published.

7 The Special Circumstances Proposal ("SC Proposal") is unacceptable to the NCUC. It is a last-minute proposal submitted by the Intellectual Property Constituency and barely reviewed and edited by the Whois Task Force for lack of time.  As the Terms of Reference tables in Section 2 and 4 of the Task Force clearly show, the SC Proposal does not even address most of the key terms of reference established by the Names Council for the Task Force. It does not define the purpose of the Registered Name Holder contact, purpose of Technical Contact, purpose of Administrative contact, or how inaccurate Whois data will be handled.  Where the OPoC is clear and balanced; the SC Proposal is ambiguous and self-serving for a few communities.

8 The SC Proposal represents the exact opposite of the direction ICANN should be headed. It assumes that all contact data of a domain name registrant should be available without restriction to any member of the public, for any use, and places a heavy burden of proof on individuals to meet a very restrictive set of criteria to prove their eligibility for a basic human right of privacy protection.

9 The far better approach, NCUC submits, is that those who want the access to sensitive data should have to prove their "special circumstances" in order to access the data, just as is now the case with requests for additional information about the holders of telephone records or drivers' licenses.

10 NCUC further notes that the SC Proposal's recommendation, that a third party vendor review all requests for data protection, does not scale globally or across language groups, nor is it consistent with the mission of ICANN or the Purpose of Whois that the Names Council decided.

11 In regard to ccTLD practices, we note that the country codes of the United Kingdom, France, Italy, South Korea, Australia, and Canada (shortly to be finalized) all provide considerably more protection for sensitive data and allow individuals to decide on the publication of their sensitive data as a matter of right.

12 On the question of access to data not published, NCUC agrees with the registrars that there are existing procedures for requesting such data from the registrar of record. But we would like to see the rights of individual registrants made clearer and stronger, and we do not believe that registrars should be able to handle any form of disclosure at their own discretion. We believe that disclosure pursuant to law protects the registrars, registries and ICANN.  Registrar policies should follow those that already exist in their countries for disclosure of unlisted telephone numbers, email and chatroom identities, etc. 

13 At this time, NCUC cannot support a proposal to allow unpublished Whois data to be accessed by anyone who signs a contract agreeing to limitations on the use of the data. Although we recognize that sufficiently restrictive terms and conditions might make such a "tiered access" contract worth considering, we believe that such a policy of access must follow implementation of the OPoC proposal and be part of a new and separate PDP. Discussion of such a proposal must be linked to discussions about what data is collected by registrars; what fees should be charged to users of a tiered access regime (fees being justified both to finance the system, assign costs to cost-causers, and to discourage misuse of tiered access for unmotivated "fishing expeditions"); what limitations should be imposed on use and transfer of the data; what mechanisms would be used to enforce the contract; what kind of entities would be eligible for such contracts, what type of penalties should be imposed for abuse, and what types of access are allowed under national laws

14 NCUC views favorably the idea of giving registrants the option of allowing the domain name to lapse in lieu of revealing the information, as elaborated in the Preliminary Task Force Report.

15 NCUC has always maintained that better privacy protection can pave the way for more accurate data, and therefore supports the OPoC proposal's accuracy improvement measures. Our support for improved accuracy is still contingent, however, upon a movement away from indiscriminate publication of sensitive contact data.

16 We close by reiterating once again the need for ICANN to move forward on this issue. In considering new policies, we urge the GNSO Council members, the GAC and ICANN's Board to pay careful attention to which constituencies have been willing to compromise and make changes in their position to make a new policy possible, and how far those accommodating constituencies have been willing to go. This is the last chance to reach a good faith agreement.

13.6 Statement of the Internet Service Providers and Connectivity Providers Constituency

Introduction

The ISPCP Constituency herein provides input on the proposals to increase privacy protections and limit access to registrant data contained in Whois databases, as requested in the Whois Taskforce Preliminary Report. As it has in the past, the ISPCP stresses the need for balance in adoption of changes, respect for earnest privacy concerns and concern over the limiting access as a means to conceal the identity of organizations or persons involved in illegal or criminal activity.

Internet Service Providers (ISPs) use Whois data for a variety of needs, but most readily to prevent and detect sources of security attacks on their respective networks and servers; to identify sources of consumer fraud, spam, phishing and denial of service attacks; and to support technical operations of their connectivity services. Moreover, since ISPs are a primary source for information on the investigation cyber-crimes, Whois data allows ISPs or law enforcement agencies to obtain some information on the subjects of the investigation that is outside the reach of ISPs but integral to obtaining the resolution of law enforcement needs.

The Operational Point of Contact Proposal

The ISPCP does not see the proposal, in its current form, seeking to remove most whois data and replace it with an operational point of contact (OPOC) as a practical model. There are some material issues that are not addressed by the OPOC which require further elaboration, without which it does not satisfy the needs of ISPs.

The OPOC does not indicate a specific time frame for notification of the registrant, or to obtain a response from the registrant. From a practical standpoint, the lack of specific timing requirements means the need for real time resolution of issues for which ISPs access Whois would not be met. Once the OPOC is contacted regarding an issue with the subject domain, the OPOC may or may not take immediate action to address the alleged activity. There is no requirement that the registrant respond back to the OPOC within any specified time, and in instances where the domain is being used for nefarious or illegal activity, the registrant would have every incentive not to respond at all.

The OPOC does not address the need for corresponding with the registrant regarding matters that are not operational in nature or fall outside the resolution of the domain name. Thus, it does not address some of the needs of ISPs to access registrant data. Illegal attacks on ISP networks, liability concerns rising from illegal uses of domain names and use of websites for criminal activity could fall outside of scope of the OPOC proposal.

In addition, there is no indication that the OPOC would be under obligation or even empowered to effect change when there is a legal request to do so. There is no required connection between the OPOC, the registrant and a registrar. While the OPOC may in fact be the same as the registrant or registrar, it need not be and the OPOC could, either legitimately or under ruse, indicate that it has satisfied its obligation to contact the registrant and will not take any further action to resolve a requester's concerns with the website at issue.

While the limitation of data described in OPOC is overbroad and unacceptable, at the same time, there is a concern that it does not address legitimate privacy concerns in a viable manner. Some in the ICANN Community have described anecdotal instances where a registrant is threatened in some regions of the world for their political views or condemned speech when they have posted statements on their websites. The OPOC does not address how legitimate concerns for safety would be addressed by the proposal. In the example described, the registrant would still be subject to persecution by governments or entities that would be in disagreement with the views published on the site.

Finally, while the ISPCP supports the OPOC goal of correcting inaccurate data, the lack of specific time mandates in the OPOC render the proposal ineffective. It is not clear what constitutes "timely" and it is not clear how long the registrant will have to respond to a registrar's call for revising inaccurate data. Additional details regarding reasonable steps in validating corrections to data are likewise vague and the ISPCP would benefit from further clarification on this plan.

Special Circumstances Proposal

As with the OPOC, the ISPCP has some remaining questions with the Special Circumstances model. The proposal would benefit from further thought and elaboration from the ICANN community on some outstanding issues, including:

It is not clear how "non-commercial" websites are defined. The ISPCP believes that websites that enable financial transactions for charitable or non-profit purposes should be able to apply for special circumstance approval.

The funding of the proposal is unclear. The ISPCP would need further edification on how re-budgeting existing fees would cover the costs of a third party vendor of the program. The term that a special circumstance application is live should be further considered to ensure that it is appropriate in length.

On balance, as between the two proposals, Special Circumstances proposal is more on point in addressing the described privacy protection of registrants. It provides anonymity in instances where there is a legitimate need for it, and would seem to protect those whose information puts them at risk.

Although the ISPCP believes that privacy rights should be extended to all, in accordance with many laws around the world, this right is not limitless and is subject to balancing requirements in law. It is important to note that operating a website is intended to hold oneself out to the Internet community at large.

Since this proposal is based on an existing model that is in effect today, it is deemed to be practical and fitting in its balance of the need to protect the Internet public at large and the needs of those who have a legitimate need for anonymity. In addition, because it is operating within the EU currently, the proposal is likely to fall within the requirements of the EU directives on data protection.

Accessing Data that is Restricted or Removed

Because both proposals seek to limit data that is displayed in Whois, it becomes equally important to address how data can be obtained outside the ordinary circumstances and under what criteria such access would be allowed. The options proposed in the preliminary report provide some viable options:

1 Registrar best practices but without additional requirements

2 UDRP complaint mechanism

3 Re-evaluation of removed data when the reason for removal is no longer valid

4 Access through a contractual means obligating the user to certain limited and pre-approved purposes.

5 As an alternative to correcting or revealing data, the registration would lapse the domain not be in use.

The ISPCP applauds any move towards uniformity of registrar practices. While option one would be useful, without a mandated change to all registrar practices, it would not be a practical solution across the board. The registrants that are using domains for illegal or criminal purposes would obviously be drawn towards registrars that do not follow the described best practices, and this could become somewhat of a business model for unscrupulous registrars. In addition, with best practices, there is no enforcement mechanism and no way to ensure adherence.

Modeling or attaching requirements to access Whois data to the UDRP process may be a possible option, but because the ISPCP members do not have much experience with the UDRP, we would benefit from further clarification on this process and how it could be scaled for Whois uses.

Options three (3) and five (5) are not seen as viable options. There is no strong evidence that circumstances leading to removal of data are likely to change in the life of a domain. While this may be true in some very limited instances, the vast majority of needs to access data would not be fulfilled with this option. Likewise, option five (5) is in effect an invitation for illegal or criminal actors to continue hiding their identity while jumping from registrar to registrar in order to continue their nefarious activity.

On balance, the ISPCP deems option four (4) as the most viable, again in part because it is already in effect in the GNR .Name registry. This limits uses of Whois data to those that are approved and deemed to be legitimate. Those who violate the terms of their agreements can be kept from accessing data going forward, and inappropriate uses of Whois data are prohibited.

Finally, the ISPCP wishes to thank all who were involved in developing and considering the proposals and alternatives. It is our sincere hope that the GNSO can move forward on this issue and act based on this and other comments from the ICANN community.

Appendix A ? Full Task Force Terms of Reference

The GNSO Council agreed the following terms of reference for the Whois Task Force on 2^nd June, 2005:

The mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems.

In performing this mission, ICANN's bylaws set out 11 core values to guide its decisions and actions. Any ICANN body making a recommendation or decision shall exercise its judgment to determine which of these core values are most relevant and how they apply to the specific circumstances of the case at hand, and to determine, if necessary, an appropriate and defensible balance among competing values.

ICANN has agreements with gTLD registrars and gTLD registries that require the provision of a WHOIS service via three mechanisms: port-43, web based access, and bulk access. The agreements also require a Registered Name Holder to provide to a Registrar accurate and reliable contact details and promptly correct and update them during the term of the Registered Name registration, including: the full name, postal address, e-mail address, voice telephone number, and fax number if available of the Registered Name Holder; name of authorized person for contact purposes in the case of an Registered Name Holder that is an organization, association, or corporation; the name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the Registered Name; and the name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the Registered Name. The contact information must be adequate to facilitate timely resolution of any problems that arise in connection with the Registered Name.

A registrar is required in the Registrar Accreditation Agreement (RAA) to take reasonable precautions to protect Personal Data from loss, misuse, unauthorized access or disclosure, alteration, or destruction.

The goal of the WHOIS task force is to improve the effectiveness of the WHOIS service in maintaining the stability and security of the Internet's unique identifier systems, whilst taking into account where appropriate the need to ensure privacy protection for the Personal Data of natural persons that may be Registered Name Holders, the authorised representative for contact purposes of a Register Name Holder, or the administrative or technical contact for a domain name.

Tasks:

(1) Define the purpose of the WHOIS service in the context of ICANN's mission and relevant core values, international and national laws protecting privacy of natural persons, international and national laws that relate specifically to the WHOIS service, and the changing nature of Registered Name Holders.

(2) Define the purpose of the Registered Name Holder, technical, and administrative contacts, in the context of the purpose of WHOIS, and the purpose for which the data was collected. Use the relevant definitions from Exhibit C of the Transfers Task force report as a starting point
(from http://www.icann.org/gnso/transfers-tf/report-exhc-12feb03.htm):

"Contact: Contacts are individuals or entities associated with domain name records. Typically, third parties with specific inquiries or concerns will use contact records to determine who should act upon specific issues related to a domain name record. There are typically three of these contact types associated with a domain name record, the Administrative contact, the Billing contact and the Technical contact.

Contact, Administrative: 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.

Contact, Billing: The billing contact is the individual, role or organization designated to receive the invoice for domain name registration and re-registration fees.

Contact, Technical: The technical contact is the individual, role or organization that is responsible for the technical operations of the delegated zone. This contact likely maintains the domain name server(s) for the domain. The technical contact should be able to answer technical questions about the domain name, the delegated zone and work with technically oriented people in other zones to solve technical problems that affect the domain name and/or zone.

Domain Holder: The individual or organization that registers a specific domain name. This individual or organization holds the right to use that specific domain name for a specified period of time, provided certain conditions are met and the registration fees are paid. This person or organization is the "legal entity" bound by the terms of the relevant service agreement with the Registry operator for the TLD in question."

(3) Determine what data collected should be available for public access in the context of the purpose of WHOIS. Determine how to access data that is not available for public access. The current elements that must be displayed by a registrar are:

- The name of the Registered Name;

- The names of the primary nameserver and secondary nameserver(s) for the Registered Name;

- The identity of Registrar (which may be provided through Registrar's website);

- The original creation date of the registration;

- The expiration date of the registration;

- The name and postal address of the Registered Name Holder;

- The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the Registered Name; and

- The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the Registered Name.

(4) Determine how to improve the process for notifying a registrar of inaccurate WHOIS data, and the process for investigating and correcting inaccurate data. Currently a registrar "shall, upon notification by any person of an inaccuracy in the contact information associated with a Registered Name sponsored by Registrar, take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with a Registered Name it sponsors, it shall take reasonable steps to correct that inaccuracy."

(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.]

Appendix B ? Proposal to the Task Force by Avri Doria, Milton Mueller, Robin Gross and Wendy Seltzer

Understanding the role of ICANN and the gTLD Whois to enhance the security and stability of the DNS

A proposal for the GNSO Task Force on Whois Services

prepared December, 2006

Background

I) The purpose of Whois

It is widely accepted that the original gTLD Whois service was used for the purpose of coordinating technical actors as they sought to resolve operational issues related to the security and stability of the DNS and a well-functioning internet.

The importance of this original, technical purpose was reaffirmed in the GNSO council's recommended[12] definition on the purpose of Whois:

"The purpose of the gTLD Whois service is to provide information sufficient to contact a responsible party for a particular gTLD domain name who can resolve, or reliably pass on data to a party who can resolve, issues related to the configuration of the records associated with the domain name within a DNS name server."

The scope of use of published Whois data has increased considerably beyond this over time, a subject that has already been substantially considered by the GNSO Whois Task Force and Council. The scope of use of the internet has also changed over time, as have the management tools used to administer these uses.

The public debate over Whois is overlooking a very important fact. In all Whois uses related to the security and stability of the DNS, the truly useful information is not the contact information for the domain name registrant, it is the name server information for the name in question. Unfortunately, neither the contact information nor the name server information in Whois is reliable or useful, because authoritative information about DNS resources doesn't live in a gTLD database, it lives inside the DNS itself.

The validity of the data in a gTLD Whois database has no impact on the operational integrity of the DNS.

Due to this disconnect between DNS and Whois, network systems managers rarely rely on gTLD Whois service when they seek to investigate or resolve serious network operations and technical coordination issues. An entirely different set of tools and resources that relies on authoritative data have evolved that support the requirements of these types of users. For example, a network administrator might use "dig"[13] or "nslookup"[14] to determine the source of a DNS problem or the network location of a mail server being abused to send spam email. All of these tools are publicly available at no charge, internet standards based, and in widespread use.

Furthermore, from a network management perspective, not only is the data in the DNS resource records more authoritative (and therefore useful), it is also more comprehensive. A typical DNS record can include information about the network location of any and all web servers, email servers and other resources associated with a specific domain name ? at all sub-levels associated with the specific DNS entry (i.e., the second, third and fourth levels of the domain hostname). The gTLD whois service contains none of this important information.

When DNS data is used in conjunction with the IP Address Whois data sourced from providers like ARIN or RIPE, a network administrator is able to form a fully authoritative view of not only the services associated with a specific domain name, but also the identity of the entity that physically hosts those resources and how to contact that entity. All of this data exists outside the gTLD Whois system.

II) ICANN's Role

The scope and authority of ICANN's policy-making responsibilities is limited by its bylaws;

The mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems. In particular, ICANN:

1. Coordinates the allocation and assignment of the three sets of unique identifiers for the Internet, which are:

a. Domain names (forming a system referred to as "DNS");

b. Internet protocol ("IP") addresses and autonomous system ("AS") numbers; and

c. Protocol port and parameter numbers.

2. Coordinates the operation and evolution of the DNS root name server system.

3. Coordinates policy development reasonably and appropriately related to these technical functions.

ICANN's role is primarily that of a technical coordinator and developer of policy to support that coordination.

III) ICANN's Scope

There are many other uses of gTLD Whois - most or all of which have been documented by the GNSO Whois Task Force[15]. Creating policy to manage, influence, prevent or encourage most of this use is out of scope for ICANN.

IV) Technical coordination in the real world

Most technical coordination of DNS administration, abuse and network management issues occurs without ICANN's involvement. Private sector coordination is more likely through CERT, NANOG, Reg-OPS and other forums, than those operated by ICANN. These initiatives are often ad hoc and key players do often not understand the importance and value of participation. This is an area where small improvements in the overall level of cooperation between the various initiatives would lead to substantial improvement in the overall security of the internet and DNS infrastructure.

Policy Implications

Given that the original beneficiaries of the gTLD Whois service have developed superior alternate methods of coordinating their activities, and that the remaining uses of this service are out of scope relative to ICANN's scope and mission, and that the abuse of this data has caused a significant barrier to the security of millions of Internet users, we propose the following;

1)      That ICANN amend its contracts to waive all Whois publication requirements for gTLD registries and registrars;

a.      Until the contracts are amended to do this, Whois publication requirements should be limited to only publishing contact information for the person or entity responsible for managing the authoritative DNS server;

2)      That ICANN immediately undertake a study of where it might best contribute to coordinating the network management activities of registration interests, network operators and service providers with law enforcement agencies. This should be done with the goal of ensuring that emergency response and technical abuse prevention is well coordinated and the overall interests of internet users are appropriately protected by a secure and functional domain name system.

3)     That ICANN undertake to develop a statement of best practices that registration interests should apply when working with law enforcement interests, network operators and other legitimate parties concerned with public safety, legislative enforcement, network management and abuse, and the protection of critical information technology infrastructure.

Appendix C ? Proposal to the Task Force by Marilyn Cade

Pragmatic and Achievable Steps toward Addressing Concerns about Public Access to WHOIS Services

This paper is authored by Marilyn Cade, in her individual capacity. It draws upon experience in co-chairing the original WHOIS Task Force; participating and reviewing an extensive survey that received slightly over 3,000 responses; reviewing public comments to various Task Force reports; attending and participating in ICANN's extensive workshop series on WHOIS Issues, and upon her experience in today's GNSO WHOIS Task Force.

I. Background:

Attempts to define the original purpose of WHOIS services encounter many disputes, according to who is speaking, whether it is a business user; an ISP/connectivity provider; a privacy activist/organization; a registry or registrar, law enforcement agency, a sys-adm dealing with network attacks; a legal advisor inside/outside a corporation.

Much of the debate on WHOIS centers around whether and what data should be publicly displayed. There has been less disagreement about the need for accurate data, and that there are legitimate uses for contact data. There are some different views on which 'Internet tools' or other resources might substitute for access to accurate WHOIS data, but little exploration and there is no agreement on whether such 'tools' are indeed substitutes.

2. Incremental Steps in the Right Direction:

This proposal takes into account that there has been extensive discussion, over a number of years, about the uses, and potential misuses of WHOIS. The proposal is agnostic on the mission and purpose of ICANN and merely addresses a pragmatic approach to addressing certain concerns about public access to displayed data in WHOIS.

The proposed approaches described below are not intended to be the total answer to all questions raised about publicly available WHOIS data. Thus, the author's proposal takes a short term to medium term approach to how public access to WOIS data can be addressed, while a more informed analysis/study is undertaken, but on a fast track. The author recognizes that the approach suggested is remedial, but notes that it can take place while further analysis and study is undertaken.

II. Proposed Changes in Display of WHOIS Services:

The proposal seeks to create significant changes to the display method, and therefore the access to public displayed data. Such changes can help to curtail, if not eliminate alleged and/or actual data mining and harvesting of email and telephone numbers. In addition, this proposal would, if implemented, create strict limits to how bulk access and Port 43 access to WHOIS data is granted, and the creation of a 'white list' of authorized uses, and users for bulk access.

All WHOIS access should be changed in all WHOIS services to web based access. Such web based services should include an Image Verification Check (IVC) of sufficient security strength so that the random letters generated are not easily machine readable. The requirement to implement such a system should become a part of consensus policy, but the mechanism that each registrar/registry uses for IVC should be of their selection, as long as sufficient security is ensured.

All bulk access should be moved to ICANN managed contractual terms for access, with an application/accreditation process for parties allowed to have such contracts. This consideration was first proposed by the initial DNSO WHOIS Task Force and deserves further consideration. The 'white list' should be maintained by ICANN, and will require a suitable cost based fee to bear the cost of implementation. Criteria for application/accreditation will need further examination, and should be posted for public comment as part of the development of said criteria. ICANN should develop standard terms and conditions for the agreements, and ICANN should provide enforcement when they are violated and complaints are received from the registry/registrar for such violation, including removing the accreditation for the 'white list'; such as charging additional fee penalties, etc.

In general, parties who need bulk access for legitimate purposes are trademark and other firms that provide trademark defense or portfolio management services. Consensus policy may be needed to establish the framework for collaboration to achieve a balanced solutions and terms. ICANN operational staff will play a significant role in helping to develop and implement a suitable approach.

This approach does need further exploration with law enforcement and consumer protection authorities to ensure how best to address their need for port 43 access or bulk access.

III. Study of WHOIS:

Today, there are close to one billion users of the Internet; with approximately 87 million registered domain names. While estimates vary, approximately 75%+ of these are registered in gTLDs, and approximately 25% are registered in country codes. It is clear that while some users may find identity in a domain name as an individual, the vast majority of Internet users do not rely on domain names, but rely on ISPs, web hosters, and connectivity providers to provide them with identity online via web email addresses, individual web pages, etc. In short, what and who will support identity on the Internet is yet to be determined and continues to evolve.

Certainly, some individual users do, and will turn to domain names to create identity sites, as well as to provide online services, communications, provide email addresses. But for the vast majority ? the jury is still out. Especially since the vast majority are yet to actually come online. IDNs and other innovations in affordable devices; new affordable access technologies, and increased 'online literacy' all hold great promise to draw the second billion users to the Internet.

Given the changes in gTLDs, and in the Internet itself, it is critical that ICANN undertake and fund an independent third party study to establish neutral and documented research ? which will undoubtedly help to provide factual information that can help to inform policy making in WHOIS. It is time for a comprehensive study which should address the characteristics of registrants and of users of WHOIS data in the non sponsored gTLD registry space.[16] This study should be undertaken by a neutral third party, retained and funded by ICANN, and study such issues as the characteristics of registrants; whether a domain name is actually in use [live DNS], uses and misuses/abuses of WHOIS data.

Elements of a study of non sponsored gTLDs and WHOIS, to encompass at least the following issues and questions should include:

Uses, misuses and abuses of WHOIS data, as publicly displayed

Characteristics of registrants in the non sponsored/open gTLDS,

e.g.: numbers of registrants who: 1) use the domain name for personal use; 2)for 'speculation/holding/resale; 3)for traffic aggregation; 4)for non commerce; and 5)for commerce online and 6) governmental or related purpose 7) other

Identify the number of sites that are registered, but do not have 'live DNS' versus those that are actually in use

Identify the percentage of inaccurate data, and a sample examination of why the data is inaccurate ? e.g. a) aged data; b) typo/registrant error c) purposeful provision of inaccurate data[17] d) other

IV. Consequences and Considerations in Changes in WHOIS Access and Display:

System wide changes in any 'system' have to take into account not just the parties who make the changes in the systems that they provide, such as the registrars and registries, but also the users and registrants of such systems, and how they will be informed and assimilate such changes. The impacts of significant changes that affect users/registrants have not yet been addressed in the earlier two proposals. This issue remains a vital, and significant challenge to any system wide change, including those changes proposed in this proposal. Consideration of the impact and cost will still need to be undertaken.

Incremental versus Revolutionary Change Approaches: In any operating system that needs to be used and accessible on a 24/7 basis, consideration also has to be given to when and how to make changes; whether dual systems can coexist for a period, what the cost implications are, impact on service and on service provider. No exploration of that has been done by the author. Such explorations are still pending for the other two proposals as well.

V. The role of IRIS/CRISP:

Much discussion has been given to the role of IRIS/CRISP as a replacement protocol. Making such a system wide change will be an extensive change and require extensive time to implement. The change in the protocol will enable more flexibility in data access and display than presently exists in the systems utilized by the registrars. However, the timing of any such shift by all the registrars, or by the majority of the larger registrars is unclear. It would be useful for any and all considerations for change in data display/access to be informed by the status or likelihood of a move to IRIS.

This proposal's recommendations should also be discussed regarding any relationship, or implications.

Appendix D ? Work Processes and Outreach Activities of the Task Force, 2005-2007

The Combined Whois Task Force met regularily by conference call approximately every two weeks (and occasionally on a weekly basis) from January 2005 to the end of February, 2007.

The following information outlines the main outreach activities outside of public comment periods conducted by the Whois Task Force and its members since early 2005.

CRISP Presentation

Cross Registry Information Protocol (CRISP) Presentation to WHOIS Task Forces 1 & 2
12 January, 2005

Presentation by Andrew Newton and Leslie Daigle

http://gnso.icann.org/meetings/transcript-crisp-12jan04.htm

GNSO Public Forums

The Task Force gave formal updates on the Whois PDP as part of the GNSO Public Forums held during the following ICANN meetings:

Mar del Plata, April, 2005

Luxembourg, July 2005

Vancouver, December 2005

Wellington, March 2006

Marrakech, June 2006

The Task Force gave a formal update and took part in lengthy discussions on the Whois PDP in a dedicated Whois Public Forum held during the ICANN meeting in Sao Paulo, December 2006. A summary of this event, including the presentations and real time captioning, is available here; http://gnso.icann.org/issues/whois-privacy/summary-whois-gnso-public-forum-saopaulo-04dec06.pdf .

Government Advisory Committee initiatives

Updates on the Whois PDP were also made at meetings of the Government Advisory Committee (GAC) to the Board of ICANN at each ICANN meeting in this period.

Task Force members attended a closed workshop on Whois and law enforcement organised by the GAC in Luxembourg, July 2005. Task Force members participated in an open meeting held by the GAC entitled "Govt. Perspectives on Public Policy Aspects of WHOIS" during the ICANN meeting in Marrakech, in June 2006.

Task Force members participated in a conference on privacy held during the Vancouver meeting (December 2005) by the Non Commercial Users Constituency, The Public Interest Registry, the Registry Constituency and Cole, Raywid & Braverman LLP.

Other Whois-related meetings

Task Force members and an ICANN Board Director participated in a panel discussion on Whois organised by the Metropolitan NY Chapter of the Internet Society and chaired by Danny Younger on 8^th November, 2006.

Task Force members participated in a conference on privacy and Whois with contributions by individuals from Latin America and the Caribbean organised by the Non Commercial Users Constituency and held during the Sao Paulo meeting, on 5^th December, 2006.

Appendix E ? Relevant GNSO Council Resolutions

23^rd June, 2005, Resolution 20050602-02

"The GNSO Council accepted the Terms of Reference for the combined WHOIS task force, noted here: http://gnso.icann.org/policies/terms-of-reference.html".

·         Meeting minutes available at http://gnso.icann.org/meetings/minutes-gnso-23jun05.shtml

12^th April, 2006, Resolution 20060412-01

"The GNSO Council recommends that the WHOIS task force use the following definition:

"The purpose of the gTLD Whois service is to provide information sufficient to contact a responsible party for a particular gTLD domain name who can resolve, or reliably pass on data to a party who can resolve, issues related to the configuration of the records associated with the domain name within a DNS nameserver."

as a working definition to allow the task force to proceed on terms of reference (2), (3), and (4) (see: http://gnso.icann.org/policies/terms-of-reference.html )."

·         Meeting minutes available at http://gnso.icann.org/meetings/minutes-gnso-12apr06.shtml

20^th July, 2006, Resolution 20060720-02

"The GNSO Council notes that the WHOIS definition approved by the GNSO Council on 18 April 06, as a working definition to allow the WHOIS task force to proceed with its work, is related to the service that provides public access to some of the data collected by registrars. It is not a definition of the purpose of the data collected by the registrars in the course of registering a domain name for their customers.

In response to the extensive community and Government input on the definition of the purpose of WHOIS, the GNSO Council agrees to undertake the following steps:

(1) Any Council member who voted in favour of the definition may provide a brief explanation of the reason for supporting the resolution and their understanding of its meaning. An Advisory Committee that supports the current definition may also make a statement for the record through the appropriate liaison to the GNSO Council.

(2) The ICANN staff will provide a summary of the other interpretations of the definition that have been expressed during the public comment period, and subsequently in correspondence from the public and Governments.

(3) The GNSO Council requests that the WHOIS task force continue with their work as specified in the terms of reference taking into account the recent input that has been provided.

(4) The GNSO Council will take the Final Report (as specified in clause 9(c) of the GNSO PDP process) from the WHOIS task force after the task force finishes its work on all the terms of reference, engage in further dialogue with the Advisory Committees (including the GAC, SSAC and ALAC), and consider improving the wording of the WHOIS service definition so that it is broadly understandable.

Note that the WHOIS Task force will produce a Task Force Report (as specified in clause 7(e) of the GNSO PDP process) later in 2006 that addresses all terms of reference. This report will be subject to a further public comment process, and the output of this public comment will be incorporated into the Final Report.

Note that the previous clause (3) in the motion posted on 13 July 2006 that related to the purposes for collecting data is now the subject of a separate motion."

• Meeting minutes available at http://gnso.icann.org/meetings/minutes-gnso-20jul06.shtml

20^th July, 2006, Resolution 20060720-03

"The GNSO Council notes that, consistent with generally accepted privacy principles, Registrars are required under clause 3.7.7.4 of the Registrar Accreditation Agreement to provide notice to each new or renewed Registered Name Holder stating:

(i) The purposes for which any Personal Data collected from the applicant are intended;

(ii) The intended recipients or categories of recipients of the data (including the Registry Operator and others who will receive the data from Registry Operator);

(iii) Which data are obligatory and which data, if any, are voluntary; and

(iv) How the Registered Name Holder or data subject can access and, if necessary, rectify the data held about them.

To further understand the range of purposes for which data is intended, the GNSO proposes the following steps:

(1) The ICANN staff will review a representative sample of registrar agreements with Registered Name Holders, taking into account the issues of geographical diversity and rule of law variances, to identify some of the purposes for which registrars collect Personal Data in the course of registering a domain name for their customers.

(2) The ICANN staff will review a representative sample of cctld registry or cctld registrar agreements with registrants, taking into account the issues of geographical diversity and rule of law variances, to identify some of the purposes for which these organisations collect Personal Data from registrants.

(3) The ICANN staff will summarise the current material that has resulted from WHOIS discussions since 2002 that document the current uses and abuses of the Personal Data that is currently made public through the WHOIS service.

(4) Supported by the material produced in steps (1), (2) and (3) above, the Council will undertake a dialogue with the ICANN Advisory Committee's, such as the GAC, SSAC and ALAC, regarding the purposes for collecting Personal Data, and discuss whether any policy development is required in this area consistent with ICANN's mission and core values.

The dialogue should seek to examine and understand consumer protection, privacy/data protection and law enforcement perspectives."

• Meeting minutes available at http://gnso.icann.org/meetings/minutes-gnso-20jul06.shtml