Attendees:

CBUC - Marilyn Cade - Co-Chair
CBUC - Bret Fausett
Registry - Becky Burr
Registrar - Ken Stubbs
Former GA Chair - Thomas Roessler
Former GA additional - Kristy McKee
IPIC - Steve Metalitz
IPIC - Laurence Djolakian
Non Com Users Constit. - Ruchika Agrawal

Louis Touton - ICANN General Counsel

Apologies
ISCPC - Tony Harris - co- chair

GNSO Sec - Glen de Saint Géry

Marilyn Cade noted the inputs to be addressed.

1. Letter from the International Working Group on Data Protection in Telecommunications
http://www.datenschutz-berlin.de/doc/int/iwgdpt/index.htm
(Thomas Roessler brought this to the attention of the task force)
Kenn Stubbs contribution
http://www.dnso.org/clubpublic/registrars/Arc02/msg00246.html
http://www.dnso.org/clubpublic/nc-whois/Arc00/msg00864.html
Thomas Roessler draft Final report
http://does-not-exist.net/final-report/final-report-feb03-030205.html

3. Practical Recommendations: Accuracy of WHOIS Data.
Changed to: Recommendations to ICANN and Registrars

B. (inserted; based on part 3 of the WHOIS implementation committee's work) strike
Changed to:
The following process should be employed in handling accuracy.

Steve Metalitz commented on
5. For a name to be removed from REGISTRAR-HOLD status to active status, the registrant must contact the registrar with updated WHOIS information (as per (3) above), and the registrar must confirm that the registrant is contactable via this new information (for example by requiring that the registrant respond to an e-mail sent to a new e-mail contact address).
The change suggested by Steve, was to delete "example" and add" including but limited to".
Ken Stubbs said that this involves costs, and Steve maintained that the Registrar should cover the costs from registrants and not the complainant.
Ken Stubbs referring to:
http://www.dnso.org/clubpublic/registrars/Arc02/msg00246.html
mentioned that responses had been received from a large number of registrars to Bruce Tonkin's response. He argued that what was being understood on face value was not the same as the written text and that there would have to be sound communication on this point.
The critical issue is egregious registrations.
Louis Touton said that it seemed to presume that the reason it went on register hold was because of an e-mail address.
Marilyn Cade said that the task force had not assumed e-mail, but had assumed when the registrar did not get a response.
Who is responsible for accurate data, the registrar or the registrant?
Louis Touton stated that the obligation of accuracy and updating has to do with all elements of WHOIS data whatever it is that it requires.
As described in a note about the 15 days there can be different consequences in terms of different registrar enforcement.
The registrant is responsible for updating their data even as trivial as zip codes, phone numbers, fax etc. Alternatively, the registrar has the authority to put on registrar hold or delete if the registrant refuses to fix something.

Louis Touton commenting on:
4. If no response is received or no acceptable data has been provided after a time limit (to be agreed) a registrar must place a name in REGISTRAR-HOLD (or equivalent) status, until the registrant has updated the WHOIS information.
stated that the word "acceptable" should be of concern to those developing policy. The standard the registrar is supposed to be applying is the one about accuracy and reliability stated in the contract.
Further, it was stated that the registrars are correct that the contractual obligation is to use reasonable steps to get accurate data.
Ken Stubbs commented that as the registrar is responsible for assessing the situation and the solution would depend on the registrars assessment as to how egregious the registration is, the registrars' attention should be drawn to this in a preamble and it would solve issues the registrars have with the report.

Louis Touton expressed two more concerns about section B and proposed sending a text that would address these.
1. the repeated use of the word "must" is in contrast to the purpose that is recommendations to registrars. "Should" would give less resistance.
2. If viewed as recommendations to registrars, it would be useful and important to have a clear statement informing registrars that it is not necessarily true that the following these practices will comply with the registrar's obligations under the registrar agreement.


section 3:
Input received both from the implementation committee and in public comments indicates a strong desire in parts of the community to extend the 15 day period currently specified in section 3.7.7.2 of the RAA. The concerns expressed were based on the interpretation that the 15 day period was mandatory.
Communication received from ICANN's General Counsel indicates that the "current contractual structure of requiring the registrar to retain the right to cancel if the customer fails to respond in 15 days, but not requiring the registrar to exercise this right is intended to give the registrar the flexibility to use good judgment to determine what action should be taken upon a customer's failure to respond to an inquiry about a Whois inaccuracy." This interpretation of the contractual language seems to address the concerns raised.

Added language:
"given the flexibility provided, the task force is not making a policy recommendation on this issue"

Section D.
ICANN should modify and supplement its May 10, 2002 registrar advisory as follows:
ICANN should remind registrars that "willful provision of inaccurate or unreliable information" is a material breach of the registration agreement, without regard to any failure to respond to a registrar inquiry. A functional definition -- based on the actual usability of contact details -- should be used for “inaccurate or unreliable”.
(mostly deleted and replaced by recommendation B above)ICANN should clearly state to registrars that "accepting unverified 'corrected' data from a registrant that has already deliberately provided incorrect data is not [not "may not be," as the advisory now states] appropriate.

Louis Touton commented that the paragraph was directed at having to verify the data, but the registrar could accept the registrants explanation even without verifying the data.
The changed language:
ICANN should clearly state to registrars that "accepting unverified 'corrected' data from a registrant that has already deliberately provided incorrect data generally is not [not "may not be," as the advisory now states] appropriate."

The task force agreed that the rest of the section D be deleted.

Section E
2. Registrars should also be responsible for ensuring that their agents provide such reminders.

Marilyn Cade proposed the following change:
Registrars should also notify their agents that they should provide such reminders.

The remaining section was accepted.

The Review Process
Louis Touton asked what the task force was trying to gain, to which Marilyn Cade replied that the registrars and others had felt there should be ongoing feedback.
Louis Touton said that it should be thought out in terms of support for the policy development process. Requesting staff support for the policy development process in the GNSO. Rather than structuring so much, it should be said that the GNSO Council requests that ICANN staff provides reports at 3, 6, 12 months on these points and depending on the analysis of the situation after 12 months the GNSO Council will consider whether further reports are required.
Marilyn Cade suggested wording:
GNSO Council will advise the ICANN staff of communicating any additional needed support.
Louis Touton noted that Bret Fausett's comment had not been corrected as should have been done.

4. Registrars should be encouraged to develop, in consultation with other interested parties, “best practices” concerning the “reasonable efforts” which should be undertaken to investigate reported inaccuracies in contact data (RAA Section 3.7.8).
"Best practices" was discussed and Becky Burr said there were two options:
- making it mandatory, so changing the term
- making it voluntary so leaving the present term.

Becky Burr concurred with "best practices", and Marilyn Cade explained that it was seeking self-governance among the registrars.


Recommendations
1. Consensus Policies: Accuracy of WHOIS Data.
These two policies match the alternative wording proposed in the Implementation Committee's report, sections 1 and 2, which was accepted by the WHOIS Task Force.
A. At least annually, a registrar must present to the Registrant the current WHOIS information, and remind the registrant that provision of false WHOIS information can be grounds for cancellation of their domain name registration. Registrants must review their WHOIS data, and make any corrections.
B. When registrations are deleted on the basis of submission of false contact data or non-response to registrar inquiries, the redemption grace period -- once implemented -- should be applied. However, the redeemed domain name should be placed in registrar hold status until the registrant has provided updated WHOIS information to the registrar-of-record. The Task Force observes that the purpose of this policy is to make sure that the redemption process cannot be used as a tool to bypass registrar's contact correction process.

Thomas Roessler asked Louis Touton for alternate wording which would clearly state that these recommendations were not mandatory but are both consensus policy and requested advice to ICANN and registrars.
Louis Touton commented that a clear mark should be made between consensus policy that will be binding on parties contracting to ICANN and what is not intended in that light.
Commenting on part 2 section 1, Louis Touton said that it was an implementation comment. It was framed in a way that presumes a specific kind of implementation change to the language of the registrars Accreditation Agreement. Changing the language of the Registrars Accreditation Agreement would literally take ICANN 5 years to implement because of the 5 year cycle of the RAA and the inability legally to require registrars to enter into new RAAs during the term of those.
What is meant is that the obligations expressed in the RAA should be modified to what is described and there should not be an opinion expressed as to how that should be done.
Express the idea that what is being recommended is consensus policy and that registrar agreements should be adjusted in this way, but how it should be done should be left to the ICANN Staff.

A. Use of bulk access WHOIS data for marketing should not be permitted. The Task Force therefore recommends that the relevant provisions of the RAA be modified or deleted to eliminate the use of bulk access WHOIS data for marketing purposes.
Section 3.3.6.3 of the RAA should be changed to read as follows (changed language underlined): "Registrar's access agreement shall require the third party to agree
Added language:
Use of bulk access WHOIS data for marketing should not be permitted. The Task Force therefore recommends that the obligations contained in the relevant provisions of the RAA be modified to eliminate the use of bulk access WHOIS data for marketing purposes. The obligation currently expressed in section 3.3.6.3 of the RAA could, for instance, be changed to read as follows

The bulk-access provision contained in 3.3.6.6 of the RAA would then become inapplicable.

Section 3.3.6.5 of the Registrar Accreditation Agreement currently describes an optional clause of registrars' bulk access agreements, which disallows further resale or redistribution of bulk WHOIS data by data users.
The use of this clause shall be made mandatory.

Thomas made changes to the Input section

Marilyn Cade mentioned the European Commission and working group and Louis Touton stated that it was important to proceed in a way that is respectful of the constraints they have to operate in. Acknowledging their contribution was important.

The meeting ended at 19:30 (CET)

Steve Metalitz and Ken Stubbs left the call for a short interval 17:55(CET)
Steve Metalitz rejoined the call at 18:00, (CET)
Louis Touton and Anne-Rachel Inne joined the call at 18:10 (CET)