<<<
Chronological Index
>>> <<<
Thread Index
>>>
[gnso-dow123] Final task force report on Recommendation 2 - procedure & advice for conflicts with national laws
- To: "'Whois TF mailing list'" <gnso-dow123@xxxxxxxxxxxxxx>
- Subject: [gnso-dow123] Final task force report on Recommendation 2 - procedure & advice for conflicts with national laws
- From: "Maria Farrell" <maria.farrell@xxxxxxxxx>
- Date: Wed, 19 Oct 2005 15:22:01 +0200
Dear all,
Attached is the final task force report on recommendation 2, as discussed on
last week's WHOIS call. I have included the IPC's follow-up statement and
the public comments report. Also included is an annex that describes the
task force straw poll taken to informally ascertain support for the 7
proposed changes to the recommendation and advice which this task force
discussed on 30 August, 2005. For the moment, the voting record is not
available for each proposed revision. However, these will be added next
week when they are available.
I would be very grateful if you could review the final task force report and
post any revisions or corrections to the list. Could I please have your
comments by close of business on Friday, 21 October? Once the task force is
satisfied with this document, Jordyn will submit it to the GNSO Council for
discussion at its next meeting.
All the best, Maria
<!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> 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
http://gnso.icann.org/issues/whois-privacy/tor2.shtml). </p>
<p> Task
Force 2's preliminary report was published for public comment in
June 2004 (available at
http://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html).
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><span
class="style1">Also at this meeting, 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 2.3 (a) below.
</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> <b>Background</b> </p>
<p> Constituencies have been invited to provide input on the Whois Task Force
Terms of Reference Items 1 (Purpose) and 2 (Purpose of WHOIS contacts). This
statement has been prepared in accordance with the GNSO policy development
process criteria for "Constituency Statements". (see annex). </p>
<p> Related documents: </p>
<ul>
<li> Call
for constituency statements on Tasks 1&2 of Whois Task Force </li>
<li> Terms
of Reference, (available at
<a href="http://forum.icann.org/lists/gnso-dow123/msg00416.html";>
http://forum.icann.org/lists/gnso-dow123/msg00416.html</a>).
</li>
<li> Terms
of Reference (available at
<a href="http://gnso.icann.org/policies/terms-of-reference.html";>
http://gnso.icann.org/policies/terms-of-reference.html</a>)
</li>
</ul>
<p> <b>1. Purpose of the Whois Database. </b> </p>
<ul>
<li> The
Internet has evolved from its early days of technical
experimentation and has become a key medium for commerce and a rich
source of information and resources for users. The purpose of the
Whois database as the primary resource of contact information must
therefore reflect this evolution.
</li><li>ICANN's
responsibility for stability and security are highly relevant to an
accurate Whois.
</li><li> The
Registrar Accreditation Agreements (RAA) maintained by ICANN
require, as a pre-requisite to the registration of a domain name,
the inclusion of the administrative, technical and contact details
into a publicly accessible Whois database. The RAA also mandates
that registrants receive notification of the public accessibility of
this information.
</li><li> The
BC supports having clear and easy to find "notice" of both the
collection and the display of data.
</li><li> The
BC also notes that registrants are able to use agents as contact
points should anonymous registration be desired. In any case, the
correct data should be collected, and maintained by the agent, for
provision upon legitimate request.
</li></ul>
<p> With the
above in mind, the BC proposes the following purpose of the Whois
database:
</p><blockquote>
A database of contact information sufficient to contact the registrant or
their agent(s) to enable the prompt resolution of technical, legal and other
matters relating to the registrant's registration and use of its domain name.
</blockquote>
<p></p>
<p> <b>Effect
on the Constituency, including financial impact</b> </p>
<p> BC members rely on accurate WHOIS data to engage in a number of important
actions, including: verification of who holds a particular name;
trademark/domain name portfolio management; contacting a registrant due to
network or phishing attacks originating from a particular domain; engaging in
trademark protection, cooperation with law enforcement and consumer
protection authorities when investigation of illegal activity in a domain;
contacting a registrant to make an offer to purchase an existing
registration, etc. </p>
<p> The BC believes that this policy will have a positive impact on the
Constituency, and will help to limit the costs to business users. We do not
believe that there is any cost associated with this policy since it is
essentially maintaining the status quo. </p>
<p> <b>Analysis of the period of time that would likely be necessary to
implement the policy</b> </p>
<p> Little
time would be needed for implementation, since this is essentially
the status quo. </p>
<p> <b>2. Purpose of WHOIS contacts</b> </p>
<p> The BC believes there is a need to clarify the information that should be
provided in the three categories defined in the Transfers Policy and to use
consistency of terminology. </p>
<p> <b>Terminology</b> </p>
<p> The Transfers policy uses the term "domain holder" in place of
"Registered Name Holder". The BC recommends that these two terms are treated
as interchangeable with each other. </p>
<p> <i>a. Registered Name Holder</i> </p>
<p> The Registered Name Holder is the registrant and thus responsible for the
domain name registration generally, including for canceling or transferring a
name. This individual's or the organisation's name and contact should be
provided in this category. </p>
<p> <i>b. Technical Contact</i> </p>
<p> The technical contact is responsible for responding to inquiries related
to the technical functioning of the web site and to deal with any technical
problems. An individual competent to respond to those kinds of inquiries
should be provided in this category. </p>
<p> (If a registrant chooses to use their ISP or other third party as the
technical contact, that changes in no way the need for accurate data for the
Registered Name Holder). </p>
<p> <i>c. Administrative Contact</i> </p>
<p> The Administrative Contact may be responsible for dealing with the
content on the web site and is responsible to the registered name holder,
unless they are the same person. The BC supports the definition in the
Transfers policy: </p>
<p> The Administrative Contact is: "an individual, role, or organization
authorized to interact with the Registry or Registrar on behalf of the Domain
Holder. The administrative contact should be able to answer non-technical
questions about the domain name's registration and the Domain Holder. In all
cases, the Administrative Contact is viewed as the authoritative point of
contact for the domain name, second only to the Domain Holder." </p>
<p> Note: the holder, technical and administrative contacts may be one and
the same. </p>
<p> <b>Effect on the Constituency, including financial impact</b> </p>
<p> This policy will have a positive impact on the BC and more broadly for
all Internet users who need to check Whois data for policing domain names,
deal with network problems and phishing attacks; check out a web site to see
with whom they are doing business, or where their children are finding
information, etc. by enhancing the accuracy and usability of the Whois
database. </p>
<p> There should be no financial impact on the constituency as a result of
this policy. It is possible that there may be minimal costs to the
Registrars if they are not fully complying with the present RAA. Any costs
would be related to the provision, in automated form, of descriptive
information of what is recommended to fill each separate category. </p>
<p> An analysis of the period of time that would likely be necessary to
implement the policy. </p>
<p> An implementation working group, to include representation from the user
constituencies, but largely to include Registrars, should be established.
The implementation time frame should be short. </p>
<p> <b>3. Outreach process</b> </p>
<p> The ICANN bylaw that outlines the GNSO policy development process
(section 7.d) states: </p>
<p> "<i>1. Constituency Statements. The Representatives will each be
responsible for soliciting the position of their constituencies, at a
minimum, and other comments as each Representative deems appropriate,
regarding the issue under consideration. This position and other comments,
as applicable, should be submitted in a formal statement to the task force
chair (each, a "Constituency Statement") within thirty-five (35)
calendar days after initiation of the PDP. Every Constituency Statement
shall include at least the following:</i> </p>
<p> <i>(i) If a Supermajority Vote was reached, a clear statement of the
constituency's position on the issue;</i> </p>
<p> <i>(ii) If a Supermajority Vote was not reached, a clear statement of all
positions espoused by constituency members;</i> </p>
<p> <i>(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;</i>
</p>
<p> <i>(iv) An analysis of how the issue would affect the constituency,
including any financial impact on the constituency; and</i> </p>
<p> <i>(v) An analysis of the period of time that would likely be necessary
to implement the policy."</i> </p>
<p> With respect to (i), (ii) and (iii) the BC approval process allows for a
14 day comment period for a position to be adopted combined where appropriate
with meetings and member calls. </p>
<p> <b>Statement on purpose</b> </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
TF reps prepared a draft purpose statement and posted it to the
Constituency on 19 July 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 Purpose was posted to the BC list on 2 August
2005 and adopted after a 14 day period.
</li></ul>
<p> <b>Statement on purpose of contacts</b> </p>
<ul>
<li> The
BC members were notified of new terms of reference for the combined
Task Force on 19 May 2005
</li><li> The
forthcoming draft statement on Purpose of Contacts was discussed at
the Luxembourg meeting 11 July 2005.
</li><li> BC
members were asked to participate in a Contacts survey on 22 July
2005
</li><li> A
conference call was held on 26 July 2005.
</li><li> The
draft statement on Purpose of Contacts was posted to the BC list on
2 August 2005 and adopted after a 14 day period.
</li></ul>
</blockquote>
<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 NCUC's summary of national laws
affecting privacy 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>
</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.
<strikethrough> Text of Recommended </strikethrough>
<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>
</p>
<p>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>
Unlike the EU or Canada, Australia does not have comprehensive data
protection legislation. Its data protection is sectoral and legislation is
adopted “as needed” for areas (e.g., financial data and health
care). Despite this sectoral approach, Australia was one of the first countries
to make wholesale changes to limit the availability of personal data in its
WHOIS database.</p>
<p><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).
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,
8/17/05, <a
href="http://forum.icann.org/lists/gnso-dow123/msg00514.html";>http://forum.icann.org/lists/gnso-dow123/msg00514.html</a>.</p>
<p>(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>.</p>
<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 30 August, 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>SUPPORT</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> </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> </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> </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> </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> </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> </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> </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@xxxxxxxxx";>webmaster@xxxxxxxxx</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>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|