[gnso-dow123] WHOIS Issues discussed at the GNSO Council meeting 2 June 2005
[To: gnso-dow123[at]gnso.icann.org] Dear All, Please find attached an extract from the draft GNSO Council minutes dealing with the 2 Items on WHOIS issues that were discussed during the GNSO Council teleconference held on 2 June 2005. The MP3 recording of the GNSO Council call may be found at: http://gnso-audio.icann.org/GNSO-Council-20050602.mp3 http://www.gnso.icann.org/calendar/#june Thank you, Kind regards, Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org <!--#set var="bartitle" value="Draft WHOIS related GNSO Council minutes"-->
<!--#set var="pagetitle" value="Draft WHOIS related GNSO Council minutes"-->
<!--#set var="pagedate" value="2 June 2005" value=""-->
<!--#set var="bgcell" value="#ffffff"-->
<!--#include virtual="/header.shtml"-->
<!--#exec cmd="/usr/bin/perl /etc/gnso/menu.pl 'Draft WHOIS related GNSO
Council minutes'"-->
<h4 align="center"><font face="Arial, Helvetica, sans-serif"><b>Extract of the
draft GNSO Council minutes<br>
relating to the WHOIS task force items </b></font></h4>
<p><font face="Arial, Helvetica, sans-serif"><b> GNSO Council Teleconference
held on 2 June 2005<br>
</b><strong><br>
Item 3: Consideration of the final report from the WHOIS task force with
respect to improving notification and consent for the use of contact data in
the Whois system. <BR>
<A
href="http://www.gnso.icann.org/mailing-lists/archives/council/msg00963.html";>http://www.gnso.icann.org/mailing-lists/archives/council/msg00963.html</A><br>
</strong><br>
<strong>Bruce Tonkin</strong> referred to his <a
href="http://gnso.icann.org/mailing-lists/archives/council/msg00977.html";>posting
to the Council list</a> stating, that with respect to considering the <a
href="http://www.gnso.icann.org/mailing-lists/archives/council/msg00963.html";>final
report </a>from the WHOIS task force on improving notification and consent
for the use of contact data in the Whois system, the GNSO council would follow
the <a href="http://www.icann.org/general/bylaws.htm#AnnexA";>ICANN bylaws,
section 10, of Annex A</a>, for the Policy Development Process. <br>
Section 10 states:<br>
10. Council Deliberation<br>
</font> <font face="Arial, Helvetica, sans-serif">a. Upon receipt of a Final
Report, the Council chair will<br>
(i) distribute the Final Report to all Council members; <br>
The <a
href="http://gnso.icann.org/mailing-lists/archives/council/msg00963.html";>Final
report has been distributed</a> to all council members and <br>
(ii) call for a Council meeting, which has been done on 2 June 2005.<br>
"The Council may commence its deliberation on the issue prior to the
formal meeting, including via in-person meetings, conference calls, e-mail
discussions or any other means the Council may choose. The deliberation process
shall culminate in a formal Council meeting either in person or via
teleconference, wherein the Council will work towards achieving a Supermajority
Vote to present to the Board."<br>
<strong><br>
Bruce Tonkin </strong>proposed adjourning the vote until the next council
meeting on 23 June 2005 to assure that proxy votes had specific voting
instructions, but using the current debate to determine if Council could reach
a Supermajority vote, 66%, based on the recommendation or whether changes were
needed. <br>
If the Council could reach a SuperMajority vote on the recommendation, the
Council might decide to create an implementation committee to flesh out some of
the implementation details before providing the Final Report <br>
to the Board.<br>
If the Council could not reach a SuperMajority position, then the Council
members that voted against the recommendations needed to provide written
reasons within 5 days for inclusion in the Final Report to the Board why they
voted against the recommendation. <br>
</font><font face="Arial, Helvetica, sans-serif"><br>
<a
href="http://gnso.icann.org/mailing-lists/archives/council/docEAuV3mXmul.doc";>Text
of the recommendation:
</a></font></p>
<font face="Arial, Helvetica, sans-serif"></font><p><font face="Arial,
Helvetica, sans-serif">"1. Registrars must ensure that disclosures
regarding availability<br>
and third-party access to personal data associated with domain names<br>
actually be presented to registrants during the registration process.<br>
Linking to an external web page is not sufficient. </font></p>
<font face="Arial, Helvetica, sans-serif"></font><p><font face="Arial,
Helvetica, sans-serif">2. Registrars must ensure that these disclosures are set
aside from<br>
other provisions of the registration agreement if they are presented to<br>
registrants together with that agreement. Alternatively, registrars may<br>
present data access disclosures separate from the registration<br>
agreement. The wording of the notice provided by registrars should, to<br>
the extent feasible, be uniform. <br>
<br>
3. Registrars must obtain a separate acknowledgement from<br>
registrants that they have read and understand these disclosures. This<br>
provision does not affect registrars' existing obligations to obtain<br>
registrant consent to the use of their contact information in the WHOIS<br>
system. "<br>
<br>
<strong><br>
Philip Sheppard</strong>, representing the Commercial and Business Users
constituency, <strong>Niklas Lagergren,</strong> a task force member and
representing the Intellectual Property Interests constituency and
<strong>Maureen Cubberley</strong>, elected by the Nominating Committee all
spoke in favour of the recommendation as being clear, concise, implementable,
maintained privacy as well as a high standard of data protection. </font></p>
<p><font face="Arial, Helvetica, sans-serif"><strong>Tom Keller</strong>, a
task force member and <strong>Bruce Tonkin</strong>, both representing the
Registrar constituency spoke against the recommendation. <br>
<strong>Tom Keller, </strong>against supporting the recommendation,
commented that it placed too much constraint on Registrars, it was unnecessary
to single out one issue especially in view of the<a
href="http://gnso.icann.org/mailing-lists/archives/council/docvXuOBc9Yat.doc";>
list of issues</a> to be clarified, and pointed out that there was a
difference between acknowledgement and consent.<br>
<strong>Bruce Tonkin</strong> commented from a registrars view point that
the recommendation dealt with consumer education and moved away from ICANN's
core issues regarding security and stability. There were many elements of
registrar agreements that consumers should be made aware of such as delete,
expiration of names practices, UDRP requirements, registering names in good
faith, and rather than single one ICANN, the Intellectual Property and Business
Users should be encouraging their communities to read all the terms and
conditions.<br>
Regarding part one, Registrars support making information about WHOIS
practices available, but disagreed that it was not possible to use a link to a
separate webpage. This is a standard way of linking to privacy policies and
terms and conditions. <br>
Obtaining a separate acknowledgement from registrants placed an unnecessary
burden on the registration process. <br>
The <a
href="http://www.icann.org/registrars/ra-agreement-17may01.htm#2";>Registrar
Accreditation Agreement</a> had a standard text that registrars should use to
inform registrants 2.7.4 <br>
<br>
<strong>Ken Stubbs</strong>, a task force member and a gTLD registries
constituency representative, proposed a uniform disclosure policy agreed on by
the registrars.<br>
<br>
<strong>Jordyn Buchanan</strong>, the chair of the combined WHOIS task force,
commented that the current recommendation arose from concern the <a
href="http://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html";>Whois
task force 2</a> had expressed that in the current notification to registrants
it was neither very conspicuous nor obvious that their data would be
published in a public data base.<br>
<B><a
href="http://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html#NotificationandConsent";>2.1
Notification and Consent</a></B></font></p>
<P><font face="Arial, Helvetica, sans-serif">"According to the ICANN
Registrar Accreditation Agreement (RAA), Registrars are required to form an
agreement with Registered Name Holders containing the following elements.
</font></P>
<P><font face="Arial, Helvetica, sans-serif">Section 3.7.7 of the RAA addresses
the requirements of the Registrar/Registrant agreement, including the need for
accurate and reliable registrant contact information. To the extent the notice
to registrants of data elements collected and displayed are not clear or may be
overlooked by registrants based on the overall length and complexity of the
registration agreement, it is useful to change the format so that better notice
is delivered to registrants. The task force finds that disclosures regarding
availability and access to Who is data should be set aside from other
provisions of a registration agreement by way of bigger or bolded font, a
highlighted section, simplified language or otherwise made more conspicuous.
</font></P>
<P><font face="Arial, Helvetica, sans-serif">It follows that separate consent
to the Whois disclosures is also useful. By obtaining separate consent from
registrants, at the time of agreement, to the specific Whois data provisions,
it would further draw attention to and facilitate better understanding of the
registrar’s Whois disclosure policy."</font></P>
<p><font face="Arial, Helvetica, sans-serif"><strong>In summary:</strong><br>
a. There could be general agreement on: <br>
2." Registrars must ensure that these disclosures are set aside from other
provisions of the registration agreement if they are presented to registrants
together with that agreement. Alternatively, registrars may<br>
present data access disclosures separate from the registration agreement. The
wording of the notice provided by registrars should, to the extent feasible, be
uniform. "<br>
<br>
b. This recommendation would appear to be unacceptable
<br>
3. Registrars must obtain a separate acknowledgement from registrants that they
have read and understand these disclosures. This provision does not affect
registrars' existing obligations to obtain registrant consent to the use of
their contact information in the WHOIS system."<br>
<br>
c. "Linking to an external web page is not sufficient." was supported
by the Registrars <br>
<strong><br>
ACTION ITEM:<br>
Marilyn Cade </strong>suggested as an administrative assignment to the ICANN
policy staff:<br>
<strong>Review of the top 10 registrars and a random selection of 10 other
registrars to determine how registrars make registrants aware of their
obligations to provide contact information for public display via the WHOIS
service. <br>
Report back to Council and the combined Whois task force.<br>
<br>
</strong></font><font face="Arial, Helvetica, sans-serif"><strong>Timeframe:
one week <br>
Vote adjourned until the next Council meeting June 23 2005, all councillors
unable to attend that meeting should provide proxy votes with instructions. <br>
</strong></font><br>
<FONT face="Arial, Helvetica, sans-serif"><strong>Item 4. Approval of new<a
href="http://www.gnso.icann.org/mailing-lists/archives/council/msg00968.html";>
terms of reference for combined WHOIS task force</a>, and approval of
membership and voting rules.<br>
Bruce Tonkin </strong>commented that the current <a
href="http://www.gnso.icann.org/mailing-lists/archives/council/msg00968.html";>terms
of reference</a>, version 5, had undergone minor additions since the council
meeting held on <a
href="http://www.gnso.icann.org/meetings/minutes-gnso-12may05.htm";>May 12,
2005. </a><br>
<br>
<strong>Niklas Lagergren proposed:<br>
</strong></FONT><strong><FONT face="Arial, Helvetica, sans-serif"> that a
requirement be added to the <a
href="http://www.gnso.icann.org/mailing-lists/archives/council/msg00968.html";>draft
terms of reference v5, task 4</a>, to develop a policy for up-front
verification of WHOIS information.<br>
</FONT></strong><FONT face="Arial, Helvetica, sans-serif"><br>
Discussion on the motion:<br>
<strong>Marilyn Cade</strong> stated that the Commercial and Business Users
constituency supported the need for accurate data, but did not support
mandating how the data should be validated. <br>
<strong>Bruce Tonkin</strong> suggested investigating the incidence of WHOIS
problem reports, how frequent was their follow up and was the complaint system
working <br>
<br>
The motion received <strong>12 votes in favour</strong>, <strong>7 votes
against</strong> and <strong>6 abstentions</strong> (count as votes against)
out of a<strong> total of 26 votes</strong>. Kiyoshi Tsuru no vote, absent
without proxy<br>
<strong>The motion failed.<br>
<br>
Bruce Tonkin </strong>proposed a vote:<br>
<strong>to accept
the <a
href="http://www.gnso.icann.org/mailing-lists/archives/council/msg00968.html";>Draft
terms of reference v5</a> for the combined WHOIS task force.
</strong></FONT></p>
<font face="Arial, Helvetica, sans-serif">The motion received <strong>22 votes
in favour, </strong>out of a total of 26 votes, (4 councillors were absent for
the vote). <br>
<strong>The motion carried</strong><br>
<br>
<strong>Marilyn Cade </strong>proposed instructions on the process:<br>
- The task force should be encouraged to have an interactive relationship with
Council by reporting on a continual basis the stages of work undertaken.<br>
In order to define the purpose of WHOIS, the current uses should be identified
and data collected by previous task forces with the help of the ICANN policy
staff should be documented. <br>
<br>
<strong>The GNSO Council accepted the <a
href="http://gnso.icann.org/policies/terms-of-reference.html";>Terms of
Reference for the combined WHOIS task force</a>, noted below: </strong><br>
<br>
The mission of The Internet Corporation for As</font><font face="Arial,
Helvetica, sans-serif">signed Names and Numbers ("ICANN") is to
coordinate, at the overall level, the global Internet's systems of unique
identifiers, and in particular to ensure the stable and secure operation of the
Internet's unique identifier systems. </font>
<p align="justify"><font face="Arial, Helvetica, sans-serif">In performing this
mission, ICANN's bylaws set out 11 core values to guide its decisions and
actions. Any ICANN body making a recommendation or decision shall exercise its
judgment to determine which of these core values are most relevant and how they
apply to the specific circumstances of the case at hand, and to determine, if
necessary, an appropriate and defensible balance among competing
values.</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">ICANN has
agreements with gTLD registrars and gTLD registries that require the provision
of a WHOIS service via three mechanisms: port-43, web based access, and bulk
access. The agreements also require a<br>
Registered Name Holder to provide to a Registrar accurate and reliable
contact details and promptly correct and update them during the term of the
Registered Name registration, including: the full name, postal<br>
address, e-mail address, voice telephone number, and fax number if available
of the Registered Name Holder; name of authorized person for contact purposes
in the case of an Registered Name Holder that is an<br>
organization, association, or corporation; the name, postal address, e-mail
address, voice telephone number, and (where available) fax number of the
technical contact for the Registered Name; and the name, postal<br>
address, e-mail address, voice telephone number, and (where available) fax
number of the administrative contact for the Registered Name. The contact
information must be adequate to facilitate timely resolution of<br>
any problems that arise in connection with the Registered Name.</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">A registrar is
required in the Registrar Accreditation Agreement (RAA) to take reasonable
precautions to protect Personal Data from loss, misuse, unauthorized access or
disclosure, alteration, or destruction.</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">The goal of the
WHOIS task force is to improve the effectiveness of the WHOIS service in
maintaining the stability and security of the Internet's unique identifier
systems, whilst taking into account where<br>
appropriate the need to ensure privacy protection for the Personal Data of
natural persons that may be Registered Name Holders, the authorised
representative for contact purposes of a Register Name Holder, or the
administrative or technical contact for a domain name.</font></p>
<p align="justify"><font face="Arial, Helvetica,
sans-serif"><strong>Tasks:</strong></font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">(1) Define the
purpose of the WHOIS service in the context of ICANN's mission and relevant
core values, international and national laws protecting privacy of natural
persons, international and national laws<br>
that relate specifically to the WHOIS service, and the changing nature of
Registered Name Holders.<br>
</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">(2) Define the
purpose of the Registered Name Holder, technical, and administrative contacts,
in the context of the purpose of WHOIS, and the purpose for which the data was
collected. Use the relevant definitions from <a
href="http://www.icann.org/gnso/transfers-tf/report-exhc-12feb03.htm";>Exhibit C
of the Transfers Task force report </a>as a starting point <br>
(from
http://www.icann.org/gnso/transfers-tf/report-exhc-12feb03.htm):</font></p>
<p align="center"><font face="Arial, Helvetica, sans-serif">"Contact:
Contacts are individuals or entities associated with domain<br>
name records. Typically, third parties with specific inquiries or<br>
concerns will use contact records to determine who should act upon<br>
specific issues related to a domain name record. There are typically<br>
three of these contact types associated with a domain name record, the<br>
Administrative contact, the Billing contact and the Technical
contact.</font></p>
<p align="center"><font face="Arial, Helvetica, sans-serif">Contact,
Administrative: The administrative contact is an individual,<br>
role or organization authorized to interact with the Registry or<br>
Registrar on behalf of the Domain Holder. The administrative contact<br>
should be able to answer non-technical questions about the domain name's<br>
registration and the Domain Holder. In all cases, the Administrative<br>
Contact is viewed as the authoritative point of contact for the domain<br>
name, second only to the Domain Holder.</font></p>
<p align="center"><font face="Arial, Helvetica, sans-serif">Contact, Billing:
The billing contact is the individual, role or<br>
organization designated to receive the invoice for domain name<br>
registration and re-registration fees.</font></p>
<p align="center"><font face="Arial, Helvetica, sans-serif">Contact, Technical:
The technical contact is the individual, role or<br>
organization that is responsible for the technical operations of the<br>
delegated zone. This contact likely maintains the domain name server(s)<br>
for the domain. The technical contact should be able to answer technical<br>
questions about the domain name, the delegated zone and work with<br>
technically oriented people in other zones to solve technical problems<br>
that affect the domain name and/or zone.<br>
Domain Holder: The individual or organization that registers a specific<br>
domain name. This individual or organization holds the right to use that<br>
specific domain name for a specified period of time, provided certain<br>
conditions are met and the registration fees are paid. This person or<br>
organization is the "legal entity" bound by the terms of the
relevant<br>
service agreement with the Registry operator for the TLD in
question."<br>
</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">(3) Determine what
data collected should be available for public access in the context of the
purpose of WHOIS. Determine how to access data that is not available for public
access. The current elements that must be displayed by a registrar
are:</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">- The name of the
Registered Name;</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">- The names of the
primary nameserver and secondary nameserver(s) for the Registered
Name;</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">- The identity of
Registrar (which may be provided through Registrar's website);</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">- The original
creation date of the registration;</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">- The expiration
date of the registration;</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">- The name and
postal address of the Registered Name Holder;</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">- The name, postal
address, e-mail address, voice telephone number, and (where available) fax
number of the technical contact for the Registered Name; and</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">- The name, postal
address, e-mail address, voice telephone number, and (where available) fax
number of the administrative contact for the Registered Name.<br>
</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">(4) Determine how
to improve the process for notifying a registrar of inaccurate WHOIS data, and
the process for investigating and correcting inaccurate data. Currently a
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<br>
inaccurate contact information associated with a Registered Name it sponsors,
it shall take reasonable steps to correct that inaccuracy."<br>
</font></p>
<p align="justify"><font face="Arial, Helvetica, sans-serif">(5) Determine how
to resolve differences between a Registered Name Holder's, gTLD Registrar's, or
gTLD Registry's obligation to abide by all applicable laws and governmental
regulations that relate to the<br>
WHOIS service, as well as the obligation to abide by the terms of the
agreements with ICANN that relate to the WHOIS service. [Note this task refers
to the current work in the WHOIS task force called 'Recommendation 2', A
Procedure for conflicts, when there are conflicts between a registrar's of
registry's legal obligations under local privacy laws and their contractual
obligations to ICANN.]<br>
</font></p>
<p align="justify"></p>
|