ICANN ICANN Email List Archives

[gnso-dow123]


<<< Chronological Index >>>    <<< Thread Index >>>

[gnso-dow123] Whois task force Revised draft minutes v2, 3 May 2005]

  • To: gnso-dow123@xxxxxxxxxxxxxx
  • Subject: [gnso-dow123] Whois task force Revised draft minutes v2, 3 May 2005]
  • From: Glen De Saint Géry <glen@xxxxxxxxx>
  • Date: Wed, 11 May 2005 23:29:22 +0200

[To: gnso-dow123[at]gnso.icann.org]

Please find yet another revised draft minutes v2 with 3 references to the OECD report mentioned by Steve Metalitz
1. http://www.icann.org/bucharest/captioning-early-morning-28jun02.htm#DavidSmall
2. http://www.oecd.org/dataoecd/27/6/1938353.pdf
3. http://www.oecd.org/dataoecd/46/53/2074621.pdf


Thank you.
Kind regards,

Glen
--
Glen de Saint Géry
GNSO Secretariat - ICANN
gnso.secretariat[at]gnso.icann.org
http://gnso.icann.org


<!--#set var="bartitle" value="WHOIS Task Forces 1 2 3 teleconference 
minutes"-->
<!--#set var="pagetitle" value="WHOIS Task Force 1 2 3 teleconference 
minutes"-->
<!--#set var="pagedate" value="3 May 2005" value=""-->
<!--#set var="bgcell" value="#ffffff"-->
<!--#include virtual="/header.shtml"-->
<!--#exec cmd="/usr/bin/perl /etc/gnso/menu.pl 'WHOIS Task Force 1 2 3 
teleconference minutes'"-->
<h4 align="center"><font face="Arial, Helvetica, sans-serif"><b>WHOIS Task 
Forces 
  1 2 3<br>
  <br>
 3 May 2005 - Minutes</b></font></h4>
<p><font face="Arial, Helvetica, sans-serif"><b>ATTENDEES:<br>
GNSO Constituency representatives:<br>
  </b> Jordyn Buchanan - Co-Chair<br>
  Registrars constituency - Tim Ruiz <br>
  Registrars constituency - Ross Rader   <br>
  Registrars constituency - Tom Keller <br>
Internet Service and Connectivity Providers constituency - Greg Ruth  <br>
  gTLD Registries constituency - Ken Stubbs <br>
Non Commercial Users Constituency - Kathy Kleiman <br>
Commercial and Business Users Constituency - David Fares<b><br>
</b>Commercial and Business Users Constituency - Sarah Deutsch <br>
  Intellectual Property Interests 
  Constituency - Steve Metalitz<br>
  Intellectual Property Interests Constituency - Niklas Lagergren <br>
  Non Commercial Users Constituency - Milton Mueller  <br>
  Non Commercial Users Constituency - Kathy Kleiman<br>
  Non Commercial Users Constituency - Frannie Wellings   <br>
  </font><font face="Arial, Helvetica, sans-serif"><br>
  <strong>Liaisons</strong><br>
  At-Large Advisory Committee (ALAC) liaisons - Bret Fausett - absent - 
apologies <br>
  At-Large Advisory Committee (ALAC) liaisons - Wendy Seltzer</font> <font 
face="Arial, Helvetica, sans-serif">  - absent  - apologies <br>
  <br>
  <b>ICANN Staff</b>: <br>
  Maria Farrell Farrell - ICANN GNSO Policy Officer<br>
  <br>
  <b>GNSO Secretariat </b>-  Glen 
  de Saint G&eacute;ry <br>
  <br>
  <b>Absent:</b><br>
  Commercial and Business Users constituency - Marilyn Cade - apologies <br>
  Internet Service and Connectivity Providers constituency - Tony Harris <b><br>
  </b>gTLD Registries constituency - David Maher   - apologies <br>
  Registrars constituency - Paul Stahura  <br>
  Non Commercial Users Constituency 
  - Marc Schneiders<br>
  Internet Service and Connectivity Providers constituency - Maggie Mansourkia 
<br>
</font> <font face="Arial, Helvetica, sans-serif"></font><font face="Arial, 
Helvetica, sans-serif">  </font> <font face="Arial, Helvetica, sans-serif"><br>
  </font> <font face="Arial, Helvetica, sans-serif"><br>
  </font>  
    
  <font face="Arial, Helvetica, sans-serif"><a 
