WHOIS Task Force
9 May - MinutesATTENDEES:
GNSO Constituency representatives:
Jordyn Buchanan - Chair
gTLD Registries constituency - David Maher
gTLD Registries constituency - Simon Sheard
Registrars constituency - Ross Rader
Registrars constituency - Tom Keller
Internet Service and Connectivity Providers constituency - Maggie Mansourkia
Internet Service and Connectivity Providers constituency - Greg Ruth
Intellectual Property Interests Constituency - Steve Metalitz
Commercial and Business Users constituency - Marilyn Cade
Non Commercial Users Constituency - Kathy Kleiman
Ex officio :
Nominating Committee appointee - Avri Doria
Liaisons
At-Large Advisory Committee (ALAC) liaisons - Wendy Seltzer
GAC Liaison - Suzanne Sene - absent
ICANN Staff:
Olof Nordling - Manager, Policy Development coordination
GNSO Secretariat - Glen de Saint Géry
Absent:
gTLD Registries constituency - Ken Stubbs - excused
Internet Service and Connectivity Providers constituency - Tony Harris - excused
Commercial and Business Users Constituency - Sarah Deutsch
Commercial and Business Users Constituency - David Fares -excused
Non Commercial Users Constituency - Milton Mueller
Intellectual Property Interests Constituency - Niklas Lagergren
Registrars constituency - Paul Stahura
gTLD Registries constituency - Tuli Day
Non Commercial Users Constituency - Frannie Wellings
Registrars constituency - Tim Ruiz (alternate)
MP3 Recording
Agenda: 1. Avri Doria's status as a task force member
2. Task force chair
3. GAC participation and interaction
4. Time of the task force call
5. Further work on the WHOIS task force terms of reference Item 1: Avri Doria's status
Jordyn Buchanan reported that Avri Doria's current status in the task force was ex officio and for her to have full task force participation, the GNSO Council should pass a motion. Avri Doria has already requested the GNSO Council chair to do so at the next Council meeting.
Item 2: Task force chair
Jordyn Buchanan reported that continuing as the task force chair presented no conflict in his new employment situation and that the GNSO Council should adopt a resolution to appoint him to the task force with the caveat that it would be difficult to attend all ICANN meetings and if the task force felt that was an impediment, he would step aside as chair.
Tom Keller suggested an interim chair be elected for the meetings.
Steve Metalitz supported by Tom Keller proposed that Jordyn Buchanan continue as chair given the caveats.
Marilyn Cade and Tom Keller proposed formulating the resolutions for both this item and item1 above for the Council.
Jordyn Buchanan suggested his participation as a non voting chair should be mentioned in the resolution.
Item 3: GAC/WHOIS task force participation and interaction
An action item arising from the task force call on 25 April 2006.
The topic is currently under discussion in the GNSO Council, which will respond to the GAC on the communiqué
Marilyn Cade commented that interaction was needed on 2 levels:
- interaction at a task force level
- interaction at the Council level
Board vote on national conflict issue arising from the GNSO Council minutes 18 August 2005.
Olof Nordling reported that it was ready to be discussed by the Board and was on the Board agenda for the 10 May 2006 meeting.
The "Notification to Registrants" was pending a recommendation at the Council level.
The "Accuracy" group led by Niklas Largergren was expected to issue a report in time for the Marrakesh meetings.
Item 4: WHOIS task force call time: It was agreed to change the time of the WHOIS task force call from 13:30 UTC to 14:30 UTC, that is 10:30 EST, and 16:30 CET.
It was genarally agreed that procedural issues should be discussed on the WHOIS task force mailing list to allow for substantive discussions on the remaining work. Item 5: Further work on the WHOIS task force terms of reference There are 3 remaining work items from the WHOIS task force terms 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
(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."
Kathy Kleiman proposed to withdraw the NCUC Procedural proposal. While the NCUC considered that the proposal raised relevant and important issues, it was probably not the appropriate next step for the task force and proposed moving on to an evaluation and consideration of public access, the next item in the Terms of Reference and supported a meeting on public access in Marrakech.
Kathy Kleiman asked: Now that a purpose for our database has been established, it is a legal and logical step to determine whether the data we are making public via the WHOIS service is appropriate. Is the data that is made public required to meet the purpose?
Jordyn Buchanan suggested that when the data output was agreed on, the language could be refined on its relation to the purpose of WHOIS Jordyn Buchanan proposed using the Operational Point of Contact Proposal (oPOC) as a template and a starting point for dealing with each area in the terms of reference as noted above.
The oPOC proposal is in 2 parts,
1. Proposal
2. Motivations and considerations Ross Rader walked the task force through the proposal which can be found on Wiki pages.
http://forum.icann.org/lists/gnso-dow123/msg00972.html
The data in the WHOIS system had exceeded its utility and there was a need to put forward a proposal to collect different data. The purpose of this proposal is to rebalance the information contained in the gTLD Whois System and how it is made available in order to make it more appropriate for its intended use given the changing nature of gTLD Registrants, the domain name system and the Internet. Proposal
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).
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 contact information for the primary operational point of contact (oPOC), which must include, but is not limited to;
3. The contact name of the oPOC
4. The contact address of the oPOC
5. The contact telephone number of the oPOC
6. The contact email address of the oPOC
7. The date of the initial registration of the domain name (creation date)
8. The date of the expiration of the current term of the domain name (expiry date)
9. The following registry level data:
10. The Registered name
11. The identity of the Sponsoring Registrar
12. The URI of the authoritative Whois server
13. All authoritative nameserver names associated with the domain name registration record
14. The status of the Registered Name (LOCK, HOLD, EXPIRED, or any other Registry specified value) Registrars may choose to allow Registrants to specify additional operational points 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;
The Registered name
The identity of the Sponsoring Registrar which shall consist of separate fields indicating;
the Registrar Name and;
the corresponding IANA Registrar Identification Number
The URI of the authoritative Whois server
All authoritative nameserver hostnames and corresponding IP addresses associated with the domain name registration record
The status of the Registered Name (LOCK, HOLD, EXPIRED, or any other Registry value specified in the EPP RFC) 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; the Registrar must notify the Operational Point of Contact or the Registered Name Holder in a timely manner.
The oPOC or the Registered Name Holder must correct the alleged inaccuracy or defend the accuracy of the data, also in a timely manner.
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.
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. 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 requestThis 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.
Ross emphasised that the proposal would not change data being currently collected and that there would be a transition and implementation period, but these had not yet been precisely defined.
It was agreed to use this proposal as a starting point.
Jordyn Buchanan concluded by attempting to map the proposal to: - TOR 2 - purpose of contacts
that data would still have to be collected but that old contacts would be depricated and replaced with new ones.
the registered name holder should have a purpose definition
- TOR 3 - access
leave the access mechanism, port 43 and 80 etc, but change the data displayed
-TOR 4 - "timely notice" needs to be defined. "Discretion would be removed and replaced by 2 options:
---prove contactability
or
---loose the name
Jordyn Buchanan proposed circulating a summary with regard to purpose of the contact using the oPOC proposal as a template for the next call and encouraged the task force to work on the mailing list. Next Task Force Call: MAY 23 2006 at 7:30 LA, 10:30 EST, 14:00 UTC, 16:30 CET,
| 