[council] WHOIS task force recommendation

["Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>]

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