[dow3tf] Whois tf 3 Draft notes 22 September 2004 teleconf

["GNSO SECRETARIAT" <gnso.secretariat@xxxxxxxxxxxxxx>]

[To: dow3tf[at]gnso.icann.org]

Please find the draft notes/minutes attached from the last teleconference
held on 22 September. May these give rise to discussion on the list in
preparation for the Wednesday 29 September 2004 teleconference.

GNSO Secretariat


<!--#set var="bartitle" value="WHOIS Task Force 3 minutes"-->
<!--#set var="pagetitle" value="WHOIS Task Force 3 minutes"-->
<!--#set var="22 September 2004" value=""-->
<!--#set var="bgcell" value="#ffffff"-->
<!--#include virtual="/header.shtml"-->
<!--#exec cmd="/usr/bin/perl /etc/gnso/menu.pl 'WHOIS Task Force 3 minutes'"-->
<p align="center"><font face="Arial, Helvetica, sans-serif"><b>WHOIS Task Force 
  3 Teleconference September 22, 2004 - Minutes</b></font></p>
<p><b><font face="Arial, Helvetica, sans-serif">ATTENDEES:<br>
  </font></b></p>
<p><b><font face="Arial, Helvetica, sans-serif">GNSO Constituency representatives:<br>
  </font></b><font face="Arial, Helvetica, sans-serif"> Intellectual Property 
  Interests Constituency - Brian Darville - Chair:<br>
  Registrars Constituency - Ross Rader<br>
  Non Commercial Users constituency - Frannie Wellings <br>
  Internet Service Providers and connectivity providers Constituency</font> - 
  <font face="Arial, Helvetica, sans-serif">Greg Ruth</font><br>
  <font face="Arial, Helvetica, sans-serif">Government Advisory Committee (GAC) 
  liaison - </font> <font face="Arial, Helvetica, sans-serif">Suzanne Sene</font><br>
  <font face="Arial, Helvetica, sans-serif"> </font><font face="Arial, Helvetica, sans-serif"> 
  <br>
  </font><font face="Arial, Helvetica, sans-serif"><b>GNSO Secretariat:</b> Glen 
  de Saint G&eacute;ry <br>
  <br>
  <b>Absent: </b></font><br>
  <font face="Arial, Helvetica, sans-serif">gTLD Registries constituency: - Ken 
  Stubbs</font> - <font face="Arial, Helvetica, sans-serif">apologies</font><br>
  <font face="Arial, Helvetica, sans-serif">Commercial and Business Users constituency 
  - Sarah Deutsch</font> <br>
  <font face="Arial, Helvetica, sans-serif">Intellectual Property Interests Constituency 
  - Kiyoshi Tsuru<br>
  Intellectual Property Interests Constituency - Terry Clark <br>
  At-Large Advisory Committee (ALAC) liaisons: - Vittorio Bertola <br>
  <b>ICANN Staff Manager</b>: Barbara Roseman - absent - apologies <br>
  <br>
  <a href="http://gnso-audio.icann.org/WHOIS-20040922-tf3.mp3";>MP3 recording</a><br>
  </font></p>
<p><font face="Arial, Helvetica, sans-serif"><a href="http://gnso.icann.org/meetings/agenda-whoistf-22Sep04.htm";>Agenda</a><br>
  <br>
  Agenda: <br>
  Attached is a document which identifies some potential opportunities for agreement 
  between the majority and minority positions of TF3. Discussion of these and 
  other potential points of agreement. <br>
  <a href="http://gnso.icann.org/meetings/MajMinIssues_22Sep04.pdf";>Click here</a> 
  to view the document.<br>
  <br>
  <b>Brain Darville </b>referred to an <a href="http://gnso.icann.org/mailing-lists/archives/dow3tf/msg00275.html";>Bruce 
  Tonkin's emai</a>l which resulted from a conference call with Ross Rader, Steve 
  Metalitz, Brian Darville and Bruce Tonkin (in his personal capacity as a registrar), 
  the pupose being to come to an agreement regarding Whois data accuracy because 
  of split positions where registars were taking the position that they were not 
  willing to agree to any recommendations. </font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Brian Darville</b> stated there 
  was no agreement in the discussion but Bruce Tonkin put forward some ideas that 
  he as a registrar and Ross Rader as the Registrar constituency representative 
  on the task force could agree to. However, from an Intellectual Property Constituency 
  point of view Brian Darville had problems with the propositions.<br>
  Bruce Tonkin's email referred to 2 relevant clauses in the Registrar Accreditation 
  Agreement: (RAA). </font></p>
