ATTENDEES:
Co-chair -Tony Harris
Co-chair - Marilyn Cade
gTLD Registries - J. Beckwith Burr
IPIC - Steve - Metalitz

IPIC - Laurance Djolakian
NCUC - Ruchika Agrawal
( Former GA Chair) - Thomas Roessler
(Former GA - representative) - Kristy McKee
(Former GA - representative) - Abel Wisman

GNSO Secretariat - Glen de Saint Géry

Marilyn Cade proposed the following agenda:
Discussion of additional input:
- Implementation committee report
- contribution from the European Commission Internal Market.
Report on the conversation with Bruce Tonkin
Issues report

Marilyn Cade reported that:
- the Policy Development Process (PDP) required a 20 day comment period on the final report but there was no clarity whether this process would be followed or whether previous comment periods had been adequate.
Bruce Tonkin suggested that areas needing further comment should be selected and treated apart, allowing the bulk of the report to move forward and be voted on at the GNSO Council teleconference, February 20, 2003.
- The PDP further required Impact statements by the constituencies, but again there was no clarity whether this document fell under the PDP guidelines. This should be verified with the ICANN staff.
Bruce Tonkin felt that this should be the responsibility of each constituency.


- Implementation committee report
http://www.dnso.org/clubpublic/nc-whois/Arc00/msg00856.html
Steve metalitz commented that the draft implementation committee report was near to the Final report and the task force could draft a report in parallel.
In general the implementation committee changes can be accepted.

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." Accordingly, where registrars send inquiries to registrants in this situation, they should require not only that registrants respond to inquiries within 15 days but that the response be accompanied by documentary proof of the accuracy of the "corrected" data submitted, and that a response lacking such documentation may be treated as a failure to respond. The specifics of acceptable documentation in this situation should be the subject of further discussions."
Alternate wording was provided by the Implementation committee, but a couple of variables should not be accepted as stated in Steve Metalitz's report.
Bulk Access and market activities called for a definition of the latter.

Discussion that followed, Tony Harris, pointed to the fact that the registrars were not doing very much to validate data. There had been no discussion about when a domain name is registered, there is a means of payment, usually by credit card and so the data is checked by means of the credit card, at that point. Before the domain name is given, proof should be given and the data would be validated
Marilyn Cade expressed disappointment at the lack of enthusiasm among the registrars for responsibility of accuracy.
Steve Metalitz commented that there were 4 situations:
1. - At the time of registration; there was no consensus in the task force group that it be recommended to change the information at the time of registration.
2. - At the time of renewal, where the WHOIS information should be reviewed. Some of the registrars did not want to be in a system that depended on humans, but wanted it automated.
3. - After a complaint was received; much of the discussion was directed to this situation. The registrars agreed that there should be steps for juristic automated data validation techniques, possibly via automated tools provided by ICANN to check that the new WHOIS information is plausible.
4. - Complaint has been received, request has gone out and after days there has been no response, the registration goes on registrar hold, then how does the name get back into the system.
The question is at what point should a human be involved? The implementation committee seemed to opt for nowhere, while the task force maintained that it should be in situation 3.

Marilyn Cade mentioned that the Deletions Task force has paragraphs that the WHOIS task force needs to address and read from:
ISSUE #2: Deletion following a complaint on WHOIS accuracy
In most respects, a name deleted for reasons relating to inaccuracy of Whois data is treated identically to a name deleted for any other reason. However, it is important to prevent registrants from using the Redemption Grace Period to simply reinstate names once they have been deleted, without providing accurate Whois information. In order to prevent this, the task force recommends that registrars require that registrants of such names provide new, verified Whois information. This new data should be provided as part of the documentation to the registry in conjunction with the request for the name's redemption.
Steve Metalitz asked what new verified data meant, to which Marilyn Cade said that verified meant some substantiation, and Thomas Roessler said the the individual processes to verify data should be considered.
The registrars concern about checks in the process related to cost issues.
Marilyn Cade asked to identify the areas where the task force feels that the implementation group does not support the task force recommendations.
A testbed for implementing the recommendations was not thought to be feasible.
The volume of complaints about inaccurate data was presented by Dan Halloran in Shanghai and proved to be well distributed over all the registrars. These complaints, as in the case of .ca, are eyeballed. Thomas Roessler added that an automatic mechanism could be misused.
Steve Metalitz referred to paragraph( a )in the implementation report that reads:
"should include a field in which the complainant is asked to provide a brief justification for or evidence in support of the complaint. "
Marilyn Cade commented on the form required to be filled in when data is in accurate and said the reports on inaccuracy should go to ICANN and then the registrars.
Kristy McKee commented that the form sent to ICANN could include basic validation mechanisms and that an ID number could be assigned to the name.
Steve Metalitz said that ICANN looking at a complaint first, was not spelled out in the protocol.
Thomas Roessler referred to the recommendation and said that it would perhaps have to be reviewed
3.ICANN should post registrar contact points on its web site (perhaps on the list of accredited registrars).
Marilyn Cade said that for a period of time we would like to ensure that the complaint goes through ICANN where they are then redistributed to the appropriate registrar and that ICANN gathers a limited amount of statistics on the complaints that are received; where the volume is and whether they are getting a high number of spurious complaints. ICANN would do as they do at present, eyeball the complaints, send them to the appropriate registrar to follow up on and keep track if the registrar reports back to them.
Discussion around the reporting back the form should include a simple automated mechanism for the registrar to report back to ICANN on the outcome of the complaints.
Thomas Roessler said the current text provided registrars with an opportunity and does not contain an obligation for them to make use of that.
Steve Metalitz drew the attention to the fact that the registrars consider it the registrant's obligation to provide accurate data.

