[gnso-dow123] Whois task force Revised draft minutes v2, 3 May 2005]
[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é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 – Ross Rader, Tom Keller, Marilyn
Cade, Bruce Tonkin, Kiyoshi Tsuru, Philip Sheppard, Ken Stubbs and Barbara
Roseman and Glen de Saint Gé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’s note on the Capetown discussions as a starting
point for the call. The procedure outlined in Bruce’s notes focused on a
complaint-initiated process for checking accuracy of Whois information.
Bruce’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>
"
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 – technical and billing
and administrative – 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 ‘registry
hold’. 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> – 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, "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."</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 ‘registry hold’, had the same meaning as when Bruce
Tonkin said ‘the name is on hold and that is removed from the zone file
and made inactive ’?</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 – 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’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’ 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 – 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>
Ø The number and type of registrant contact details used to pursue
inaccuracy complaints before a name is put on hold or deleted,<br>
Ø Validating responses to requests for updated data,<br>
Ø 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’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’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> </p>
<h1> </h1>
<p> </p>
<p align="center"> </p>
<p> </p>
|