href="http://gnso-audio.icann.org/WHOIS-20050503-tf123.mp3";>MP 3 Recording</a> 
<br>
  <br>
  Maria Farrell's quick summary after the meeting: <br>
<a href="http://forum.icann.org/lists/gnso-dow123/msg00164.html";>Decisions and 
Actions</a></font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Jordyn Buchanan</strong> 
proposed the following <strong>agenda:</strong><br>
  1. Review progress on Recommendation 2, next steps moving forward <br>
2. Review of <a 
href="http://forum.icann.org/lists/gnso-dow123/msg00041.html";>accuracy topic 
Bruce Tonkin</a> sent to the task force list <br>
3. Tiered access for next week
<br>
<br>
<strong>1. </strong></font><strong><font face="Arial, Helvetica, 
sans-serif">Review progress on Recommendation 2,<br>
- Next steps and moving forward.</font></strong><font face="Arial, Helvetica, 
sans-serif"><br>
<br>
<strong>Jordyn Buchanan</strong> proposed continuing the work on the list so 
that when there were new terms of reference the task force would be  ready to 
take definitive action. This was not intended to delay the work in any way. <br>
<br>
<br>
<strong>Summary</strong><br>
</font><strong><font face="Arial, Helvetica, sans-serif">The substance of this 
work item was not discussed on the call. Work on revised drafts will continue 
on the Whois mailing list pending the new task force charter/terms of 
reference.<br>
</font></strong><strong><font face="Arial, Helvetica, sans-serif">Action<br>
</font></strong><strong><font face="Arial, Helvetica, sans-serif">* Task force 
members will continue to discuss and revise Recommendation 2 on the Whois 
mailing list. <br>
</font></strong></p>
<p><font face="Arial, Helvetica, sans-serif">2.</font> <font face="Arial, 
Helvetica, sans-serif">Review of <a 
href="http://forum.icann.org/lists/gnso-dow123/msg00041.html";>accuracy topic 
Bruce Tonkin</a> sent to the task force list<br>
Roll call of Cape Town participants &ndash; Ross Rader, Tom Keller, Marilyn 
Cade, Bruce Tonkin, Kiyoshi Tsuru, Philip Sheppard, Ken Stubbs and Barbara 
Roseman and Glen de Saint G&eacute;ry.</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Jordyn Buchanan</strong> 
briefly summarised <a 
href="http://forum.icann.org/lists/gnso-dow123/msg00041.html";>Bruce Tonkin's 
notes</a> <br>
General themes:<br>
Verification of data at registration
<br>
</font><font face="Arial, Helvetica, sans-serif"> Some members of the ICANN 
community would like registrars to proactively verify the accuracy of 
information  at the time of registration,  registrars felt strongly that it 
would be difficult and costly.This resulted in the  focus moving to contacting 
the registrant which was difficult because of  inaccurate Whois 
information.<br> 
A complaint based approach to address the issues was favoured. A registrar 
would attempt to contact a registrant if there were a complaint about 
inaccurate Whois data, if there were no response within 15 days, the name would 
be put on hold,  the registrant would be given another 15 days at the end of 
which the name would be cancelled. </font></p>
<p><font face="Arial, Helvetica, sans-serif"> Intellectual Property 
infringement<br> 
Because there might be some short term or ongoing harm  a 15 to 30 day process 
would not be helpful, and there may be a need for a procedure like notice and 
take down of the name as in the US DMCA approach. However this was considered 
outside of the scope of the task force and ICANN. </font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Ross Rader </strong>added 
that a lot of time was spent talking about the business process itself which 
was unfortunately not noted. The  focuses on the business process was not on 
what the community did, but rather each stakeholder said what they needed from 
the process.<br>
    <br>
    <strong>Summary
    <br>
2 Review of accuracy topic<br>
    </strong></font><strong><font face="Arial, Helvetica, sans-serif">Jordyn 
re-capped Bruce Tonkin&rsquo;s note on the Capetown discussions as a starting 
point for the call. The procedure outlined in Bruce&rsquo;s notes focused on a 
complaint-initiated process for checking accuracy of Whois information. 
Bruce&rsquo;s notes also mentioned the possibility of fast-track procedures - 
similar to notice and takedown in the US DMCA - but this was seen as outside 
the scope of the task force and of ICANN.</font></strong></p>
<p></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Jordyn Buchanan</strong> 
proposed that the  registrar representatives comment on their company or 
industry practices on inaccuracy complaints.<br>
  <br>
    <strong>Ross Rader</strong> said the Tucows process was simple and 