<p><font face="Arial, Helvetica, sans-serif">: "3.7.7.2 A Registered Name Holder's 
  willful provision of inaccurate or unreliable information, its willful failure 
  promptly to update information provided to Registrar, or its failure to respond 
  for over fifteen calendar days to inquiries by Registrar concerning the accuracy 
  of contact details associated with the Registered Name Holder's registration 
  shall constitute a material breach of the Registered Name Holder-registrar contract 
  and be a basis for cancellation of the Registered Name registration."<br>
  <br>
  "3.7.8 Registrar shall abide by any specifications or policies established according 
  to Section 4 requiring reasonable and commercially practicable (a) verification, 
  at the time of registration, of contact information associated with a Registered 
  Name sponsored by Registrar or (b) periodic re-verification of such information. 
  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." <br>
  <br>
  (1) With respect to verification at time of registration: <br>
  The registrars constituency would prefer to focus on improving the process for 
  dealing with complaints, because adding verification at the time of registration 
  may be a significant cost burden across all registrations, the vast majority 
  of which are for legitimate purposes and do not infringement any 3rd party IP 
  rights. Improved verification can first be implemented when WHOIS data is corrected 
  following a complaint (see (2) below). The effective of this approach can then 
  be evaluated prior to considering adding this at time of registration. <br>
  <br>
  <b>Brain Darville</b> felt that it begged the question of the purpose of the 
  task force which was to improve accuracy. Being concerned about accuracy after 
  a complaint was filed was not consistent with the requirements of the RAA.<br>
  <b>Brian Darville</b> mentioned that the task force preliminary report suggested 
  verifying 2 contact data elements while during the call verification of only 
  one data element was discussed. Brian was of the opinion that email verification 
  at the time of the registration was an obligation as Registrants were contractually 
  required to provide accurate data. <br>
  <b>Ross Rader</b> was of the opinion that verifying email at the time a domain 
  name was registered would result in a backlog in the pending queue, a regression 
  in the registrar industry and the progress made with real time registration, 
  while the economic impact on registrar sector could be millions of dollars<br>
  - customer loss<br>
  - increased costs<br>
  - decreased value of service level. </font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Frannie Wellings</b> agreed with 
  data verification after a complaint and felt it would be a wasted effort to 
  verify data at the time of registration and asked how would one differentiate 
  between a mistake and purposeful inaccurate data.<br>
  . <br>
  <b>Greg Ruth</b> commented on the validation of every registration versus complaints 
  only saying that where there were complaints time could be spent tracking them 
  down as they would be few in number but checking everyone would probably lead 
  to a perfunctory job and not serve purposes.</font><font face="Arial, Helvetica, sans-serif"> 
  </font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Ross Rader</b> requested that 
  the whole line of discussion be killed but that deferring the issue each time 
  was not satisfactory.<br>
  No decision could be taken because there were not enough people on the call. 
  <br>
  <b>Ross Rader</b> </font><font face="Arial, Helvetica, sans-serif">suggested 
  that the issues be put to the task force vote:<br>
  a. Was it a valid assumption that it was desirable policy ie, verification at 
  the time of registration<br>
  b. Is this a change that the community is willing to accept?<br>
  <br>
  (2) Reasonable steps to investigate inaccuracy <br>
  Reasonable steps can be clarified further to state that a registrar must use 
  at least one of email, phone, fax, or postal mail to notify a registrant of 
  a complaint about accuracy. If one of these methods fails (e.g receive a return 
  to sender mail, email bounces, number is disconnected, or there is no fax service 
  connected to the number) then another method must be used. If all of email, 
  phone, and fax fail, then the name should be placed on registrar HOLD (ie the 
  name decommissioned). <br>
  <br>
  <b>Brian Darville</b> suggested adding reasonable time limits.<br>
  <br>
  A registrant would still have 15 days to respond before further action is taken. 
  To correct an inaccuracy registrars (or their resellers) must verify at least 
  one of the following three data elements: - phone, Fax, or email Verification 
  would take the form of: - customer provides data - registrars contacts customer 
  using data - customer confirms registration A registrar may charge the registrant 
  to recover costs of correcting the inaccuracy and may place a name on Transfer 
  LOCK during this process. The pricing of this would be left to market forces. 
  To ensure effective measurement of the compliance with this policy, all complaints 
  should be lodged through the centralised WHOIS Data Problem Report system. Registrars 
  must close cases lodged in the system to report on how they have been resolved. 
  ICANN will be able to provide regular public reporting on the number of complaints 
  and the follow up to these complaints. <br>
  </font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Brian Darville</b> referred to 
  item 2 and suggested verifying more data elements at this point, to which Ross 
  Rader commented that there was a moderately accurate data base, every indication 
  showed that all the steps that have been taken to increase accurate data have 
  been effective and was not sure that there was the degree of inaccuracy that 
  some people presumed. The requirement/drive/need for further accuracy should 
  be identified. <br>
  <br>
  Item 2 should not be seen in isolation from item 3.<br>
  </font></p>