Marilyn Cade suggested:
- Steve Metalitz get Louis Touton and Dan Halloran to confirm the registrars contractual obligations and - get an update on Dan Halloran's Shanghai report.
- a discussion with ICANN staff on the section of the recommendations affecting ICANN staff.

Bulk Access recommendations:

Steve Metalitz reported that the implementation committee looked at the first recommendation, agreed with the language and agreed that the Registrars Accreditation Agreement should be changed.
In addition The Implementation Committee concluded that "there is a need to clarify the definition of "marketing purposes". This may require a small working group to define, possibly just in the form of examples (but not limited to) of marketing activities covered."
The Task Force agrees with this observation.
Marilyn Cade went on to comment about Port 43 access and said that datamining is targeted at port 43 and other automated port facilities through individual agreements registrars may strike. This bypasses the intent of limiting marketing uses of bulk access. The implementation committee did not address this.
The question: Is the task force able to modify the recommendation or make a new recommendation that addresses the need to limit port 43 access for non-authorized uses such as marketing?
Steve Metalitz mentioned two issues to be explored:
- technological means to minimize the problem
- on web based WHOIS there are contractual limitations
Kristy McKee that the task force should support security layers around port 43 and differentiated access.
Thomas Roessler said the key issue was how to avoid bulk access through port 43 that is freely available to anyone.
Steve Metalitz suggested supporting the Security Advisory committee recommendation that encourages the development of mechanisms to prevent the harvesting and mining of WHOIS data.

Tony Harris and Marilyn Cade referred to the European Commission document from the Internal Market, commenting on the WHOIS task force report.
Tony Harris commented that the report found bulk access unacceptable, supported the task force on accuracy, detailing access and raised questions about uniformity.
The commission suggested a meeting with the WHOIS task force.

European Commission report, Page 3, bullet point 2
Concerning the final conclusions of the report, the Commission wishes to state its support for the proposals concerning accuracy of the data (which is also one of the principles of the European Data Protection Directive) and limitation of bulk access for direct marketing issues. We would like to point out however that the new electronic communications directive (Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications). includes provisions imposing opt-in for unsolicited commercial e-mail which are relevant for the discussion on bulk access. Any bulk access to e-mail addresses for direct marketing must be based on opt-in only. Offering an opt-out will not be enough in the light of this new directive. Furthermore, concerning the general issue of bulk access, the commission would like to stress the fact that bulk access, for any purpose (not only for direct marketing), is in principle unacceptable.

Steve Metalitz made two comments
- that the directive is the child of the Information Society directive, not of the Internal Market
- that is it a mistake to to conclude that it represents the view of the Internal Market Directory, as it probably represents the view of a staff person.
Marilyn Cade suggested a separate consultation with the Information Society about their directive.
Highlighted passages:

Again under European law, the initial purpose for which the data is collected is the test. This clearly does not include the private policing of content. Accordingly, if rights holders wish to control that only "authorized" persons are using their works and thus discourage on-line privacy through Whois queries, then that would require a distinct legal base, at least in the European Union.

The publication of the private telephone number of individuals would be a problem for several data protection authorities.

Marilyn Cade suggested:
- asking ICANN staff on how to respond.
- clarify the status of the document
- inviting Louis Touton to join the next call
- prepare a dialogue, questions and explanations
- take into account the input of the paper

Thomas Roessler commented on changes made to the Final Report:
- changes to the period open for comment
- Chapter 12 (a) task force members (b) Comments received

Should changes be made throughout the text or should there be a new document with final recommendations?

A document with updated policy recommendations was suggested, maintaining the non policy recommendations.
Aim to have a limited number of pages stating the recommendations which is easily readable.

Form of the Final Report (reverse chronological order)
- Updated recommendations
- Implementation Committee report
(a) policy
(b) good advice
- Comments
- Policy recommendations
- Policy recommendations to ICANN

Areas not clear:
Thomas Roessler suggested:
section 3 (e) where there are reservations recommend that the process of the implementation committee be accepted on condition that they are monitored by ICANN during a certain period for affectivity and negative side effects.
Steve Metalitz proposed guidelines until the future Dispute resolution policy was in place

Marilyn Cade mentioned the 15 day period where she has been led to believe if the task force goes ahead with it, the report will not be voted.
Decision: undertake discussion on line.

Privacy Issues, lack of significant input, send comments to Ruchika Agrawal.
Issue Reports to be in for Rio de Janeiro meeting
Marilyn Cade and Antonio Harris thanked the participants for their contributions.

Call ended: 4:00 PM EST, 19:00 CET

Next Call: Friday January 31, 2003 - 2:00 PM EST.