commented on . com . net and .org. <br>
&quot;
The process is generic across the TLDs. When a notice of inaccuracy  is 
received  through the Whois problem reporting system, email or phone, it is 
sent to the  compliance department team whose job it is to ensure that not only 
 resellers operate within the contracts but also the registrants. They are a 
reactive group who mostly deal with UDRP issues, phishing, spamming etc. Any 
issue with a domain usually  ends up with them. An issue is examined on face 
value,  an email notice describing the alleged inaccuracy that was put forward 
to us will be sent out  to the registrant contact &ndash; technical and billing 
and administrative &ndash; that outlines the penalties for not providing 
accurate data. The expected response is that the registrant responds with the 
accurate data and there should be a response within 15 days. If there is no 
response during that period of time  the name is put on &lsquo;registry 
hold&rsquo;. This prevents the registrant from using their name till the 
inaccuracy is corrected or until the name expires. A letter is again sent to 
the address while the name is on hold and ultimately if there is no response,  
the name the name is expired.<br>
Responding to questions from Jordyn: <br>
This is not natural expiration but deletion of the name.<br>
</font><font face="Arial, Helvetica, sans-serif">When   additional information 
is received, it is not validated. The compliance team is extremely reactive and 
deals with issues in the following order,  accuracy, udrp and transfer issues. 
</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Milton Mueller</strong> 
asked whether in the case of accuracy complaints, do you as a registrar ever 
have trouble contacting the registrant for billing?<br>
  <br>
  <strong>Ross Rader</strong> &ndash; yes, the model is very disintermediated 
and there is little information collected about the clients there is the  same 
exposure to inaccuracy issues as anyone else using the Whois data system. There 
is no credit card number on file for the clients, intermediaries are relied on 
for that information. Only keep the required information. One thing they were  
diligent about was tracking bounces when notices were sent out so as to have 
the best chances of collect money so accuracy was taken quite seriously.<br>
In response to Milton Mueller, Ross did not know how many times Tucows had 
taken down names because of inaccuracy but could find out.<br>
<strong>Milton Mueller</strong>, speaking from a constituency perspective, felt 
that it was  not worth addressing accuracy issues until the privacy issues were 
addressed and wanted to know whether this was a factor in inaccurate data.<br> 
Ross Rader agreed with him,  &quot;as someone who regularly has bad data in his 
Whois records and does not want to be called at home  because of the 4 million 
people he serves, I can relate to the privacy concerns.&quot;</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Kathy Kleiman</strong> 
asked when a registrant submitted revised information, could they ask the 
Tucows team not to publish that on the website?</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Ross Rader</strong> 
responded that Tucows did not provide a privacy product.</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Steve Metalitz</strong> 
asked whether &lsquo;registry hold&rsquo;,  had the same meaning as when  Bruce 
Tonkin said &lsquo;the name is on hold and that is removed from the zone file 
and made inactive &rsquo;?</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Ross Rader</strong> 
answered yes,</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Jordyn Buchanan</strong> 
added that both in EPP and RRP there was technical flag that could be set on a 
domain name that left it in the registry data base but not in the zone 
file.</font> </p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Tim  Ruiz 
</strong>commented that Godaddy  handled things very similarly. The way the 
registrant or admin contact was  contacted was perhaps different as Godaddy 
started out with email and if that failed,   used the phone or other means but 
seldom if ever was anything sent to a postal address. According to the RAA if 
there was no response after 15 days the registrar had the option to delete the 
name, while Godaddy put the name on hold if there was no response after 10 
days. If nothing was heard from the registrant after  a  reasonable time 
period,  the name would then be deleted.</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Steve Metalitz</strong> 
asked whether new data received  was checked?<br>
<strong>Tim Ruiz</strong> responded that the client is told it takes 24 hours 
to validate the data but in fact if  it looks reasonable, addresses the 
complaint &ndash; i.e. if a new phone number was asked for, the phone number is 
not necessarily checked. If no information comes back,  the registrant is 
informed that they  have a chance to respond.<br>
<strong>Steve Metalitz</strong> asked what would happen if a non-responsive 
response came through in the first 10 days.<br>
<strong>Tim Ruiz</strong> responded that he did not know and imagined that  the 
clock would just keep ticking.<br>
 In response to a question from <strong>Kathy Kleiman</strong> on the amount of 