<p><font face="Arial, Helvetica, sans-serif">(3) Extra steps to investigate inaccuracy 
  <br>
  A complainant may pay a registrar for an extra inaccuracy investigation service. 
  A registrar in parallel will use all forms of contact to notify the customer: 
  email Phone Fax Post - via registered mail (to ensure receipt) If all forms 
  of communications fail - the name will immediately be placed on HOLD, (or redirected 
  to a notification website). The customer will have 15 days to respond. When 
  the registrant responds to update details, all of Email Phone Fax Post will 
  be individually verified. Again at the cost of the complainant. The advantage 
  of this service is it will provide a concrete set of contact details for further 
  action by a complainant. The cost of this service will initially be left to 
  market forces. <br>
  <br>
  A lengthy discussion followed about who should be responsible for paying for 
  inaccurate data</font><font face="Arial, Helvetica, sans-serif">.<br>
  <b>Brian Darville</b> was of the opinion that it was a non starter to charge 
  anybody but the registrant. <br>
  <b>Ross Rader</b> explained that there could be different models and different 
  levels of fees depending on which registrar was chosen but that the registrar 
  may not choose anybo</font><font face="Arial, Helvetica, sans-serif">dy but 
  the registrant to pay for the service was equally not acceptable</font>.<br>
  <font face="Arial, Helvetica, sans-serif"><b><br>
  Ross Rader</b> suggested that item 2 was a starting point for future compromise.</font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Brian Darville</b> suggested continuing 
  the discussion on the next task force call and encouraged task force members 
  to express their positions regarding verifying email contact data at the time 
  of registration.</font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Next week 29 September 2004</b></font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Agenda</b><br>
  Continue the discussion on the following items:</font></p>
<p><font face="Arial, Helvetica, sans-serif">1. Verification at the time of registration 
  of contact information<br>
  </font><font face="Arial, Helvetica, sans-serif">2. Reasonable steps to investigate 
  inaccuracy<br>
  - clarify timelines in the process<br>
  </font><font face="Arial, Helvetica, sans-serif">3. Extra steps to investigate 
  inaccuracy</font></p>
<p><font face="Arial, Helvetica, sans-serif"> </font><font face="Arial, Helvetica, sans-serif"><b> 
  Brian Darville thanked everyone for their presence and participation and ended 
  the call at noon EST, 16:00 UTC.<br>
  <br>
  </b> <b>Next call: Wednesday 29 September </b><b>15:30 UTC, 10:30 EST, 7:30 
  Los Angeles, 16:30 CET.<br>
  <br>
  <br>
  </b></font></p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>