Hello All, To avoid confusion, here is the WHOIS Task Force recommendation from the task force report: http://gnso.icann.org/issues/whois-privacy/whois-services-final-tf-repor t-12mar07.htm 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. Regards, Bruce Tonkin