names deleted  for accuracy issues, <strong>Tim Ruiz</strong> responded that he 
did not know. He  had asked ICANN, when the they do the (WDPRS) Whois Data 
Problem Report System, to provide specific reports to each registrar so they 
could analyse their performance individually and compare it with what  ICANN 
was seeing  so they could see if it matched up internally and if they could 
improve. The overall report was not so  useful.<br>
 <br>
 <strong>Ken Stubbs</strong> commented that it was important to look at the 
magnitude of inaccurate data  before any process was set up.<br>
 <strong>Tim Ruiz</strong> went on to say that in Godaddy it was handled in the 
fraud department that dealt  with stolen credit cards,  etc. and not through 
the compliance team.</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Jordyn  Buchanan</strong> 
asked <strong>Maria  Farrell</strong> to enquire  about the numbers and 
outcomes in ICANN's (WDPRS) Whois Data Problem Report System.<br>
  <br>
  <strong>Tom Keller </strong>explained that  Schlund's, compliance problem was 
 very similar to Tucows and Register.com. Whatever information came in was 
dealt with and if there was no new information, the domain name would be put on 
registrar hold until the domain name had expired and then it would be deleted. 
They received one or two ICANN reports a month but apart from those they had no 
 outside complaints about the accuracy of the data.<br>
  <br>
</font><font face="Arial, Helvetica, sans-serif"><strong>Jordyn  Buchanan 
</strong>speaking for Register.com and not as the task force chair commented 
that in relation to the  2.5 million names handled by his company there was  
not even one accuracy complaint a day. It was a fraction of a hundredth of a 
percent during any given year. <br>
<strong>Jordyn Buchanan</strong> felt that the current information matched what 
<strong>Bruce Tonkin</strong> has ascertained and asked  how registrars' 
current procedures were not meeting the needs of various constituencies and 
whether there were any specific suggestions for procedures.</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Steve Metalitz 
</strong>mentioned 3 issues:  <br>
1. There was some discussion within task force three that there should be some 
standard contact points in the registrar to report bad data. <br>
2. 
What was done when  a response was received from the registrant? Was there any 
vetting of the response to see if it responded to the question and if it was 
accurate?<br>

Tim Ruiz indicated that there was a quick look at the new data, while Ross 
Rader said that Tucows did not look at it.  It was  a documented problem that 
had been going on for a few years that registrants provided new false data,  
and there should be a policy to address it. Further Steve Metalitz felt that 
If the volume of complaints were as low as Jordyn Buchanan and Tom Keller had 
described, then it should not be a great burden for registrars to check the 
data when it came in. <br>
3. This did not rule out a registrar agreeing to a faster procedure, a fast 
track procedure, in certain circumstances but the issues of authenticating or 
validating the new data remained.<br>
<br>
<strong>Tim Ruiz</strong> made the point that being able to contact someone was 
far more accurate to his company than how accurate the data might look. There 
was no guarantee that the data identified the individual, but someone could be 
contacted. </font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Ross Rader</strong> 
cautioned about  rehashing 18 months of discussion and putting too much stock 
in the number of contact points the registrar should validate for a name.    
Contactability should be stressed and not the amount of accurate data in the 
record. If the person was contactable the objective had been achieved. 
Registrars had a high degree of discretion about what they could do with names, 
and would always have the right to implement fast-track if  needed. Thus 
spelling out the fast track process was a waste of time. Issues such as 
ensuring the security and stability and meeting the legal frameworks should be 
emphasized rather than defining every aspect of the business.<br> 
    <strong>Steve Metalitz</strong>  pointed to the OECD presentation in 
Bucharest as documentation on the  revalidation problem as well as anecdotal 
cases.<br>
  <strong><br>
  Ross Rader</strong> felt that the current capability allowed registrars to do 
a lot of things which they often did not often use thus to create policy to 
deal with boundary cases was not useful for the task force.</font><font 
face="Arial, Helvetica, sans-serif"><br>
    <strong><br>
    Steve Metalitz </strong>explained  his concern  about the importance of 
contact points in situations where people were contactable but were not <br>
being  contacted because the registrar had only tried one email or from the 
point of a registrant, where the email address  no longer responded but the 
phone number was still good. </font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Jordyn Buchanan</strong> 
proposed pursing two topics:<br>
  - 
