PDF Version [164K] Table of ContentsSUMMARY OF THE 'SPECIAL CIRCUMSTANCES' PROPOSAL TERM OF REFERENCE 2: PURPOSE OF THE CONTACTS Summary of task force discussion TERM OF REFERENCE 3: PUBLIC ACCESS TO DATA Summary of task force discussion (including proposals for access to data) TERM OF REFERENCE 4:� INACCURATE DATA Summary of task force discussion Statement of the Commercial and Business Users Constituency Statement of the Intellectual Property Constituency (IPC) Statement of the Registrar Constituency Statement of the Registry Constituency Statement of the Non Commercial Users Constituency Statement of the Internet Service Providers and Connectivity Providers Constituency Annex B � DRAFT Special Circumstances Proposal Annex C � Task Force Terms of Reference EXECUTIVE SUMMARYThis is the draft Preliminary Task Force Report on Whois Services. This report forms part of 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 that have emerged during the work 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:
The task force has been unable to reach agreement on the following issues:
Public comments are particularly invited on:
There will be a public comment period on this preliminary task force report from 24th November, 2006 to 15 January, 2007. After the public comment period, the Whois Task Force will consider the public comments received and prepare a final task force report for submission to the GNSO Council.� | back to top | INTRODUCTIONThis document is the Preliminary Task Force Report on the Whois Service. It summarises the work of the WHOIS Task Force to date, and invites public comments on the policy issues addressed. 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):
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.html, 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. Following the public comment period on this preliminary task force report (November, 2006 to 15th January, 2007), the Whois Task Force will consider the public comments received and prepare a final task force report for submission to the GNSO Council. 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 Non-Commercial Users Constituency Milton Mueller Frannie Wellings 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.) | back to top | Summary of voting
The task force also conducted straw polls to gauge support for various recommendations described in this report�the results of the straw polls are described in the sections of this report that describe those recommendations.� The task force is also requesting that GNSO constituencies provide constituency statements on the policy recommendations and other elements of the Task Force's terms of reference.� These constituency statements will provide a further opportunity for constituencies to elaborate on their policy positions. | back to top | BackgroundThis section outlines the procedural background of the policy development process on Whois, outlining the key developments since this process began in 2003. 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 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.html) On 29 October, 2003 during the ICANN meeting in Carthage, (http://gnso.icann.org/meetings/minutes-gnso-29oct03.html) 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 Terms of Reference: area 1 http://gnso.icann.org/issues/whois-privacy/tor.html 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.html) � 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: 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.html#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 2nd 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). (http://gnso.icann.org/meetings/minutes-gnso-02jun05.html) 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)". | back to top | SUMMARY OF THE OPoC PROPOSALThe 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.� Its 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.� It is broadly supported by task force members from the following constituencies or groupings[1]:
The 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 a mechanism for access to Whois data 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. | back to top | SUMMARY OF THE 'SPECIAL CIRCUMSTANCES' PROPOSALThe 'special circumstances' proposal (full text in Annex B) was introduced by the Intellectual Property Constituency to the task force on 25th September 2006.� It is "the result of discussions among members of the IPC and other constituencies and is a working draft, based largely on the model used for several years in the Dutch ccTLD, .NL". (email from Steve Metalitz, Intellectual Property Constituency, to the task force, 25 September, 2006) This proposal has not been developed by the task force, but some modifications have been made to it following a task force discussion (a re-organized version of the proposal was posted on November 4 and is the text in Annex B). . It is broadly supported by task force members from the following constituencies or groupings:[2]
NB The BC has expressed support for considering this proposal and elaborating it. Other constituencies have not yet expressed a mandate of support for this proposal. This may change before this preliminary report is finalized, e.g. in the constituency statements. The Special Circumstances Proposal is based on the practices of the .NL ccTLD (Netherlands) which is subject to European data protection law. This proposal is intended to "accommodate the needs of certain individual registrants of second level domain names for special treatment with regard to public access to some contact data." It allows individuals who demonstrate the existence of special circumstances to substitute contact details of the registrar for the data that would otherwise appear in published Whois. The Special Circumstances Proposal does not include a mechanism for improving notification and correction of inaccurate Whois data. In a task force discussion, it was suggested that the ability for individual registrants to avoid publishing their contact information might lead to improved accuracy of Whois data. The Special Circumstances Proposal does not include a mechanism for access to unpublished Whois data by, for example, law enforcement agencies or intellectual property rights holders.� The proposal envisages that full contact data of individuals would be held back from publication in the Whois only when this "would jeopardize a concrete and real interest in their personal safety or security that cannot be protected other than by suppressing that public access". This would seem to indicate that the vast majority of contact information would be published in the Whois, and that means of access to unpublished data would rarely be required. | back to top | TERM OF REFERENCE 2: PURPOSE OF THE CONTACTS�Term of reference: "(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: "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."
| back to top | Summary of task force discussionThe 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. | back to top | TERM OF REFERENCE 3: PUBLIC ACCESS TO DATA��������Term of reference: "(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."
| back to top | Summary of task force discussion (including proposals 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. | back to top | TERM OF REFERENCE 4:� INACCURATE DATA"(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."
| back to top | 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.[3] 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. | back to top | Constituency statements are being solicited in parallel with the public comments period held from November 2006 to January 15th, 2007. The Final Task Force Report to be submitted to the GNSO Council will include the Constituency Statements. 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. " | back to top | Statement of the Commercial and Business Users ConstituencyStatement of the Intellectual Property Constituency (IPC) Statement of the Registrar ConstituencyStatement of the Registry ConstituencyStatement of the Non Commercial Users ConstituencyStatement of the Internet Service Providers and Connectivity Providers ConstituencyAnnex A - OPoC Proposal(as of 18 October, 2006) 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. | back to top | Annex B � DRAFT Special Circumstances Proposal(Revised version emailed to the Whois Task Force of 4 November, 2006) An Alternative "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"[4] 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"[5] data be substituted).� The holder or applicant must submit a written request for data to be withheld from the public section of the register.[6] 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.[7] Another SIDN document[8] 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. | back to top | Annex C � Task Force Terms of ReferenceThe GNSO Council agreed the following terms of reference for the Whois Task Force on 2nd 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 "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.] [1] The Task Force conducted a straw poll to measure support for the proposal, with representatives from 3 constituencies (Registrar Constituency, Registry Constituency, and Non-Commercial Users Constituency) and the Nominating Committee appointee supporting the OPOC proposal, and the other 3 Constituencies (Intellectual Property Constituency, Business Constituency, and Internet Service Providers and Content Providers) abstaining. [2] The Task Force conducted a straw poll to measure support for the proposal, with representatives from 2 constituencies (Intellectual Property Constituency and Business Constituency) supporting the proposal; representatives from 3 constituencies (Registrar Constituency, Registry Constituency, and Non-Commercial Users Constituency) and the Nominating Committee appointee opposed to the proposal, and with representatives from one constituency (Internet Service Providers and Content Providers Constituency abstaining. [3] The Task Force conducted a straw poll to measure support for the proposal, with representatives from three constituencies (Registry Constituency, Intellectual Property Constituency and Non-Commercial Users Constituency) supporting the proposal; representatives from the remaining three constituencies (Registrar Constituency, Business Constituency, and (Internet Service Providers and Content Providers Constituency) and the Nominating Committee appointee abstained. [5] "Participant" is the term used for registrars in the .NL ccTLD registry. [6] As opposed to regular .NL domains, the process for requesting that some data be withheld from public access differs for a "personal domain name," which is intended to be used only by individuals.� The "personal domain name" is a special category of domain name in the .NL registry that scarcely exists as a practical matter.�� For the 99.98% of .NL registrants who hold regular domain names, withholding data from public access requires a showing of "special circumstances". |
Preliminary Task Force Report on Whois Services
Last Updated:
Date