<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><title>GNSO | Whois Privacy</title>
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<style type="text/css">
<!--
p, li, td, ul { font-family: Arial, Helvetica, sans-serif}
.indent { margin-left:2em }
.red { color: #FF0000; }
a.cal {color:#FF0000}
td.cald { font-size: smaller }
.style1 {font-family: Arial, Helvetica, sans-serif}
-->
</style>
</head>
<body bgcolor="#ffffff">
<table align="center" border="0" cellpadding="0" cellspacing="2" width="100%">
<tbody><tr>
<td align="center" width="15%"><a href="http://gnso.icann.org/index.html"><img alt="ICANN Logo" src="tf-prelim-rpt-12sep05_files/logo_med.jpg" align="top" border="0" height="116" width="150"></a></td>
<td><img src="tf-prelim-rpt-12sep05_files/space.gif" border="0" height="1" width="1"></td>
<td valign="top"><img src="tf-prelim-rpt-12sep05_files/space.gif" border="0" height="1" width="1"></td>
<td valign="top"><img src="tf-prelim-rpt-12sep05_files/space.gif" border="0" height="1" width="1"></td>
<td align="center" width="84%"> <p> <font size="+2"><b>
Whois Privacy</b></font>
<br><font size="+1"><i></i></font>
</p></td></tr>
<tr>
<td rowspan="3" bgcolor="#ccccff" valign="top">
<table border="0" cellpadding="4" cellspacing="0" width="100%">
<tbody><tr>
<td colspan="2"><b>Information</b></td>
</tr>
<tr><td valign="top" width="1%"> </td>
<td valign="top" width="99%"><font size="-1"><a class="cal" href="http://gnso.icann.org/calendar/">Master Calendar</a></font></td>
</tr>
<tr><td valign="top" width="1%"> </td>
<td valign="top" width="99%"><font size="-1"><a href="http://gnso.icann.org/announcements/">Announcements</a></font></td>
</tr>
<tr>
<td valign="top"> </td>
<td valign="top"><font size="-1"><a href="http://gnso.icann.org/issues/">Issues</a></font></td>
</tr>
<tr>
<td valign="top"> </td>
<td valign="top"><font size="-1"><a href="http://gnso.icann.org/comments-request/">Request for Comments</a></font></td>
</tr>
<tr>
<td valign="top"> </td>
<td valign="top"><font size="-1"><a href="http://gnso.icann.org/policies/">Policies</a></font></td>
</tr>
<tr>
<td valign="top"> </td>
<td valign="top"><font size="-1"><a href="http://gnso.icann.org/faq.shtml">FAQ</a></font></td>
</tr>
<tr>
<td valign="top"> </td>
<td valign="top"><font size="-1"><a href="http://gnso.icann.org/reference-documents.htm">Documents</a></font></td>
</tr>
<tr>
<td valign="top"> </td>
<td valign="top"><font size="-1"><a href="http://gnso.icann.org/mailing-lists/">Mailing Lists</a></font></td>
</tr>
<tr>
<td valign="top"> </td>
<td valign="top"><font size="-1"><a href="http://www.dnso.org/">DNSO Site Archive</a></font></td>
</tr>
<tr>
<td valign="top"> </td>
<td><font size="-1"><a href="http://gnso.icann.org/acronyms.shtml">Acronyms</a></font></td>
</tr>
<tr>
<td valign="top"> </td>
<td><font size="-1"><a href="http://gnso.icann.org/elections/index.html">Elections</a></font></td>
</tr>
<tr>
<td colspan="2"><b>Constituencies</b></td>
</tr>
<tr>
<td> </td>
<td><font size="-1"><a href="http://gnso.icann.org/commercial-and-business/">Commercial & Business</a></font></td>
</tr>
<tr>
<td> </td>
<td><font size="-1"><a href="http://gnso.icann.org/gtld-registries/">gTLD Registries</a></font></td>
</tr>
<tr>
<td> </td>
<td><font size="-1"><a href="http://gnso.icann.org/internet-service-and-connection-providers/">Internet Service & Connection Providers</a></font></td>
</tr>
<tr>
<td> </td>
<td><font size="-1"><a href="http://gnso.icann.org/non-commercial/">Non-Commercial</a></font></td>
</tr>
<tr>
<td> </td>
<td><font size="-1"><a href="http://gnso.icann.org/registrars/">Registrars</a></font></td>
</tr>
<tr>
<td> </td>
<td><font size="-1"><a href="http://gnso.icann.org/intellectual-property/">Intellectual Property</a></font></td>
</tr>
<tr>
<td colspan="2"><b>GNSO Council</b></td>
</tr>
<tr>
<td> </td>
<td><font size="-1"><a href="http://gnso.icann.org/council/members.shtml">Council Members</a></font></td>
</tr>
<tr>
<td> </td>
<td><font size="-1"><a href="http://gnso.icann.org/council/icann-participants.shtml">ICANN Participants</a></font></td>
</tr>
<tr>
<td> </td>
<td><font size="-1"><a href="http://gnso.icann.org/council/docs.shtml">Documents</a></font></td>
</tr>
</tbody></table>
</td>
<td rowspan="3"><img src="tf-prelim-rpt-12sep05_files/space.gif" border="0" height="1" width="1"></td>
<td rowspan="3" valign="top"><img src="tf-prelim-rpt-12sep05_files/space.gif" border="0" height="1" width="1"></td>
<td rowspan="3" valign="top"><img src="tf-prelim-rpt-12sep05_files/space.gif" border="0" height="1" width="1"></td>
<td bgcolor="#ffffff" height="589" valign="top" width="74%">
<table border="0" cellpadding="4" cellspacing="0" width="100%">
<tbody><tr>
<td>
<table bgcolor="#cccccc" border="0" cellpadding="2" cellspacing="0" width="100%">
<tbody><tr>
<td><font size="-1"><b>
<a href="http://gnso.icann.org/">GNSO Home</a> | <a href="http://gnso.icann.org/issues/">Issues</a> | Whois Privacy</b></font></td>
</tr>
</tbody></table>
<h2>Combined
WHOIS Task Force of the GNSO Council</h2>
<p align="left"> <b>Final task force report on a policy recommendation
and advice on a procedure for handling conflicts between a
registrar/registry's legal obligations under privacy laws and their
contractual obligations to ICANN </b>
</p>
<p align="center"> </p>
<hr>
<p> <b>Table of contents </b></p>
<br>
<p>
1 Introduction & background <br>
1.1 Text of recommendation and advice on a procedure<br>
1.2 Summary of Task Force voting on the recommendation<br>
<br>
2 Constituency statements <br>
<br>
2.1 Commercial and Business User Constituency <br>
2.2 Non-Commercial User Constituency <br>
2.3 Intellectual Property Constituency <br>
2.4 Registrar Constituency <br>
2.5 Registry Constituency<br>
2.6 Internet Service Providers & Connectivity Providers Constituency<br>
</p>
<p>3 Public comment report</p>
<p> 3.1 Comments from the International Trademark Association - WHOIS Subcommittee<br>
3.2 Comments from indidivuals<br>
3.3 Comments from the Electronic Privacy Information Center (EPIC)<br>
3.4 Comments from the American Intellectual Property Law Association (AIPLA) <br>
3.5 Public comments report - conclusion </p>
<p> Annexes <br>
<br>
Annex 1 Relevant provisions of the Registrar Accreditation Agreement (RAA) </p>
<p> Annex 2 International Data Protection laws: Comments to ICANN from Commissioners and Organizations regarding WHOIS and the Protection of Privacy (background paper from the NCUC) </p>
<p> Annex 3 Results of Task Force indicative straw poll on proposed changes to the recommendation and advice </p>
<hr>
<p> <b>1 Introduction & background</b> </p>
<p> <a name="X-1"></a>Article X,
Section 1 of the ICANN Bylaws
(<a href="http://www.icann.org/general/bylaws.htm#X">http://www.icann.org/general/bylaws.htm#X</a>
) states "the Generic Names Supporting Organization (GNSO), (which)
shall be responsible for developing and recommending to the ICANN
Board substantive policies relating to generic top-level domains."
This preliminary task force report and the consensus policy
recommendation therein refers only to the generic top level domain
space. </p>
<p> This
document is the Preliminary Task Force Report on a consensus policy
recommendation and advice on a procedure for handling WHOIS conflicts
with local or national privacy laws. It is comprised of the proposed
recommendation and advice, background information, the task force
vote and the constituency statements. This report was the subject of
a task force vote held on Tuesday, 6<sup>th</sup> September, 2005.
</p>
<p> Work on the issues in this task force report was begun in 2003 by the then WHOIS Task Force 2. This work was continued through 2005 by the Combined WHOIS Task Force which ultimately voted on the developed recommendation and advice. In
December 2003, WHOIS Task Force 2 was tasked with "<i>document(ing)
examples of existing privacy laws in regard to display/transmittal of
data</i>". (Task Force 2 terms of reference, point 4 of 'tasks
and milestones';available at
<a href="http://gnso.icann.org/issues/whois-privacy/tor2.shtml">http://gnso.icann.org/issues/whois-privacy/tor2.shtml</a>). </p>
<p> Task
Force 2's preliminary report was published for public comment in
June 2004 (available at
<a href="http://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html">http://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html</a>).
It included a table of privacy laws by country of registrar, created by the Registrar Constituency and the Non-Commercial Users Constituency - an updated version is available <a href="http://www.ncdnhc.org/policydocuments/TF2Analysis-OECD%20Governments.xls">here</a>. The report found, in section 2.3, that:
</p>
<p> "<i>After
documenting and reviewing the examples of local privacy laws it is
the Task Force's finding that different nations have very different
privacy laws and that the determination whether they are applicable
to the gTLD WHOIS situation is not an easy one. However, situations
have arisen in which privacy laws or regulations have conflicted with
WHOIS-related contractual obligations with ICANN. </i>
</p>
<p> ... </p>
<p> <i>The
Task Force believes that there is an ongoing risk of conflict between
a registrars' or registries' legal obligations under local
privacy laws and their contractual obligations to ICANN. </i>
</p>
<p> <i>Since
the variety of the existing local privacy laws does not allow for a
one-size-fits-all solution, the registrars and registries
encountering such local difficulties should be allowed an exception
from the contractual WHOIS obligation for the part of the WHOIS data
in question by the local regulation, after proving the existence of
such a conflict with a law or regulation. In addition, a procedure
should be established for seeking to resolve such conflicts with
local authorities as new regulations evolve in a way that promotes
stability and uniformity of the WHOIS system. Such steps will
undoubtedly achieve a greater legal certainty and foster the
international competition on the domain name market."</i> </p>
<p> The
report recommended (section 3.3) that ICANN: </p>
<p> "<i>...should develop
and implement a procedure for dealing with the situation where a
registrar (or registry, in thick registry settings) can credibly
demonstrate that it is legally prevented by local mandatory privacy
law or regulations from fully complying with applicable provisions of
its ICANN contract regarding the collection, display and distribution
of personal data via Whois. The goal of the procedure should be to
resolve the conflict in a manner conducive to stability and
uniformity of the Whois system</i>." </p>
<p> The report gave details for the steps to be included in such a procedure:</p>
<p>
<i>
</i></p><ul>
<li><i> "Written
notification by the affected registrar/registry to ICANN with a
detailed report which includes but is not limited to: </i></li>
<i> </i><ul>
<i> <li>The law or regulation that causes the conflict.</li>
<li>The part of the Whois obligation in question.</li>
<li>The steps that will have to be taken to cure the conflict.</li>
</i></ul>
<li><i>If data elements are removed this must be notified to the requester
by the insertion of standardized notice in the Whois results advising the
requester of the problem and, if possible, directing requester to another or
alternative procedure for obtaining access to this data element.</i></li>
<li><i>Prompt notification from ICANN to the public informing it of the
change and of the reasons for ICANN's forbearance from enforcement of full
compliance with the contractual provision in question. </i></li>
<li><i> The
changes must be archived on a public website for future research. </i></li>
</ul>
<p></p>
<p> <i> Except in those cases arising from a formal complaint or contact by a
local law enforcement authority that will not permit consultation with ICANN
prior to resolution of the complaint under local law, the procedure should be
initiated using the following steps:
</i></p><ul>
<li><i>prompt notification by the affected registrar/registry to ICANN with
detailed summary of the problem arising including:
</i><ul>
<i> <li>the
law or regulation that causes the conflict.</li>
<li>the
part of the Whois obligation in question.</li>
</i></ul>
</li><li><i> consultation
by the registrar/registry with ICANN and other parties (which
include government agencies) to try to resolve the problem / remove
the
impediment to full compliance with contract."
</i></li></ul>
<p></p>
<p> On 30
November 2004, the WHOIS Task Forces 1 and 2 produced <b>Recommendation
1 — A Procedure for conflicts, when there are conflicts between a
registrar's or registry's legal obligations under local privacy laws
and their contractual obligations to ICANN </b>
(available at
<a href="http://gnso.icann.org/issues/whois-privacy/whois-tf-conflict-30nov04.pdf">
http://gnso.icann.org/issues/whois-privacy/whois-tf-conflict-30nov04.pdf</a>).
This recommendation was presented to the GNSO Council during the GNSO
public forum at the ICANN meeting in Capetown in December 2004.
</p>
<p> On
February 17, 2005, the WHOIS task forces 1, 2 and 3 were combined
into a single combined WHOIS Task Force.
(<a href="http://www.gnso.icann.org/meetings/minutes-gnso-17feb05.shtml">
http://www.gnso.icann.org/meetings/minutes-gnso-17feb05.shtml</a>). On
2nd June 2005, the combined WHOIS task force was chartered by the
GNSO Council with terms of reference and a set of tasks that required
it to conclude its work on the 'conflicts' policy recommendation: </p>
<p><i> "(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
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."
</i>(available at
http://gnso.icann.org/policies/terms-of-reference.html) </p>
<p> Accordingly, task force members continued to develop the recommendation
through June 2005. The task force voted on May 24, 2005 to divide its work
into a recommendation for consensus policy accompanied by advice for a
procedure. Constituency statements on the recommendation were solicited by
21 July 2005. </p>
<p>The task force met on 30 August, 2005 to discuss the constituency statements. Further discussion was held on-list and by teleconference to discuss proposed changes to the recommendation and advice, including an illustrative 'straw poll' of task force members to ascertain the level of support for specific changes. The text of the proposed recommendations and the level of support is detailed in Annex 3 to this report. The straw poll results were indicative only and do not represent an official vote of the task force. The text in section 1.1 below represents the final version agreed by the task force and posted for public comments from 12 September to 2 October, 2005. </p>
<p>O<span class="style1">n 11 October, 2005, the task force met to review and discuss the public comments received during the public comment period from 12 September 2005 to 2 October 2005. The public comment report in section 3 of this report summarises the public comments received and also describes the result of the task force meeting on 11 October, 2005. </span></p>
<p><span class="style1">Also at the task force meeting on 11 October, 2005, the task force invited constituencies who wished to do so to submit a short final statement on any changes to the procedure/advice that were not accepted by the task force. One such statement was received from the Intellectual Property Constituency (IPC), and it has been included following the IPC's original statement in section <strong>2.3 (a) </strong>below. This supplementary statement was also supported by the Business Constituency and the Internet Service Providers and Connectivity Providers Constituency. </span></p>
<p> </p>
<p> <b>1.1
Text of recommendation and advice on a procedure</b> </p>
<p>
</p>
<p> This
is the final version of the recommendation and advice voted on by the
task force. The constituency statements responded to an earlier
version of this text.
</p>
<p> <b>WHOIS
Task Force policy recommendation and advice on Whois conflicts with
national and local privacy laws</b> </p>
<p> <b>Preamble</b> </p>
<p> Task
Force 2 spent over a year collecting data and working on the conflict
between a registrar/registry's legal obligations under privacy laws
and their contractual obligations to ICANN. Its report included the
statement: "The Task Force believes that there is an ongoing risk
of conflict between a registrar's or registry's legal obligations
under local privacy laws and their contractual obligations to ICANN.
TF2 Report, Section 2.3,
<a href="http://www.gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html">
http://www.gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html</a>. </p>
<p> By vote
of the Task Force, now merged, on May 24, 2005, the work of Task
Force 2 is hereby divided into a recommendation for "consensus
policy" accompanied by "well-developed advice for a procedure." </p>
<p> <b>I.
Task Force Policy for WHOIS Conflicts with Privacy Law</b> </p>
<p> <b>CONSENSUS
POLICY RECOMMENDATION</b> </p>
<p> In order
to facilitate reconciliation of any conflicts between local/national
mandatory privacy laws or regulations and applicable provisions of
the ICANN contract regarding the collection, display and distribution
of personal data via Whois, ICANN should:
</p>
<ol>
<li><p> Develop and publicly document a procedure for dealing with the
situation in which a registrar or registry can credibly demonstrate that it
is legally prevented by local/national privacy laws or regulations from fully
complying with applicable provisions of its ICANN contract regarding the
collection, display and distribution of personal data via WHOIS.
</p>
</li><li><p> Create goals for the procedure which include: </p>
<ol type="a">
<li>Ensuring that ICANN staff is informed of a conflict at the earliest
appropriate juncture; </li>
<li> Resolving the conflict, if possible, in a manner conducive to ICANN's
Mission, applicable Core Values and the stability and uniformity of the Whois
system;</li>
<li> Providing a mechanism for the recognition, if appropriate, in
circumstances where the conflict cannot be otherwise resolved, of an
exception to contractual obligations to those registries/registrars to which
the specific conflict applies with regard to collection, display and
distribution of personally identifiable data via Whois; and </li>
<li> Preserving sufficient flexibility for ICANN staff to respond to
particular factual situations as they arise. </li>
</ol>
</li></ol>
<p> <b>II.
Text of Recommended Procedure</b> </p>
<p> <b>WELL-DEVELOPED ADVICE ON A PROCEDURE FOR HANDLING WHOIS CONFLICTS WITH
PRIVACY LAW </b> </p>
<p> Based on extensive research and negotiation among Task Force 2, together
with the merged Task Force and ICANN staff, the following procedure for
handling the policy recommendation set out in Section I above is set out as a
Recommended Step-by-Step Procedure for Resolution of WHOIS Conflicts with
Privacy Law. We encourage ICANN staff to use this Recommended Procedure as a
starting point for developing the procedure called for in the Consensus
Policy Recommendation above. </p>
<p> <i>Step One: Notification of Initiation of Action</i> </p>
<p> Once receiving notification of an investigation, litigation, regulatory
proceeding or other government or civil action that might affect its
compliance with the provisions of the RAA or other contractual agreement with
ICANN dealing with the collection, display or distribution of personally
identifiable data via Whois ("Whois Proceeding"), a Registrar/ Registry must
within thirty (30) days provide ICANN's General Counsel (or other staff
member as designated by ICANN) with the following information: </p>
<ul type=".">
<li>Summary description of the nature and status of the action (e.g.,
inquiry, investigation, litigation, threat of sanctions, etc.)</li>
<li> Contact information for the responsible official of the
registrar/registry for resolving the problem. </li>
<li> Contact information for the responsible territorial government agency or
other claimant and a statement from the registrar/registry authorizing ICANN
to communicate with those officials or claimants on the matter. If the
registrar/registry is prevented by applicable law from granting such
authorization, the notification should document this. </li>
<li> The text of the applicable law or regulations upon which the local
government or other claimant is basing its action or investigation, if such
information has been indicated by the government or other claimant. </li>
</ul>
<p> Meeting
the notification requirement permits Registrars/Registries to
participate in investigations and respond to court orders,
regulations, or enforcement authorities in a manner and course deemed
best by their counsel. </p>
<p> Depending
on the specific circumstances of the Whois Proceeding, the
Registrar/Registry may request that ICANN keep all correspondence
between the parties confidential pending the outcome of the Whois
Proceeding. It is recommended that ICANN respond favorably to such
requests to the extent that they can be accommodated with other legal
responsibilities and basic principles of transparency applicable to
ICANN operations.
</p>
<p> <i>Step Two: Consultation</i> </p>
<p> Unless impractical under the circumstances, we recommend that the ICANN
General Counsel, upon receipt and review of the notification and, where
appropriate, dialogue with the registrar/registry, consider beginning a
process of consultation with the local/national enforcement authorities or
other claimant together with the registrar/registry. The goal of the
consultation process should be to seek to resolve the problem in a manner
that preserves the ability of the registrar/registry to comply with its
contractual obligations to the greatest extent possible. </p>
<p> The Registrar should attempt to identify a solution that allows the
registrar to meet the requirements of both the local law and ICANN
obligations. The General Counsel can assist in advising the registrar on
whether the proposed solution meets the ICANN obligations. </p>
<p> If the Whois proceeding ends without requiring any changes and/or the
required changes in registrar/registry practice do not, in the opinion of the
General Counsel, constitute a deviation from the R.A.A. or other contractual
obligation , then the General Counsel and the registrar/registry need to take
no further action. </p>
<p> If the registrar/registry is required by local law enforcement
authorities or a court to make changes in its practices affecting compliance
with Whois-related contractual obligations before any consultation process
can occur, the registrar/registry shall promptly notify the General Counsel
of the changes made and the law/regulation upon which the action was based.
The Registrar/Registry may request that ICANN keep all correspondence between
the parties confidential pending the outcome of the Whois Proceeding. It is
recommended that ICANN respond favorably to such requests to the extent that
they can be accommodated with other legal responsibilities and basic
principles of transparency applicable to ICANN operations. </p>
<p> <i>Step Three: General Counsel analysis and recommendation</i> </p>
<p> If the local/national government requires changes (whether before, during
or after the consultation process described above) that, in the opinion of
the General Counsel, prevent full compliance with contractual WHOIS
obligations, ICANN should consider the following alternative to the normal
enforcement procedure. Under this alternative, ICANN would refrain, on a
provisional basis, from taking enforcement action against the
registrar/registry for non-compliance, while the General Counsel prepares a
report and recommendation and submits it to the ICANN Board for a decision.
Such a report may contain: </p>
<ol type="i">
<li> A
summary of the law or regulation involved in the conflict; </li>
<li> Specification
of the part of the registry or registrar's contractual WHOIS
obligations
with which full compliance if being prevented;
</li>
<li> Summary
of the consultation process if any under step two; and
</li>
<li> Recommendation
of how the issue should be resolved, which may include
whether
ICANN should provide an exception for those registrars/registries to
which the specific conflict applies from one or more identified WHOIS
contractual
provisions. The report should include a detailed justification of
its recommendation, including the anticipated impact on the
operational
stability,
reliability, security, or global interoperability of the Internet's
unique
identifier systems if the recommendation were to be approved or
denied.
</li>
</ol>
<p> The
registrar/registry should be provided a copy of the report and
provided a reasonable opportunity to comment on it to the Board. The
Registrar/Registry may request that ICANN keep such report
confidential prior to any resolution of the Board. It is recommended
that ICANN respond favorably to such requests to the extent that they
can be accommodated with other legal responsibilities and basic
principles of transparency applicable to ICANN operations.
</p>
<p> <i>Step Four: Resolution </i> </p>
<p> Keeping
in the mind the anticipated impact on the operational stability,
reliability, security, or global interoperability of the Internet's
unique identifier systems, the Board should consider and take
appropriate action on the recommendations contained in the General
Counsel's report as soon as practicable. Actions could include,
but are not limited to: </p>
<ul>
<li> Approving
or rejecting the report's recommendations, with or without
modifications; </li>
<li> Scheduling
a public comment period on the report; or
</li>
<li> Referring
the report to GNSO for its review and comment by a date
certain. </li>
</ul>
<p align="left"> <i>Step
Five: Public Notice</i> </p>
<p> The
Board's resolution of the issue, together with the General
Counsel's report, should ordinarily be made public, along with the
reasons for it, and be archived on a public website (along with other
related materials) for future research. Prior to release of such
information to the public, the Registry/Registrar may request that
certain information (including, but not limited to, communications
between the Registry/Registrar and ICANN, or other
privileged/confidential information) be redacted from the public
notice. In the event that such redactions make it difficult to
convey to the public the nature of the actions being taken by the
Registry/Registrar, the General Counsel should work with the
Registry/Registrar on an appropriate notice to the public describing
the actions being taken and the justification for such actions.
</p>
<p> Unless
the Board decides otherwise, if the result of its resolution of the
issue is that data elements in the registrar's Whois output will be
removed or made less accessible, ICANN should issue an appropriate
notice to the public of the resolution and of the reasons for ICANN's
forbearance from enforcement of full compliance with the contractual
provision in question.
</p>
<p> <i>Step
Six: Ongoing Review</i> </p>
<p> With
substantial input from the relevant registries or registrars,
together with all constituencies, there should be a review of the
pros and cons of how the process worked, and the development of
revisions designed to make the process better and more efficient,
should the need arise again at some point in the future. </p>
<p>
</p>
<p align="left"> <b>1.2 Summary
of Task Force voting on the recommendation </b>
</p>
<p> The
task force vote on the recommendation and advice for a procedure was
held during a task force conference call on 6 September 2005. The
recommendation and advice for a procedure were supported unanimously.
</p>
<table border="1" bordercolor="#000000" cellpadding="7" cellspacing="0" width="620">
<col width="172">
<col width="226">
<col width="178">
<tbody><tr valign="top">
<td width="172">
<p> <b>In favour</b> </p>
</td>
<td width="226">
<p> <b>Opposed</b> </p>
</td>
<td width="178">
<p> <b>Abstained</b> </p>
</td>
</tr>
<tr valign="top">
<td width="172">
<p> <b>Commercial
and Business Users Constituency</b> </p>
<p> (Marilyn
Cade, David Fares, Sarah Deutsch) </p>
</td>
<td width="226">
<p align="left"> None </p>
</td>
<td width="178">
<p> Jordyn
Buchanan (Co-Chair) </p>
</td>
</tr>
<tr valign="top">
<td width="172">
<p> <b>Intellectual
Property Constituency</b> </p>
<p> (Steve
Metalitz, Niklas Lagergren) </p>
</td>
<td width="226">
</td>
<td width="178">
</td>
</tr>
<tr valign="top">
<td width="172">
<p> <b>Non
Commercial Users Constituency</b> </p>
<p> (Milton
Mueller, proxy for all NCUC task force members) </p>
</td>
<td width="226">
</td>
<td width="178">
</td>
</tr>
<tr valign="top">
<td width="172">
<p> <b>Internet
Service Providers and Connectivity Providers Constituency</b> </p>
<p> (Tony
Harris) </p>
</td>
<td width="226">
</td>
<td width="178">
</td>
</tr>
<tr valign="top">
<td width="172">
<p> <b>Registrars
Constituency</b> </p>
<p> <b>( </b><span>Ross
Rader, proxy for all registrars constituency task force members</span><b>)
</b>
</p>
</td>
<td width="226">
</td>
<td width="178">
</td>
</tr>
<tr valign="top">
<td width="172">
<p> <b>Registry
Constituency</b> </p>
<p> <b>(</b><span>David
Maher, Ken Stubbs, Tuly Day</span><b>)</b> </p>
</td>
<td width="226">
</td>
<td width="178">
</td>
</tr>
</tbody></table>
<p> <b>2 Constituency statements</b> </p>
<p> <b>2.1 Commercial and Business User Constituency</b> </p>
<blockquote>
<p> This statement provides the BC views on the draft recommendation of the WHOIS TF on procedures to be followed in the event of a conflict between national privacy laws and registry/registrar contractual obligations to ICANN.</p>
<p><strong>Background </strong></p>
<p>The BC supports the task force recommendations on addressing possible conflicts between the national laws affecting a registry or registrar and the relevant ICANN contracts. </p>
<p>The BC has not seen examples of such conflicts and is not aware that they are a frequent occurrence. Many of the BC members operate in multiple regions of the world, and offer online services. Our members are familiar with privacy requirements for online services in jurisdictions where they operate. The BC is not aware of any increase in conflicts and does not expect this to change. However, the BC supports the TF recommendations in order to ensure transparent, consistent approaches to dealing with any such conflicts. </p>
<p><strong>BC Position </strong></p>
<p>It is the experience of the BC members that most of the established privacy regimes are typically based on the OECD privacy principles, requiring use and disclosure practices to be provided to the data subject at the time of data collection. ICANN’s present WHOIS requirements, as governed by the RAA, require notice and consent to the collection of personally identifiable data. </p>
<p>Thus, today, as required by existing ICANN agreements, registrants are notified of the collection and display of data and consent to the collection and display of data. This should meet the privacy requirements of existing national law. </p>
<p>In the view of the BC, registrants are obtaining domain names in order to engage in communications with the public and therefore, should provide accurate and complete information so that they can be “found” through a WHOIS query. The BC strongly supports accurate WHOIS data and recommends that all registrants be advised of the requirement to provide such data and that that data will be publicly displayed. The BC does support the use of third party services to provide any needed anonymity, such as third parties, registrars, or ISP services. The BC notes that any individual who prefers not to have such data has choices, both in the third party proxy registrant services, and also by utilizing an ISP or web hosting service who can provide personal web pages. Thus, the BC does not accept that individuals/as registrants, should be allowed to use false information as a protection of personal privacy. </p>
<p>The BC believes that the registrant notice should be sufficient; and therefore the BC fully supports the additional focus on notice to the registrants as provided in a separate working item of the WHOIS TF. </p>
<p>As regards the need for a standardized process to deal with national law conflicts, should a conflict with national law arise, the BC supports the need for a standardized transparent process that establishes the required procedures to resolve possible conflicts. The BC supports the TF’s proposed process as transparent, neutral and supportive of the needs of the broad ICANN community, while respecting the needs of the registries/registrars and of national law. </p>
<p>The BC supports the need to have an effective resolution to conflicts between national law and ICANN contractual requirements, to the extent economically feasible and practical, while respecting the needs of the global community for WHOIS access. </p>
<p>It is important that, to the greatest extent possible, disclosure to the broader community occur, when this procedure is undertaken between a registrar and ICANN. </p>
<p>We should seek to avoid “unique solutions”, to the greatest extent possible. Transparency of processes will ensure that there is the greatest possible consistency of any solutions that are developed in dealing with conflicts that do arise. Consistent with other ongoing reviews of consensus policy, this area of policy should be monitored, and in particular Council should review how the first exception is dealt with to see if there are any lessons to be learned. </p>
<p>The BC therefore supports the TF recommendations on dealing with conflicts between national laws and registry/registrar contractual obligations to ICANN. </p>
<p><strong>Outreach for Statement on Conflicts of Law </strong></p>
<ul>
<li> The BC members were notified of the new terms of reference for the combined Task Force on 19 May 2005 </li>
<li> The statement and the issues were discussed at the Luxembourg meeting 11 July 2005. </li>
<li> A conference call was held on 26 July 2005. </li>
<li> The draft statement on Conflicts of Law was posted to the BC list on 2 August 2005 and adopted after a 14 day period. </li>
</ul>
</blockquote>
<p> </p>
<p><b>2.2 Non-Commercial User Constituency</b> </p>
<blockquote>
<p> <b>NCUC Statement on "Whois Task Force Policy Recommendation and
Advice on Whois Conflicts with National and local Privacy Laws."</b>
</p>
<p> The NCUC supports passage and quick implementation of the "Whois
Task Force Policy Recommendation and Advice on Whois Conflicts with National
Privacy Laws." The NCUC views this procedure as a stop-gap measure that
needs to be implemented pending a more comprehensive reform of the Whois
service to make it conform to ICANN's mission, national privacy laws and
international privacy norms. </p>
<p>(The NCUC also submitted input to the public comment period in the form of a background paper - "Background Statement on International Data Protection Laws: Comments to ICANN from Commissioners and Organizations regarding WHOIS and the Protection of Privacy" - requesting that the paper form part of the record of the task force proceedings. This paper is included as Annex 2 to this final task force report. Also, the summary of national laws affecting privacy, developed by the NCUC and the Registrar Constituency, is available directly from the <a href="http://www.ncdnhc.org/policydocuments/TF2Analysis-OECD%20Governments.xls">NCUC website</a>.) </p>
</blockquote>
<p> <b>2.3 Intellectual Property Constituency</b> </p>
<blockquote>
<p> This statement responds to the request for constituency input on the
Whois Task Force recommendations regarding conflicts between local law and
Whois requirements. (The call for constituency statements is available at
<a href="http://forum.icann.org/lists/gnso-dow123/msg00415.html">
http://forum.icann.org/lists/gnso-dow123/msg00415.html</a>).
</p>
<p> Pursuant
to requirements of the GSNO policy development process, outlined by
the ICANN bylaws, see Annex A, Sec. 7(d), (available at
<a href="http://www.icann.org/general/archive-bylaws/bylaws-19apr04.htm">
http://www.icann.org/general/archive-bylaws/bylaws-19apr04.htm</a>)
the IPC came to the following conclusion.
</p>
<p> The Intellectual Property Interests Constituency (IPC) generally supports
the "Policy/Advice Recommendation on conflicts between national privacy laws
and registries' or registrars' contractual obligations to ICANN." </p>
<p> While we agree with the statement by Whois Task Force 2 that "there is an
ongoing risk of conflict between a registrar's or registry's legal
obligations under local privacy laws and their contractual obligations to
ICANN," we believe this risk is generally low in the gTLD environment.
Public access to Whois and local privacy laws have coexisted for many years,
and the likelihood is that this will continue to be the case in the future.
The main reasons for this are (1) under ICANN's contracts, no domain name may
be registered in a generic Top Level Domain until the registrant has been
notified of, and consented to, the uses and disclosures that may be made of
personally identifiable data submitted in connection with the registration;
and (2) Whois data has historically been, and continues to be, collected for
the broad purpose of enabling contact with the entities responsible for a
given Internet resource. Current ICANN agreements and long-standing
registrar practices make clear that public access is one of the purposes for
which Whois data is collected. Indeed, the contractual obligations of the
Registered Name Holder depend on the public's ability to access the
information and use it. </p>
<p> However, because the risk of conflict between RAA obligations and
national law, while probably very low, is not zero, we support the idea that
ICANN should have a procedure in place for handling claims of such conflicts.
The alternative, to have no formal procedure in place for this eventuality,
could have adverse consequences. Registrars and registries might simply
unilaterally change their policies and practices so that they fail to comply
with ICANN agreements, and wait for compliance action from ICANN, if any.
This could create uncertainty, insecurity and instability in the domain name
system, and reduce uniformity of Whois policies. The result could be
confusion and frustration of the purposes of the Whois database, to the
detriment of intellectual property owners, businesses, consumers, parents,
law enforcement agencies, and others who rely upon access to it. </p>
<p> The goals for the procedure, set out in item 2 of the Consensus Policy
Recommendation, are critical: </p>
<ul>
<li> ICANN
should be made aware of a potential or asserted conflict as soon as
possible, and where appropriate ICANN should actively assist in
efforts to resolve the issue in a way that allows full compliance
with both local law and contractual obligations. For example, local
law may require that the registrar do more than the ICANN contract
requires in order to obtain a consent from the registrant, which is
legally valid under that jurisdiction's laws, for a use of Whois
data. In such a circumstance, the registrar should be required to
take those extra steps to obtain such consent, if it is practical to
do so, and if consent obtained simply by following the contractual
obligations would make the use problematic under local law.
</li>
<li> The
mechanism for recognizing an exception to contractual obligations
should be exercised only in extraordinary circumstances, and should
not be mandatory or automatic whenever efforts at resolution meet an
impasse. Recognizing exceptions could have adverse impacts on the
security and stability of the current system, and on the competitive
playing field among registrars. Conceivably, the application of some
local law could be so rigid or demanding that a registrar or registry
subject to that law simply cannot fulfill its contractual obligations
to ICANN and thus the contractual relationship must be phased out.
</li>
<li>
Finally, flexibility is critical, since we cannot now anticipate the
specific contours of a future potential conflict, and the legal
issues — beginning with which jurisdiction's law is even
applicable — may be extremely complex.
</li>
</ul>
<p> In
general, IPC believes the Recommended Procedure meets these goals and
forms a good starting point for development of the policy. The
General Counsel (or some other ICANN staff person) should be
designated to receive notifications of potential conflicts, to engage
in consultation efforts to help resolve them, and to inform the Board
and ultimately the ICANN community of any action that needs to be
taken. While this may include, in an extraordinary case, forbearance
from full enforcement of contractual obligations, it may also include
enforcement action to compel compliance.
</p>
<p> IPC
offers a few specific comments regarding the Recommended Procedure,
which it urges the ICANN staff to consider in formulating its own
procedure: </p>
<ol type="A">
<li> We
are concerned that the confidentiality provisions in Steps One, Two,
and Three could, as a practical matter, foreclose the ability of
interested parties to question or rebut the need for a departure from
the RAA on a case-by-case basis. Such an ability to question a
registrar's assertion of a conflict in a specific case is
particularly important in light of the sparse or non-existent history
of insurmountable conflicts between national laws and the RAA.
Although we agree there could be circumstance in which
confidentiality might be necessary, the policy should not favor such
requests, and in fact should specify that they would be granted only
in unusual circumstances. </li>
<li> The
statement near the end of Step One that "Meeting the notification
requirements permits Registrar/Registries to participate in
investigations and respond to court orders, regulations, or
enforcement authorities in a manner and course deemed best by their
counsel" is ambiguous. This language may be intended to provide an
incentive for registrars to comply with the notification requirements
set out in Step One. However, the consequence of failing to meet the
notification requirements is not specified. On the other hand, it
may be that this sentence is intended as an explanatory comment only.
</li>
<li>
"Step Four: Resolution" should re-emphasize the goal of
achieving uniform Whois disclosure requirements. Therefore, we
suggest amending the first sentence to read as follows: "Keeping in
the mind the anticipated impact on the operational stability,
reliability, security, or global interoperability of the Internet's
unique identifier systems, and the value of uniform Whois
requirements applying to all Registrars/Registries to the extent
possible, the Board should consider and take appropriate action on
the recommendations contained in the General Counsel's report as
soon as practicable." </li>
<li> The
Public Notice portion of the Procedure should include information
about how information made less accessible can be accessed through
other sources. For example, if a departure from the RAA resulted in
the registrant's name but not address being made available, the
notice should include information on alternative ways in which such
information might be obtained. Therefore, the final sentence of the
recommendation should be amended as follows: "Unless the Board
decides otherwise, if the result of its resolution of the issue is
that data elements in the registrar's Whois output will be removed
or made less accessible, ICANN should issue an appropriate notice to
the public of the resolution and of the reasons for ICANN's
forbearance from enforcement of full compliance with the contractual
provision in question, including relevant contact information for how
such data might be accessed in appropriate circumstances."
</li>
</ol>
<p>
</p>
<p><b> i)
If a Supermajority Vote was reached, a clear statement of the
constituency's position on the issue;</b> </p>
<blockquote>
See above.
</blockquote>
<p></p>
<p><b> (ii)
If a Supermajority Vote was not reached, a clear statement of all
positions espoused by constituency members;</b> </p>
<blockquote> N/A
</blockquote>
<p><b> (iii) A clear statement of how the constituency arrived at its
position(s). Specifically, the statement should detail specific constituency
meetings, teleconferences, or other means of deliberating an issue, and a
list of all members who participated or otherwise submitted their views;</b> </p>
<blockquote> The IPC
membership was notified of the request for a constituency statement
on June 22. A draft constituency statement was circulated on July 8.
The statement and the issue were discussed at the IPC meeting in
Luxembourg on July 11. A revised version of the statement was
circulated on July 20 and discussed on an IPC membership call on July
22. At that meeting, on a motion, which was seconded, it was agreed
without objection to approve the constituency statement, subject to
minor drafting changes.
</blockquote>
<p> <b>(iv)
An analysis of how the issue would affect the constituency, including
any financial impact on the constituency; </b>
</p>
<p> As noted
above, a sound policy in this area would benefit the constituency,
whose members rely upon public access to Whois data to manage their
domain name portfolios, enforce their rights against copyright and
trademark infringers, and combat cybersquatting, among other
purposes. The lack of a policy in this area could ultimately reduce
this access to Whois data, make access less uniform and predictable,
reduce transparency and accountability, and encourage infringers and
other violators to utilize particular registrars or registries in
order to evade detection or enforcement efforts. This would have an
adverse financial impact on constituency members.
</p>
<p> <b>(v)
An analysis of the period of time that would likely be necessary to
implement the policy </b> </p>
<p> While
this question should be directed to ICANN staff, IPC believes that
the recommended procedure is a sufficiently good starting point that
a formal procedure could be promulgated within a short time after
approval of this recommendation.</p>
<p><strong>2.3(a) </strong>O<span class="style1">on 11 October, 2005, the task force invited constituencies who wished to do so to submit a short final statement on any changes to the procedure/advice that were not accepted by the task force. One such statement was received from the Intellectual Property Constituency (IPC):</span></p>
<P class=789204214-18102005 style1 style="MARGIN: 0in 0in 0pt">"IPC continues to support the Task Force recommendation on the topic of this report. While we believe that the risk of conflict between the contractual obligations of a registrar or gTLD registry to ICANN, and the demands of national privacy laws, is very low, it is not zero, and a procedure ought to be in place for handling claims of such conflicts. We believe that the recommendation could have been improved through the adoption of three amendments which were supported by three of the six constituencies participating in the Task Force but opposed by the others, even after they were supported in the public comment period. These amendments, which are summarized in the IPC constituency statement, would have increased transparency of the process, promoted the goal of uniformity of Whois policies across gTLDs, and aided members of the public who use Whois, in the unlikely event that the conflict procedure resulted in suppression of Whois data from public access. We encourage the GNSO Council to re-examine these amendments when it considers this recommendation." </P>
<P class=789204214-18102005 style1 style="MARGIN: 0in 0in 0pt"> </P>
<P class=789204214-18102005 style1 style="MARGIN: 0in 0in 0pt">This statement was also supported by the Business Constituency and the Internet Service Providers and Connectivity Providers Constituency.</P>
<p>
</p>
</blockquote>
<p> <b>2.4
Registrar Constituency</b> </p>
<blockquote>
<p> A marked
copy of the edits to the proposal recommended by the Registrar
Constituency position is included below. These recommendations have
been reviewed by the Registrar Constituency and ratified by a
super-majority vote conducted in accordance with the Registrar
Constituency Bylaws. </p>
<p> A
summary of the recommended changes is as follows: </p>
<ol type="1">
<li>
Section II should be positioned as guidance for the staff in
establishing recommended procedures for handling WHOIS conflicts with
national law. Section II therefore would be a non-exhaustive,
non-binding suggestion rather than a consensus policy recommendation
that must be implemented as written. </li>
<li>
Section II, Step 2 should include additional language that ensures
that the registrar in question has worked with staff to identify
whether or not a solution exists that satisfies the requirements of
local law and the ICANN policy in question. </li>
<li> There
are other minor stylistic edits redlined throughout the document. </li>
<p> <b>N.B.
Additional text in section 2.4 is marked in italics and bold. Text
that is suggested for deletion is marked in strikethrough mode. </b>
</p>
<p> "<b>CONSENSUS POLICY RECOMMENDATION</b> </p>
<p> In order
to facilitate reconciliation of any conflicts between local/national
mandatory privacy laws or regulations and applicable provisions of
the ICANN contract regarding the collection, display and distribution
of personal data via Whois, ICANN should:
</p>
<ol>
<li> Develop
and publicly document a procedure for dealing with the situation in
which a registrar or registry can credibly demonstrate that it is
legally
prevented
by local/national privacy laws or regulations from fully complying
with applicable provisions of its ICANN contract regarding the
collection, display and distribution of personal data via WHOIS.
</li><li>
Create goals for the procedure which include:
<ol type="a">
<li> Ensuring that ICANN staff is informed of a conflict at the earliest
appropriate juncture; </li>
<li> Resolving the conflict, if possible, in a manner conducive to stability
and uniformity of the Whois system; </li>
<li> Providing a mechanism for the recognition, in appropriate circumstances
where the conflict cannot be otherwise resolved, of an exception to
contractual obligations <b><i>for all registrars</i></b> with regard to
collection, display and distribution of personally identifiable data via
Whois; and </li>
<li>
Preserving sufficient flexibility for ICANN staff to respond to
particular
factual
situations as they arise. </li>
</ol>
</li></ol>
<p> <b>II.
<strike>Text of Recommended</strike>
<i>Guidance</i> on Procedure</b> </p>
<p> WELL-DEVELOPED ADVICE ON A PROCEDURE FOR HANDLING WHOIS CONFLICTS WITH
PRIVACY LAW </p>
<p> Based on extensive research and negotiation among Task Force 2 together
with the merged Task Force and ICANN staff, the following procedure for
handling the policy recommendation set out in Section I above is set out as a
Recommended </p>
<p> Step-by-Step Procedure for Resolution of WHOIS Conflicts with Privacy
Law. We encourage ICANN staff to use this Recommended Procedure as a
starting point for developing the procedure called for in the Consensus
Policy Recommendation above. </p>
<p> <i>Step One: Notification of Initiation of Action</i> </p>
<p> Once receiving notification of an investigation, litigation, regulatory
proceeding or other government or civil action that might affect its
compliance with the provisions of the RAA or other contractual agreement with
ICANN dealing with the collection, display or distribution of personally
identifiable data via Whois ("Whois Proceeding"), a Registrar/ Registry must
within thirty (30) days provide ICANN's General Counsel (or other staff
member as designated by ICANN) with the following information: </p>
<ul>
<li> Summary description of the nature and status of the action (e.g.,
inquiry, investigation, litigation, threat of sanctions, etc.) </li>
<li> Contact information for the responsible official of the
registrar/registry for resolving the problem. </li>
<li> Contact information for the responsible territorial government agency or
other claimant and a statement from the registrar/registry authorizing ICANN
to communicate with those officials or claimants on the matter. If the
registrar/registry is prevented by applicable law from granting such
authorization, the notification should document this. </li>
<li> The text of the applicable law or regulations upon which the local
government or other claimant is basing its action or investigation, if such
information has been indicated by the government or other claimant. </li>
</ul>
<p> Meeting
the notification requirement permits Registrars/Registries to
participate in investigations and respond to court orders,
regulations, or enforcement authorities in a manner and course deemed
best by their counsel. </p>
<p> Depending
on the specific circumstances of the Whois Proceeding, the
Registrar/Registry may request that ICANN keep all correspondence
between the parties confidential pending the outcome of the Whois
Proceeding. It is recommended that ICANN respond favorably to such
requests to the extent that they can be accommodated with other legal
responsibilities and basic principles of transparency applicable to
ICANN operations.
</p>
<p> <i>Step
Two: Consultation</i> </p>
<p> Unless
impractical under the circumstances, we recommend that the ICANN
General Counsel, upon receipt and review of the notification and,
where appropriate, dialogue with the registrar/registry, consider
beginning a process of consultation with the local/national
enforcement authorities or other claimant together with the
registrar/registry. The goal of the consultation process should be
to seek to resolve the problem in a manner that preserves the ability
of the registrar/registry to comply with its contractual obligations
to the greatest extent possible.
</p>
<p> <i><b>The
Registrar should attempt to identify a solution that allows the
registrar to meet the requirements of both the local law and ICANN
obligations. The General Counsel can assist in advising the
registrar on whether the proposed solution meets the ICANN
obligations.</b></i> </p>
<p> If the
Whois proceeding ends without requiring any changes and/or the
required changes in registrar/registry practice do not, in the
opinion of the General Counsel, constitute a deviation from the
R.A.A. or other contractual obligation , then the General Counsel and
the registrar/registry need to take no further action.
</p>
<p> If the
registrar/registry is required by local law enforcement authorities
or a court to make changes in its practices affecting compliance with
Whois-related contractual obligations before any consultation
process can occur, the registrar/registry shall promptly notify the
General Counsel of the changes made and the law/regulation upon which
the action was based. The Registrar/Registry may request that ICANN
keep all correspondence between the parties confidential pending the
outcome of the Whois Proceeding. It is recommended that ICANN
respond favorably to such requests to the extent that they can be
accommodated with other legal responsibilities and basic principles
of transparency applicable to ICANN operations.
</p>
<p> <i>Step
Three: General Counsel analysis and recommendation</i> </p>
<p> If the
local/national government requires changes (whether before, during or
after the consultation process described above) that, in the opinion
of the General Counsel, prevent full compliance with contractual
WHOIS obligations, ICANN should consider the following alternative to
the normal enforcement procedure. Under this alternative, ICANN
would refrain, on a provisional basis, from taking enforcement action
against the registrar/registry for non-compliance, while the General
Counsel prepares a report and recommendation and submits it to the
ICANN Board for a decision. Such a report may contain:
</p>
<ol type="i">
<li> A
summary of the law or regulation involved in the conflict; </li>
<li> Specification
of the part of the registry or registrar's contractual WHOIS
</li>
<li> obligations
with which full compliance if being prevented;
</li>
<li> Summary
of the consultation process if any under step two; and
</li>
<li> Recommendation of how the issue should be resolved, which may include
whether ICANN should provide an exception for <b><strikethrough>
</b>the <b></strikethrough> <i>all</i></b>
registrars/registries from one or more identified WHOIS contractual
provisions. The report should include a detailed justification of its
recommendation, including the anticipated impact on the operational
stability, reliability, security, or global interoperability of the
Internet's unique identifier systems if the recommendation were to be
approved or denied.
</li>
</ol>
<p> The
registrar/registry should be provided a copy of the report and
provided a reasonable opportunity to comment on it to the Board. The
Registrar/Registry may request that ICANN keep such report
confidential prior to any resolution of the Board. It is recommended
that ICANN respond favorably to such requests to the extent that they
can be accommodated with other legal responsibilities and basic
principles of transparency applicable to ICANN operations."
</p>
<p> <b>End of proposed changes to the recommendation and advice.</b> </p>
<p> The Registrar Constituency proposed no changes to the remaining sections
of the procedure: <i>Step Four: Resolution</i> and <i>Step Five: Public
Notice</i> </p>
</ol>
</blockquote>
<p> <b>2.5 Registry Constituency </b> </p>
<blockquote>
<p> Pursuant to requirements of the GSNO policy development process, the
Registry Constituency (RyC) has concluded: </p>
<p> <b>I. Constituency position</b> </p>
<p> The RyC supports the general principles of the Policy/Advice
Recommendation 2 on conflicts between national privacy laws and registries'
or registrars' contractual obligations to ICANN. The RyC further believes
that the recommended procedures should deal with the possibility of the
following: </p>
<ol>
<li><p> If exceptions to contractual requirements are made to accommodate
local law(s) for one registrar or registry in a local jurisdiction, should
the same exceptions be extended to other registrars and registries in that
jurisdiction and, if so, how should that take place; and
</p></li><li> If exceptions to contractual requirements are made to accommodate local
law(s), it is possible that the variation in requirements for different
registrars or registries will begin to create a fragmented experience for
users and therefore create a need to revisit the contractual requirement in a
broader way. </li>
</ol>
<p> The RyC
also believes that the WHOIS Combined Task Force should include in
its final recommendation a further recommendation that affording
tiered access to WHOIS data be available to registrars and registries
as a means of complying with local legal requirements when
applicable. </p>
<p> <b>II. Method for Reaching Agreement on RyC Position </b> </p>
<p> The RyC drafted and circulated via email a constituency statement,
soliciting input from its members. RyC members suggested edits and additions
to the draft which were subsequently incorporated into the final constituency
statement. The statement was adopted by a unanimous vote. One constituency
member, RegistryPro did not take part in the vote. </p>
<p> <b>III. Impact on Constituency</b> </p>
<p> The Policy/Advice Recommendation 2 in its present form would assist the
members of the RyC in fulfilling their legal obligations in their respective
jurisdictions. It should be noted, however, that the Policy/Advice
Recommendation 2 does not purport to provide complete assurance that
potential conflicts can be avoided or resolved. </p>
<p> <b>IV. Time Period Necessary to Complete Implementation</b> </p>
<p> We anticipate that the Policy/Advice Recommendation 2 supported by this
statement would not require an extensive time period to implement. </p>
</blockquote>
<p> <b>2.6 Internet Service Providers & Connectivity Providers
Constituency</b> </p>
<blockquote>
<p> <b>Introduction</b> </p>
<p> The
Internet Service Providers & Connectivity Providers Constituency
(ISPCP Constituency) herein provides input to the combined Whois Task
Force on its recommendations on policies related to the Whois
database as required by the ICANN GNSO policy development process.
Specifically, the task force has put forth a recommendation on
procedures to be followed in the event of a conflict between national
privacy laws and registry/registrar contractual obligations to ICANN </p>
<p> <b>The
ISPCP constituency views on conflict of law resolution process</b> </p>
<p align="left"> The
ISPCP is generally supportive of the task force recommendations on
how conflicts shall be addressed in the event of a conflict between
the national laws of a registrar or registry's home base and its
ICANN contract.
</p>
<p> The
ISPCP does not deem such conflicts to be a common occurrence in the
gTLD or ccTLD space and further, we do not see any indicators that
this trend is likely to change in the foreseeable future. We are
guided in our belief by the examination of the record over the course
of the past several years where, in the gTLD and ccTLD space,
registries and registrars have rarely had reason to challenge their
contractual obligations related to Whois disclosures as a result of
conflicting national or local privacy laws.
</p>
<p> This was
further evidenced by the previous Whois Task Force 2 findings during
a survey completed in 2004. Within the EU member states' ccTLD
operators, those who submitted survey responses indicated that they
work closely with their respective country's data protection
authorities and are in full compliance with their respective privacy
laws.
</p>
<p> <b>ISPCP
Position</b> </p>
<p> The
majority of established privacy regimes throughout many regions of
the world require that actual information use and disclosure
practices be limited to the list of intended use and disclosure
practices that are provided to the data subject at the time of data
collection. Accordingly, once more conspicuous disclosure is
provided and consent obtained, the subsequent use of the registrant
data for Whois purposes, pursuant to the ICANN contract, is not
likely to be in conflict with local or national laws.
</p>
<p> The
ISPCP believes that once registrants receive notice of the intended
uses of their registration data as it relates to the Whois database,
there is little reason for future use in accordance with the contract
terms to somehow come in conflict with applicable privacy laws. The
likelihood of a conflict is further reduced once the more conspicuous
notice requirements go into affect, and registrants are better
alerted to the possible uses of the personally identifiable
registration data they provide.
</p>
<p> Nevertheless,
if a scenario arises whereby such conflict does arise, the ISPCP
strongly favors the implementation of a process, clearly defined and
transparent, that sets forth the steps in resolving any possible
conflict. In reviewing the proposal set forth by the Whois task
force, the ISPCP finds it to be well thought out, neutral and
respectful of the needs and interests of the ICANN community and the
registry/registrar organizations. Our constituency believes that no
organization should be placed in a situation where it must choose
between breaking its contractual obligations or violate applicable
law, and we do not believe that any of the ICANN RAA terms are likely
to do that.
</p>
<p> Based
upon the forgoing values, we strongly urge the Whois task force to
consider the following concepts prior to finalizing its policy
recommendations related to conflict of law issues.
</p>
<ul>
<li> Transparency is paramount. It is not only a major tenet of the ICANN
policy development process, it is also an implicit aspect of most privacy
laws. Without full disclosure and transparency in the manner that
information is collected and used, there can hardly be a viable notion of
privacy protection. While confidentiality of actions, negotiations and
discussions may be necessary in some instances, it is not always a
requirement or the most useful manner in which to resolve conflict. Thus,
the ISPCP believes that to the extent possible, the ICANN community be
notified when the resolution process is begun and as much as possible
throughout the process as well. </li>
<li> Outcomes should be uniform. Some have indicated that legal obstacles
will be used by registries or registrars to obtain competitive advantages,
resulting in forum shopping. The ISPCP has not seen any evidence that this
is in fact reality. Nevertheless, in order to remove the perception that
this may be happening, the recommendation should emphasize the importance of
uniformity and consistency of handling conflicts should they arise. </li>
<li> It is worthy to note that transparency of the process will inevitably
lead to more uniformity and better consistency among conflicts that do arise.
</li>
<li> Review should be ongoing. The ISPCP believes that there will be some
lessons learned from the first instance where this process is implemented.
With substantial input from the relevant registry or registrar, together with
all constituencies, there should be a review of the pros and cons of how the
process worked, and the development of revisions designed to make the process
better and more efficient, should the need arise again at some point in the
future. </li>
<li> Again, we'd like to highlight the fact that this goal will be easier met
when there is transparency and uniformity throughout the process. </li>
<li> Accuracy
is the goal. If this and other recommendations do not work towards
improved accuracy, the system will remain substantially flawed. The
ISPCP task force members have participated in good faith to achieve
the improved privacy protections that are important to community. The
constituency expects that all members of the task force, and the
chair and ICANN staff especially, show commitment to improved
accuracy and quickly move on to developing changes aimed at the same. </li>
</ul>
<b>ISPCP Conclusion</b> The
ISPCP hereby thanks the task force for its work in this matter and
looks forward to seeing a better Whois experience for all
stakeholders who develop, populate, oversee and use the Whois
databases.
<p> </p>
<p><strong>3 Public comment report</strong></p>
<p>The Public Comment Report on the preliminary task force report is based on public comments received during a public comment period from 12 September 2005 to 2 October 2005 on the <a href="http://gnso.icann.org/comments-request/">ICANN website</a>. </p>
<p>Of the 10 comments received, seven were directly relevant to the preliminary task force report. These comments have been summarised below but may be accessed in full by visiting the relevant <a href="http://forum.icann.org/lists/gnso-whoisprivacy-cmts/">public comments archive</a>. One comment - from the GNSO's Non-Commercial Users Constituency - consisted of a background document ' <font face="arial,helvetica"><font ptsize="10" family="SANSSERIF" face="Arial" lang="0"> "International Data Protection Laws: Comments to ICANN from Commissioners and Organizations Regarding WHOIS and the Protection of Privacy</font></font>'. This document does not address the specific topic of this task force report and has been included in Annex 2 of this final task force report. The remaining six public comments below are summarised in order of their publication on the ICANN website. </p>
<p> </p>
<p><strong>3.1 Comments from the International Trademark Association - WHOIS Subcommittee</strong></p>
<p>The International Trademark Association (INTA) WHOIS Subcommittee found the proposal generally to be comprehensive and thorough should issues arrise, but advocated extreme caution in order to minimise departures from compliance with the Registrar Accreditation Agreement (RAA), maintaining a level playing field and ensuring predictability for users. </p>
<p>On the issue of consent, the INTA subcommittee was unaware of any situation that would require a departure from the RAA because ICANN agreements and registrar practice make clear the purpose and use of WHOIS data and because the subcommittee is unaware of legal prohibitions against obtaining consent. The preliminary task force report of Task Force 2 (available <a href="http://www.gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html">here</a>) was not seen to demonstrate a need for departures from the RAA. Registrars are already required by the RAA to obtain registrants' consent to publication of their contact information and the INTA subcommittee believes this is sufficient to meet local privacy laws in most or all cases. ICANN's proper role is to clarify that public dissemination is an intended purpose of the data by amending the RAA rather than grant exceptions to registrars. </p>
<p class="style1">Parts of the INTA subcommittee's comments on the draft policy and procedure largely echoed those of the IPC constituency detailed above in section 2.3 of this report. Further comments were made as follows:</p>
<p class="style1">"
<font size="3"><span style="font-size: 12pt;"> B. The subcommittee questions whether the procedure in Step One should apply to a mere "investigation" that "might affect" a registrar's compliance. It may be beneficial either to provide additional definitions concerning these terms or to require that some kind of enforcement proceeding has been initiated, or that the investigation be of the specific registrar’s policies. The language of the proposed policy might encourage registrars to seek waivers every time there is some government "investigation" of any registrar’s privacy policies --or even the privacy policies of any party receiving any personal data of any kind apart from the Whois system -- under the argument that it "might affect" the registrar's compliance.</span></font> </p>
<p class="style1"> <font size="3"><span style="font-size: 12pt;"> C. The statement near the end of Step One that “Meeting the notification requirements permits Registrar/Registries to participate in investigations and respond to court orders, regulations, or enforcement authorities in a manner and course deemed best by their counsel” is ambiguous. This language appears intended to provide an incentive for registrars to comply with the notification requirements set out in Step One. However, the consequence of failing to meet the notification requirements are not specified. If this language is intended to suggest that the registrar cannot participate in investigations or respond to enforcement authorities until it has met its notification requirements, it would likely be unenforceable, so the policy should instead specify alternative, realistic, enforceable consequences; in the alternative, the sentence should be removed in its entirety to eliminate the ambiguity.</span></font> </p>
<p class="style1"> <font size="3"><span style="font-size: 12pt;"> D. In the first paragraph under "Step Two: Consultation," the last sentence should be amended to specify that the registrar must obtain consent of the registrants to the publication of their Whois data, in order to be considered as having complied with its contractual obligations to the greatest extent possible. In other words, the last sentence of the first paragraph should be amended to read as follows: “The goal of the consultation process should be to seek to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its contractual obligations to the greatest extent possible<i><u><span style="font-style: italic;">, including via obtaining consent of registrants to the publication of their Whois data</span></u></i>."</span></font> </p>
<p class="style1"> <font size="3"><span style="font-size: 12pt;"> F. The Public Notice portion of the Procedure should include information about how information made less accessible can be accessed through other sources. For example, if a departure from the RAA resulted in the registrant’s name but not address being made available, the notice should include information on how such information might be obtained or how to contact the relevant data protection authorities to gain access to the data. Therefore, the final sentence of the recommendation should be amended as follows: “Unless the Board decides otherwise, if the result of its resolution of the issue is that data elements in the registrar’s Whois output will be removed or made less accessible, ICANN should issue an appropriate notice to the public of the resolution and of the reasons for ICANN’s forbearance from enforcement of full compliance with the contractual provision in question<i><u><span style="font-style: italic;">, including relevant contact information for how such data might be accessed in appropriate circumstances</span></u></i>.”</span></font> " </p>
<p><strong>3.2 Comments by individuals:</strong></p>
<p>The Rev. D. Ceabron Williams did not directly address the procedure and advice but commented that personal information such as home telephone number and home address should not be required and should remain private.</p>
<p> Hans Klein, Director, Internet and Public Policy Project, Georgia Institute of Technology applauded the recommendations in the report, saying it was right and important that ICANN take steps to protect privacy. Mr. Klein also commented that "the proposals would be better if they were stronger. Ultimately, ICANN should not incorporate privacy law be exception but as a matter of right and principle."</p>
<p>Kenneth Coney said he was "horrified and appalled that ICANN would propose to allow Internet registrars to keep their identity private", arguing that domain name registration is a commercial privilege and not a right. If registrants do not provide their information, they should not be allowed to register domain names, Mr. Coney argued, saying that if ICANN held firm, legislators around the world would change their laws accordingly. Mr. Coney said the proposed change would affect Internet credit card purchases because the identity of firms and individuals would be harder to find out. Secondly, Mr. Coney said that it would be harder to identify and prosecute spammers. Mr. Coney questioned the motivation of those seeking to change the rules, saying this "smacks of co-conspiracy". He said the fact that potential registrants in many countries are not lobbying their legislators to bring about changes in national laws to allow registrants to "declare themselves" was "a possible indicator of nefarious intent". Mr. Coney said the comment period was too short and designed to prevent average Internet users from providing input - pointing out that MSNBC, Reuters and CNN did not mention the proposed rule change. Finally, Mr. Coney said he would not divulge who had sent him the information on the public comment period in case he "might not learn of the next proposed rule change in a timely fashion". </p>
<p><strong>3.3 Comments from the Electronic Privacy Information Center (EPIC) </strong></p>
<p>Marc Rotenberg of the Electronic Privacy Information Center (EPIC) said that EPIC supports the proposal, noting that it is "a critical first step in reforming WHOIS privacy policies, and that the proposal should be implemented immediately." EPIC's comments said the proposal would give registrants somewhat more security in their ability to apply privacy protections offered to them by law, make registrars less likely to have to choose between honouring contractual requirements under the RAA and national laws, and give certainty to registrants as to whether registrars will comply with the RAA or applicable law. </p>
<p> EPIC said a comprehensive reform of WHOIS privacy policy is crucial. The proposal creates a significant burden of proof on registrars to "prove" or "credibly demonstrate" a conflict of law, creating a high bar for a registrar to find a conflict, and possibly encouraging registrars to simply hope that the conflict will go unnoticed or be unenforced.<span class="Apple-converted-space"> </span>As the procedure only appears to deal with situations where enforcement action has already been taken, registrars who see clear conflicts between the RAA and local laws have no clear procedure to follow, and are not guaranteed an exception. This "discourages voluntary compliance with local law, and registrars must wait to be sued, prosecuted, or investigated before they may apply for an exception that would allow them to comply both with ICANN policy and the law."</p>
<div style="margin: 0px; min-height: 14px;">EPIC also said that user consent is often insufficient to reconcile these problems as a "mere boilerplate demand by registrars that users consent to Whois distribution of their private information cannot universally meet the requirements of every data protection law, present and future." Also, consent disclaimers do not protect users' privacy rights. Finally, EPIC said that ICANN should " take steps to assure the rights of Internet users, not merely recalcitrantly follow in the footsteps of various local governments" by taking " further and more thorough action to protect users' privacy."</div>
<div style="margin: 0px; min-height: 14px;"><br>
<strong>3.4 Comments from the American Intellectual Property Law Association (AIPLA)</strong></div>
<p>The American Intellectual Property Law Association (AIPLA) supported the same changes to the procedure and advice proposed by the Intellectual Property Constituency of the GNSO and supported by the International Trademark Association. These specific changes are described in section 2.3 of this document.</p>
<p>The AIPLA generally agreed with the IPC statement (section 2.3 above) and commented further that WHOIS data "should be widely and immediately available to the general public on an anonymous basis, for free, and with only limited restrictions on how the data can be used. Any exceptions to this general rule should only be applied after careful consideration, and should be targeted to specific circumstances making such an exception necessary." Along with the IPC and INTA, AIPLA said the risk of conflict between obligations under the RAA and national law is very low, and urged ICANN to "exercise caution to minimize departures from compliance with the RAA by registrars."</p>
<p><strong>3.5 Public comments report - conclusion</strong></p>
<p>Finally, the Non-Commercial Users Constituency (NCUC) submitted a public comment in the form of a background paper - "Background Statement on International Data Protection Laws: Comments to ICANN from Commissioners and Organizations regarding WHOIS and the Protection of Privacy" - requesting that the paper form part of the record of the task force proceedings. This paper is included as <strong>Annex 2 </strong>to this final task force report. </p>
<p>The WHOIS Task Force met on October 22th, 2005 to discuss the public comments received and decide if the proposal or report should be substantively changed in the light of those comments. Each comment was discussed individually and the task force decided to leave the procedure and advice unchanged, i.e. not to accept any of the proposed changes. The task force report was then updated to include summaries of the public comments. </p>
<p> </p>
<p><b>Annex
1 </b>
</p>
<p> <b>Relevant
provisions of the Registrar Accreditation Agreement</b> </p>
<p> "3.7.2
Registrar shall abide by applicable laws and governmental
regulations." </p>
<p> </p>
<p><strong>Annex 2 </strong></p>
<p><strong>International Data Protection Laws: Comments to ICANN from Commissioners and Organizations regarding WHOIS and the Protection of Privacy</strong></p>
<p> The Noncommercial Users Constituency (NCUC) feels that ICANN and the WHOIS TF must pay close attention to the authoritative formal written comments made by Data Protection Commissioners and their organizations. These opinions are exactly the type of expert input ICANN regularly asks for in its policy-making process. Further, these opinions come from those charged with interpretation, investigation and ultimately enforcement under their national laws. Ultimately, it is worthwhile to heed their advice, instruction and warnings. </p>
<p><strong><br>
A: Comprehensive Data Protection Laws – An Overview</strong><br>
The European Union, as one of its early legislative acts, created comprehensive data protection legislation for its citizens in the 1995 EU Data Protection Directive, 95/46/EC. The goal of the legislation was to “remove the obstacles to the free movement of data without diminishing the protection of personal data.” <br>
Under the EU Data Protection Directive, all EU citizens are entitled to protections in the collection and use of their personal data. The first three principles of data protection are:</p>
<br>
A. “Data must be processed fairly and lawfully.”<br>
B. “They must be collected for explicit and legitimate purposes and used accordingly.”<br>
C. “Data must be relevant and not excessive in relation to the purpose for which they are processed.”</blockquote>
<p><br>
Codified in Article 6 of the EU Directive, the law requires that these principles be adopted into the data protection laws of each Member State. Further, the Directive gives EU citizens the right to file complaints regarding violations of their data protection rights and receive compensation for certain injuries (Articles 14 and 23). It also mandates that each Member State establish one (or more) Data Protection Authorities to monitor the laws within the country, investigate, intervene, and “engage in legal proceedings” where rights are being violated (Article 28).</p>
<p><br>
The EU Directive applies directly to the 25 members of the EU: Belgium, Germany, France, Italy, Luxembourg, The Netherlands, Denmark, Ireland and the United Kingdom, Greece, Spain and Portugal, Austria, Finland, Sweden, Cyprus, Czech Republic, Estonia, Hungary, Latvia, Lithuania, Malta, Poland, Slovakia, and Slovenia.<br>
Further, very similar laws have been adopted by other countries, including Israel. In addition, Canada adopted its own version of comprehensive data protection laws called the Canadian Personal Information Protection and Electronic Documents Act (PIPEDA).</p>
<p><br>
Approximately half of all ICANN-accredited registrars are based in countries with comprehensive data protection laws, and a growing percentage of domain name registrants come from these countries as well.</p>
<p><strong><br>
B: International and National Laws Protecting Privacy of Natural Persons:</strong><br>
<em>Opinions from Leading Data Protection Authorities to ICANN</em><br>
</p>
<p>Experts on data protection laws for their countries and regions have published a number of opinions on the meaning and effect of these laws. In these carefully written opinions, the data protection authorities took the time to instruct ICANN on data protection principles, show that personal data is located in the WHOIS database, and guide ICANN towards changes to bring the WHOIS databases into compliance with international and national data protection laws.</p>
<p><br>
<strong>1. The Article 29 Data Protection Working Party</strong><br>
<em>Established by the EU Data Protection Directive 95/46, comprised of senior members of each member state’s data protection authority</em><br>
On February 2003, the Article 29 Data Protection Working Party (WP) wrote a strong opinion to ICANN and the world expressing the deep concerns of its members regarding the collection and publication of personal data in the WHOIS databases. According to Dr. Giovanni Buttarelli, Secretary-General of Italy’s Data Protection Authority and a principal author of the paper, over 25 countries worked on this opinion and it was intended to send a strong message to ICANN. </p>
<p><br>
The Article 29 WP Opinion is definitive and clear: </p>
<p><br>
a. Data Protection Commissions are receiving complaints regarding misuse of their personal data in the WHOIS databases:<br>
<em>“more and more individuals (private persons) are registering their own domain names and there have been complaints about improper use of the WHOIS data in several countries. The registration of domain names by individuals raises different legal considerations than that of companies…”</em></p>
<p><br>
b. Fundamental rights and principles of the EU Data Protection Directive do apply to the WHOIS databases:<br>
<em>“Article 6c of the Directive imposes clear limitations concerning the collection and processing of personal data meaning that data should be relevant and not excessive for the specific purpose. In that light it is essential to limit the amount of personal data to be collected and processed.”</em></p>
<p><br>
c. Changes must be made to bring the WHOIS databases into compliance with the EU Data Protection Directive:<br>
<em>“where an individual registers a domain name....there is not legal ground justifying the mandatory publication of personal data referring to this person.”</em><br>
AND<br>
<em>“In the light of the proportionality principle [of the EU Directive], it is necessary to look for less intrusive methods that would still serve the purpose of the Whois directories without having all data directly available on-line to everybody.” </em></p>
<p><br>
According to the Article 29 Working Party, it was very clear that the existing collection and publication of millions of pieces of personal data in the WHOIS database WHOIS is not consistent with the EU Data Protection Directive -- and that significant changes must be made to bring the WHOIS databases into compliance with the data protection laws and protections of the EU.</p>
<p><br>
The Article 29 WP recently repeated and affirmed this 2003 Opinion. On January 18, 2005, in a detailed statement about intellectual property owners collecting too much personal data as part of digital rights management, the Article 29 WP affirmed its deep concerns about WHOIS. </p>
<p><br>
<strong>2. International Working Group on Data Protection in Telecommunications</strong><br>
<em>National and international data protection organizations,
scientists and specialists in privacy and telecommunications</em></p>
<p><br>
Like the Article 29 WP, the International Working Group on Data Protection in Telecommunications (International WG) includes Data Protection Commissioners and international authorities on telecommunication and privacy. At the time of its opinions to ICANN in 2000 and 2003, the International WG was chaired by Dr. Hansjürgen Garstka, Commissioner for Data Protection for Berlin. The 2000 opinion (called the “Common Position”) expressed deep concerns about the WHOIS database:</p>
<p><br>
a. It stated that data protection laws clearly apply to the personal data collected and published in the WHOIS database:<br>
<em>“the collection and publication of personal data of domain name holders gives itself rise to data protection and privacy issues.”</em><br>
b. It instructed ICANN on the basic principles of data protection laws:<br>
<em>“The amount of data collected and made publicly available in the course of the registration of a domain name should be restricted to what is essential to fulfill the purpose specified.”</em><br>
c. It drew clear conclusions that the existing collection and publication of personal data for registrants in the gTLDs violates international and national data protection laws:<br>
<em>“The current Registrar Accreditation Agreement (RAA) developed by ICANN does not reflect the goal of the protection of personal data of domain name holders in a sufficient way.”</em><br>
AND<br>
<em>“The right not to have telephone numbers published - as recognized in most of the national telecommunications data protection regimes should not be abolished when registering a domain name.” </em><br>
In a follow-up letter to ICANN in 2003, the International WG repeated its position and concerns to then ICANN president Stuart Lynn. The WG urged ICANN to take its instructions and concerns into account <em>“when reshaping ICANN’s WHOIS policy.” </em></p>
<p><strong><br>
3. The European Commission, Internal Market Directorate-General</strong><br>
<em>Written opinion and speeches</em></p>
<p><br>
In January 2003, the European Commission’s Internal Market Directorate-General expressed its concerns regarding personal data in the WHOIS database in a written opinion to ICANN. The EC discussed the basic data protection principles and rights under the EU Directive. It also gave ICANN some stark orders to:<br>
<em>“limit the amount of personal data to be collected and processed”</em><br>
AND<br>
<em>“look for less intrusive methods that would still serve the purpose of the WHOIS database without having all data available to everybody.” </em></p>
<p><br>
Subsequent written comments of officials of the European Commission’s Internal Market DG to ICANN’s Government Advisory Committee (GAC) on May 12, 2003, pointed out the stark impact of WHOIS policies on citizens living in countries with comprehensive data protection rights:</p>
<p><em><br>
“It does not seem reasonable that gTLDs, which by their nature are global, should operate in a manner that results in the loss of legally established rights for a significant part of their client base.” </em></p>
<p><br>
In speeches to ICANN groups, EC Internal Market officials repeated these requirements and provided additional insight to their concerns and conclusions. At the Montreal ICANN meeting in 2003, Diana Alfonso Blas shared with ICANN the:<br>
● <em>“Need to respect the existing data protection framework in Europe, contracts can in no case overrule the law”</em><br>
● <em>“Need to look for privacy-enhancing ways to run the Whois directories in a way that serves the original purpose whilst protecting the rights of individuals”</em><br>
And the EC’s very realistic conclusion that: <br>
● <em>“not everything that might seem useful or desirable is legally possible!” </em><br>
</p>
<p>George Papavlou delivered similar points in his discussions of “WHOIS data: The EU legal principles” at the Rome ICANN meeting in 2004.</p>
<p><br>
<strong>C: The Canadian Personal Information Protection and Electronic Documents Act</strong><br>The Canadian Personal Information Protection and Electronic Documents Act (PIPEDA) went into effect on January 1, 2001. Through a phase-in process, its laws reached each private organization <em>“that collects, uses or discloses personal information in the course of a commercial activity within a province”</em> on January 1, 2004.</p>
<p><br>
On November 12, 2005, CIRA (the Canadian domain registration authority for .CA) posted for public comment its new policy to protect personal data from mandatory publication in the .CA WHOIS. Updated to comply with PIPEDA, CIRA’s new rules propose that the .CA WHOIS will list only limited technical data for individuals: the domain name, registrar’s name, registration and expiration date, date of last change , suspension (if any), the IP address and name servers. http://www.cira.ca/en/Whois/whois_policy.html.</p>
<p><br>
The exception is if the domain name registrant specifically requests publication of his/her name, address, phone, fax and email (a strict and completely voluntary “opt-in” basis). CIRA worked with the Office of the Privacy Commissioner of Canada to ensure that these WHOIS policies comply with the national data protection laws.</p>
<p><br>
It seems safe to say that today there are strong and growing expectations among Canadian domain name registrants for protection of privacy and personal data in the WHOIS databases. </p>
<p><strong><br>
D. Australia: Domain name privacy without comprehensive data protection legislation</strong><br>
In 2002 the Australian registration authority, auDA removed identifying information from the .AU WHOIS database, except for technical contact. This innovative policy applied not only to the domain name data of individuals, but also companies and organizations. According to comments posted by those involved in the process, the changes protect not only the privacy of individuals and families, but small and home-based businesses, hobbyists and those who run political, social and community websites. </p>
<p><br>
<strong>Conclusion:</strong><br>
The authorities from countries with comprehensive data protection laws have spoken clearly and frequently to ICANN. They also have been patient with the long ICANN WHOIS process. Now it is time for ICANN to listen. ICANN should recognize the warnings — that the WHOIS databases for the gTLDs do not comply with data protection laws — and act to limit the amount of personal data we collect and publish in the WHOIS databases as quickly as possible.</p>
<p><br>
In conclusion, ICANN is not above or outside national data protection laws. In every other area of Internet and telecommunications operations, companies find ways to protect personal data and run successful and profitable businesses. ICANN can and must do the same.</p>
<p><strong>Footnotes</strong></p>
<p>(1) On July 25, 2005, the Intellectual Property Constituency (IPC) submitted a “Background Paper” to ICANN ‘s WHOIS Task Force (TF); <SPAN class=023471521-25102005><FONT face=Arial><SPAN class=522095013-26102005><A title=http://forum.icann.org/lists/gnso-dow123/msg00465.html
href="http://forum.icann.org/lists/gnso-dow123/msg00465.html">http://forum.icann.org/lists/gnso-dow123/msg00465.html</A></SPAN></FONT></SPAN>. Despite an entire section that purported to analyze international and national data protection laws (Section B), not once in this section did the IPC quote or even refer to the authoritative opinions received by ICANN and the WHOIS TF from Data Protection Commissioners and their organizations, including the Article 29 Working Party established by the EU Data Protection Directive to advise and interpret the law. David Maher, longtime WHOIS TF representative from the Registry Constituency and longtime trademark attorney, called the IPC’s paper “deceptive.” He also stated that the IPC’s conclusion that EU data protection laws favor the continued the WHOIS with its full global publication of personal data to be a “distorted view” of the European Commission position. His views were so strong that Maher called on the IPC to withdraw its paper. The IPC declined. Maher email to WHOIS TF, 17 August, 2005, <a href="http://forum.icann.org/lists/gnso-dow123/msg00514.html">http://forum.icann.org/lists/gnso-dow123/msg00514.html</a>. Steve Metalitz replied on behalf of IPC on 26 August, 2005; <SPAN class=023471521-25102005><FONT face=Arial><A
title=http://forum.icann.org/lists/gnso-dow123/msg00540.html
href="http://forum.icann.org/lists/gnso-dow123/msg00540.html">http://forum.icann.org/lists/gnso-dow123/msg00540.html </A>. </FONT></SPAN></p>
<DIV dir=ltr align=left><SPAN class=023471521-25102005><FONT face=Arial
size=2></FONT></SPAN> (2) Data Protection in the EU, <a href="http://europa.eu.int/comm/justice_home/fsj/privacy/docs/guide/guide-ukingdom_en.pdf">http://europa.eu.int/comm/justice_home/fsj/privacy/docs/guide/guide-ukingdom_en.pdf</a>.</DIV>
<p>(3) Data Protection in the EU, “Rules Data Controllers Must Adhere To,” page 6.</p>
<p>(4) Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, in all languages of the EU, at <a href="http://www.epic.org/privacy/whois/">http://europa.eu.int/comm/justice_home/fsj/privacy/law/index_en.htm</a>.<br>
</p>
<p>(5) In the IPC paper, its authors concede that they do “not purport to be experts in every potential international and national law that may protect the privacy of natural persons.” It is not clear why they failed to cite the experts who have spoken on these subjects.</p>
<p>(6) See generally, Electronic Privacy Information Center, “WHOIS Discussion Gets a Dose of Privacy Law –Again,” <a href="http://www.epic.org/privacy/whois/">http://www.epic.org/privacy/whois/</a>.</p>
<p>(7) Opinion 2/2003 on the application of the data protection principles to the Whois directories, <a href="http://p2pnet.net/story/3821">http://europa.eu.int/comm/justice_home/fsj/privacy/docs/wpdocs/2003/wp76_en.pdf</a>.</p>
<p>(8) Opinion 2/2003 on the application of the data protection principles to the Whois directories, in all languages of the EU, at <a href="http://p2pnet.net/story/3821">http://europa.eu.int/comm/justice_home/fsj/privacy/workinggroup/wpdocs/2003_en.htm</a>.</p>
<p>(9) EU Warns of DRM Abuse, including full text of Article 29 WP’s Working document on data protection issues related to intellectual property rights January 18, 2005, <a href="http://p2pnet.net/story/3821">http://p2pnet.net/story/3821</a>.</p>
<p>(10) International Working Group on Data Protection in Telecommunications, Common Position on Privacy and Data Protection in Telecommunications, May 4/5 2000,
<a href="http://www.datenschutz-berlin.de/doc/int/iwgdpt/dns_en.htm">http://www.datenschutz-berlin.de/doc/int/iwgdpt/dns_en.htm</a>. </p>
<p>(11) Letter from Hansjürgen Garstka to Stuart Lynn Regarding Whois Issues, 15 January 2003, <a href="http://www.icann.org/correspondence/garstka-to-lynn-15jan03.htm">http://www.icann.org/correspondence/garstka-to-lynn-15jan03.htm</a>.</p>
<p>(12) Contribution of the European Commission to the general discussion on the Whois database raised by the Reports produced by the ICANN Whois Task Force, January 22, 2003;
<a href="http://www.dnso.org/dnso/notes/ec-comments-whois-22jan03.pdf">http://www.dnso.org/dnso/notes/ec-comments-whois-22jan03.pdf</a>.</p>
<p>(13) Whois Data, Brussels, 12 May 2003 (copy in NCUC archives).</p>
<p>(14) Diana ALONSO BLAS, LL.M., European Commission, DG Market, Unit Data Protection and Media, June 23, 2003, Privacy and Data protection consideration of the Whois directories discussion, powerpoint slides (copy in NCUC archives).</p>
<p>(15) Interestingly, the IPC paper used Canada and Canadian opinion to conclude that Canadians expect and want all their personal data (including home addresses, home phone numbers and personal email addresses) to be publicly published in the WHOIS data published. In light of the actual changes taking place in Canada, it is puzzling why the IPC would issue a public statement with conclusions that are completely contrary to Canadian direction.</p>
<p>(16) AU Privacy Policy, <a href="http://www.auda.org.au/policies/auda-2002-10/">http://www.auda.org.au/policies/auda-2002-10/</a>.</p>
<p></p>
<p> </p>
<p><strong> Annex 3 Results of Task Force indicative straw poll on proposed changes to the recommendation and advice </strong></p>
<p>On 6 September, 2005 the Task Force held an informal and purely indicative 'straw poll' of task force members to ascertain the level of support for specific proposed changes to the recommendation and advice. The text of those proposed changes and the informal level of support for each is illustrated in the table below. </p>
<table width="794" border="1">
<caption>
Indicative 'straw poll' on proposed changes to recommendation & advice
</caption>
<tr>
<td width="476"><strong>PROPOSED REVISION </strong></td>
<td width="302"><strong>STRAW POLL VOTE </strong></td>
</tr>
<tr>
<td><DIV>
<p><strong>Proposed revision 1 </strong></p>
<p>Paragraph 2 (c) of the policy recommendation would be changed to the following (insertion marked in bold italics):</p>
</DIV>
<DIV><BR class=khtml-block-placeholder>
</DIV>
<DIV><SPAN><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px">"c.</SPAN></FONT><SPAN
style="mso-spacerun: yes"><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px"> </SPAN></FONT></SPAN><FONT
class=Apple-style-span face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px">Providing a mechanism for the recognition, if appropriate, in </SPAN></FONT><SPAN style="mso-spacerun: yes"><FONT
class=Apple-style-span face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px"></SPAN></FONT></SPAN><FONT class=Apple-style-span
face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px">circumstances where the conflict cannot be otherwise resolved, of an exception to contractual obligations <B><I>to those registries/registrars to which the specific conflict applies</I></B> </SPAN></FONT></SPAN><SPAN><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px">with regard to collection, display and distribution of personally identifiable data via Whois; and </SPAN></FONT></SPAN><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px"></SPAN></FONT>
<DIV style="mso-element: comment-list">
<DIV style="mso-element: comment">
<DIV language=JavaScript class=msocomtxt id=_com_1
onmouseover="msoCommentShow('_anchor_1','_com_1')"
onmouseout="msoCommentHide('_com_1')"><SPAN style="mso-comment-author: "
Buchanan?? A\. Jordyn><FONT class=Apple-style-span face=Arial size=4></FONT></SPAN><FONT class=Apple-style-span face=Arial
size=4><SPAN class=Apple-style-span style="FONT-SIZE: 16px"></SPAN></FONT>
<DIV class=MsoCommentText><BR class=khtml-block-placeholder>
</DIV>
<DIV class=MsoCommentText>Similarly, sub-paragraph iv of Step Three would be replaced with the following (changes marked in bold italics again):</DIV>
<DIV class=MsoCommentText><BR class=khtml-block-placeholder>
</DIV>
<DIV class=MsoCommentText><SPAN><FONT class=Apple-style-span face=Arial
size=4><SPAN class=Apple-style-span style="FONT-SIZE: 16px">Recommendation of how the issue should be resolved, which may include whether ICANN should provide an exception <B><I>for those registrars/registries</I></B></SPAN></FONT></SPAN><SPAN><FONT
class=Apple-style-span face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px"><B><I> to which the specific conflict applies </I></B>from one or more identified WHOIS contractual provisions. The report should include a detailed justification of its recommendation, including the anticipated impact </SPAN></FONT><SPAN><FONT class=Apple-style-span face=Arial
size=4><SPAN class=Apple-style-span style="FONT-SIZE: 16px">on the operational stability, reliability, security, or global interoperability of the </SPAN></FONT></SPAN><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px">Internet's unique identifier systems if the recommendation were to be approved or denied</SPAN></FONT><SPAN><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px">. " </SPAN></FONT></SPAN></SPAN></DIV>
</DIV>
</DIV>
</DIV>
</DIV></td>
<td><p><strong>Vote to accept the revision</strong>:</p>
<p>6 votes - NCUC (Milton Mueler),
CBUC (Marilyn Cade, David Fares, Sarah Deutsch), IPC (Steve Metalitz, Niklas Lagergren) </p>
<p> </p>
<p><strong>Votes to reject the revision:</strong></p>
<p>4 votes - Registry C. (David Maher, Tuli Day, Ken Stubbs,), Registrars C. (Tim Ruiz, only registrar on call, Jordyn does not<br>
vote).</p>
<p><strong>Revision 1 accepted by the task force </strong></p></td>
</tr>
<tr>
<td><p><strong>Proposed revision 2 </strong></p>
<p>Adding an additional paragraph to the end of the policy recommendation, as follows:
</p>
<DIV><BR class=khtml-block-placeholder>
</DIV>
<DIV class=MsoNormal><A style="mso-comment-reference: JAB_1"><SPAN><FONT
class=Apple-style-span face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 14px">"3) Registrars and registries may use tiered access as a means of complying with local legal requirements when applicable.</SPAN></FONT></SPAN></A>"</DIV></td>
<td><strong>Revision 2 rejected by the task force </strong></td>
</tr>
<tr>
<td><p><strong>Proposed revision 3 </strong></p>
<p>The proposal would replace the last paragraph of step one as follows:
</p>
<DIV> </DIV>
<DIV><SPAN><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px">"Depending on the specific circumstances of the Whois Proceeding, the Registrar/Registry may request that ICANN keep all correspondence between the parties confidential pending the outcome of the Whois Proceeding, <B><I>although throughout the entire procedure (including later steps) confidentiality should only be granted in those circumstances where it is necessary, keeping in mind the</I></B></SPAN></FONT></SPAN><SPAN><SPAN style="mso-spacerun: yes"><FONT
class=Apple-style-span face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px"><SPAN class=Apple-style-span
style="TEXT-DECORATION: line-through"> </SPAN></SPAN></FONT></SPAN><FONT
class=Apple-style-span face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px"><SPAN class=Apple-style-span
style="TEXT-DECORATION: line-through">It is recommended that ICANN respond favorably to such requests to the extent that they can be accommodated with </SPAN>other legal responsibilities and basic principles of transparency applicable to ICANN operations.</SPAN></FONT><SPAN
style="mso-spacerun: yes"><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px"> " </SPAN></FONT></SPAN></SPAN></DIV></td>
<td><p><strong>Vote to accept the revision</strong>:</p>
<p> 6 votes - CBUC (Marilyn Cade and proxy for David Fares, Sarah Deutsch), ISP (Tony Harris), IPC (Steve Metalitz, Niklas Lagergren).</p>
<p><strong>Votes to reject the revision:</strong> </p>
<p>6 votes - Registry C. (Tuli Day, David Maher, Ken Stubbs), NCUC (Milton Mueller), Registrars C (Tim Ruiz) (Ross Rader was against on the list).</p>
<p><strong>Revision 3 rejected by the task force </strong></p>
<p> </p></td>
</tr>
<tr>
<td><p><strong>Proposed revision 4</strong></p>
<p>The proposal is to add a paragraph to Step Two of the guidance on the procedure. The new paragraph would be inserted between the current first and second paragraphs: </p>
<DIV><BR class=khtml-block-placeholder>
"<SPAN><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px">The Registrar should attempt to identify a solution that allows the registrar to meet the requirements of both the local law and ICANN obligations.</SPAN></FONT><SPAN
style="mso-spacerun: yes"><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px"> </SPAN></FONT></SPAN><FONT
class=Apple-style-span face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px">The General Counsel can assist in advising the registrar on whether the proposed solution meets the ICANN obligations."</SPAN></FONT></SPAN></DIV>
</td>
<td><strong>Revision 4 accepted by the task force </strong></td>
</tr>
<tr>
<td><p><strong>Proposed revision 5</strong></p>
<p>The proposal is to add text to the end of the first sentence of Step Four. The new sentence would read: </p>
<DIV>"<SPAN><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px">Keeping in the mind the anticipated impact </SPAN></FONT><SPAN style="COLOR: black"><FONT
class=Apple-style-span face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px">on the operational stability, reliability, security, or global interoperability of the </SPAN></FONT></SPAN><FONT class=Apple-style-span
face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px">Internet's unique identifier systems, <B><I>and the value of uniform Whois requirements applying to all Registrars/Registries to the extent possible</I></B></SPAN></FONT></SPAN><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial; mso-ansi-language: EN-US"><FONT
class=Apple-style-span face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px">, the Board should consider and take appropriate action on the recommendations contained in the General Counsel’s report as soon as practicable.</SPAN></FONT><SPAN style="mso-spacerun: yes"><FONT
class=Apple-style-span face=Arial size=4><SPAN class=Apple-style-span
style="FONT-SIZE: 16px">" </SPAN></FONT></SPAN></SPAN></DIV>
</td>
<td><p><strong>Vote to accept the revision</strong>:</p>
<p>5 votes - CBUC (Marilyn Cade, Sarah Deutsch), ISP (Tony Harris), IPC (Steve Metalitz, Niklas Lagergren)
</p>
<p><strong>Votes to reject the revision:</strong> </p>
<p>5 votes - Registry C. (Tuli Day, David Maher, Ken Stubbs), Registrars C. (Tim Ruiz), NCUC (Milton Mueller) </p>
<p><strong>Revision 5 rejected by the task force </strong></p>
<p> </p></td>
</tr>
<tr>
<td><p><strong>Proposed revision 6</strong></p>
<p>This change would add text to the last sentence of Step Five. The new sentence would read: </p>
<DIV>"<SPAN><FONT class=Apple-style-span face=Arial size=4><SPAN
class=Apple-style-span style="FONT-SIZE: 16px">ICANN should issue an appropriate notice to the public of the resolution and of the reasons for ICANN’s forbearance from enforcement of full compliance with the contractual provision in question<B><I>, including relevant contact information for how such data might be accessed in appropriate circumstances</I><SPAN class=Apple-style-span
style="FONT-WEIGHT: normal">."</SPAN></B></SPAN></FONT></SPAN></DIV>
</td>
<td><p><strong>Vote to accept the revision</strong>:</p>
<p>5 votes - CBUC (Marilyn Cade, (proxy David Fares, Sarah Deutsch), ISP (Tony Harris, (proxy Maggie Mansourkia), IPC (Steve Metalitz, Niklas Lagergren)<br>
</p>
<p><strong>Votes to reject the revision:</strong> </p>
<p>5 votes - Registry C. (Tuli Day, David Maher, Ken Stubbs), NCUC (Milton Mueller), Registrars C. (Tim Ruiz)</p>
<p><strong>Revision 6 rejected by the task force</strong>
</p>
</td>
</tr>
<tr>
<td><p><strong>Proposed revision 7</strong></p>
<p>This change would add a new Step Six to the guidance on the procedure. The new section would read as follows: </p>
<DIV>"<A style="mso-comment-reference: JAB_1"><SPAN
style="FONT-FAMILY: Arial"><FONT class=Apple-style-span face=Arial><I>Step Six:</I></FONT><SPAN style="mso-spacerun: yes"><FONT class=Apple-style-span
face=Arial><I> </I></FONT></SPAN><FONT class=Apple-style-span
face=Arial><I>Ongoing Review</I></FONT><FONT class=Apple-style-span
face=Arial><O:P></O:P></FONT></SPAN></A></DIV>
<DIV class=MsoNormal><SPAN style="mso-comment-continuation: 1"><SPAN
style="FONT-FAMILY: Arial"><I><FONT class=Apple-style-span
face=Arial></FONT></I><FONT class=Apple-style-span
face=Arial><O:P></O:P></FONT></SPAN></SPAN></DIV>
<DIV class=MsoNormal><SPAN style="mso-comment-continuation: 1"><SPAN
style="FONT-FAMILY: Arial"><FONT class=Apple-style-span face=Arial>With substantial input from the relevant registries or registrars, together with all constituencies, there should be a review of the pros and cons of how the process worked, and the development of revisions designed to make the process better and more efficient, should the need arise again at some point in the future."</FONT></SPAN></SPAN></DIV></td>
<td><p><strong>Vote to accept the revision</strong>:</p>
<p>8 votes - Registry C. (Tuli Day, David Maher, Ken Stubbs), CBUC (Marilyn Cade, Sarah Deutsch), ISP (Tony Harris), IPC (Steve Metalitz, Niklas Lagergren)<br>
</p>
<p><strong>Votes to reject the revision:</strong> </p>
<p>2 votes - NCUC (Milton Mueller),
Registrars C. (Tim Ruiz)</p>
<p><strong>Revision 7 accepted by the task force </strong><br>
</p></td>
</tr>
</table>
<p><br>
</p></td>
</tr>
<tr>
<td> </td>
</tr>
</tbody></table>
</td>
</tr>
</tbody></table>
<center>
<hr noshade="noshade" size="1" width="95%">
<p><font size="-1">Comments concerning the
layout, construction and functionality of this site <br>
should be sent to <a href="mailto:webmaster@icann.org">webmaster@icann.org</a>.</font><br>
<font size="-1"> This file last modified 12-Sep-2005</font>
<br><font size="-2">©2005 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.</font></p>
</center>
</body></html>