</font><font face="Arial, Helvetica, sans-serif"> whether there should be a 
standard for which or how many contacts used before deleting or putting a name 
on hold,<br>
- 
whether there should be a process for validating responses to requests for 
updated data. </font> </p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Ross Rader</strong> added 
the issue of creating a mandatory  standardized reporting systems 
(WDPRS).</font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Jordyn Buchanan</strong> 
proposed combining Ross Rader's and Steve Metalitz's  suggestions to provide a  
streamlined response to accuracy problems.</font></p>
<p><strong><font face="Arial, Helvetica, sans-serif">Milton Mueller 
</font></strong><font face="Arial, Helvetica, sans-serif">commented that 
</font><font face="Arial, Helvetica, sans-serif"> there was a certain quality 
of unreality about these detailed discussions on accuracy. It made no sense to 
go further than the task force had on accuracy without addressing the data 
access privacy considerations.Some people did not want to address the 
considerations but one of the causes of inaccuracy was that people did not want 
to put their data out there. So it did not&rsquo;t make sense to put time, 
policy and registrar resources into improving accuracy. So people who are most 
concerned about accuracy d need to accept that fact and work together to deal 
with the privacy problems. Milton went on to say that once privacy concerns 
were dealt with the NCUC would be very willing to work with other 
constituencies to address accuracy issues. Until privacy was treated as a 
priority he was against any detailed discussions or proposals regarding 
accuracy.<br>
  <br>
</font><font face="Arial, Helvetica, sans-serif"><strong>Jordyn 
Buchanan</strong> in summary:<br>
  - reminded the task force that there would be new terms of reference<br>
  - accuracy  - to focus on developing a standardized procedure for reacting to 
complaints about data, <br>
- 
reviewing whether there should be requirements in terms of registrars making 
attempts to contact a certain number or specific set of contact points 
available, <br>
- 
whether upon receiving a response with new whois data there should be a 
standard way to validate the data before reinserting it into the Whois record. 
<br>
<br>
<strong>Summary:<br>
</strong></font><strong><font face="Arial, Helvetica, sans-serif">Ross Rader, 
Tim Ruiz and Tom Keller outlined their companies&rsquo; procedures for 
responding to complaints of inaccurate Whois data and answered questions. TF 
members identified areas in which current practices and policies may need 
revision<br>
<br>
Points agreed:<br>
The possibility for an external fast-track procedure &ndash; i.e. within the 
national law context and in cases where harm would be done during the 2 x 15 
day accuracy checking process - should not be prevented by TF policy 
recommendations </font></strong></p>
<p><strong><font face="Arial, Helvetica, sans-serif">Task force members will 
explore standardized procedures for:<br>
&Oslash; The number and type of registrant contact details used to pursue 
inaccuracy complaints before a name is put on hold or deleted,<br>
&Oslash; Validating responses to requests for updated data,<br>
&Oslash; Directing all accuracy-related complaints to the ICANN Whois data 
reporting system.<br>
<br>
Actions:</font></strong></p>
<p><strong><font face="Arial, Helvetica, sans-serif"> * Ross Rader and Tim Ruiz 
to try and find information about the number of deleted names arising from 
inaccurate Whois information.<br>
  * Maria Farrell to provide information on the Whois data reporting process, 
i.e. numbers of complaints and outcomes. <br>
  * Ross Rader and Steve Metalitz to draft language on standardized procedures 
and circulate to the list. </font></strong><font face="Arial, Helvetica, 
sans-serif"><br>
      <br>
      <strong><br>
  3. Next week&rsquo;s topic - tiered access<br>
  Tuesday 10 May<br>
  <br>
  Actions:</strong></font></p>
<p><strong><font face="Arial, Helvetica, sans-serif"> * Task force members are 
encouraged to submit ideas on accuracy to the list to help next week&rsquo;s 
discussion.<br>
  * Jordyn will review previous Task Force 1 work and forward any relevant 
information to the list. </font></strong></p>
<p> <br>
<font face="Arial, Helvetica, sans-serif"><strong>Jordyn Buchanan</strong> 
thanked everyone for their participation and the call ended at 16:30 </font> 
</p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p>&nbsp;</p>
<h1>&nbsp;</h1>
<p>&nbsp;</p>
<p align="center">&nbsp;</p>
<p>&nbsp;</p>



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy