ICANN/GNSO GNSO Email List Archives


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

[dow2tf] A Compromise Proposal

  • To: dow2tf@xxxxxxxxxxxxxx
  • Subject: [dow2tf] A Compromise Proposal
  • From: KathrynKL@xxxxxxx
  • Date: Mon, 3 May 2004 00:14:11 EDT
  • Sender: owner-dow2tf@xxxxxxxxxxxxxx

To All:
In the interest of advancing our debate, the following compromise proposal is 
submitted. It has been put together by a number of members of this 
Constituency to advance the debate of our TF and to find a common ground as we move 
forward to our report and presentation of our findings and proposals.  In doing 
so, the NCUC does not withdraw its name/email proposal, but moves also to 
support this Registrars Proposal, as revised with slight modifications and 

We assure you that no one Constituency will be happy with the terms of this 
compromise, and therein may lie the basis of a true compromise.  We call on all 
members of the TF2 to support this revised Registrars proposal and move 
together to a solid report of our work.  

[Edit note: Sections left unchanged from the Registrars proposal are in 
quotes.  Those with modifications are in bold.]

âThe recent data collection of Task Force (TF) 2 and the analysis of a sample 
of existing national privacy regulations and domain name registries' policies 
has shown that there is an increasing awareness of privacy rights in an 
increasing number of countries all around the world. Depending on the countriesâ 
cultural and historical perspectives, their views with respect to what is 
allowed or appropriate in terms of privacy vary. This variety of views does not 
allow us to find a common denominator that would allow a  âone size fits allâ 
policy. Instead, it requires local and national rules in order to truly enable 
and promote international competition, per ICANN principles. As a consequence, 
the general rule should be that: 

    âNo Registrar should be forced to breach its local laws regarding the 
collection, display and distribution of personal data in order to be able to 
provide ICANN approved domain registrations, regardless of whether the WHOIS 
service is provided by such registrar or another party under agreement with such 

âEnabling and promoting competition - per the ICANN principles - would not 
allow the disadvantaging of any registrar. A registrar may be disadvantaged in 
this way if a customer were to transfer his domain names away to a registrar in 
a  âbetter protected jurisdiction.â Therefore a uniform low standard for the 
display of WHOIS data must be set, unless local legislation prohibits doing 
so. Both the data fields and the format must be standardized, although 
technical standardization for the formatting can be left to bodies like the IETF.â

âAnother such disadvantage is the Bulk whois obligation. According to a 
recent presentation by George Papapavlou, Bulk whois is not acceptable under the EU 
Privacy Directive and in many other jurisdictions and can not be enforced in 
those countries. Therefore, TF 2 should recommend striking this obligation in 
order to establish a level playing field for all registrars world-wide.â

âThe issue of which data elements should be published on the whois has been 
passionately discussed over the last several months, with many good reasons 
brought forth both by the parties claiming to need the data for various 
legitimate uses, as well as those advocating that personal data should not be displayed 
due to the potential misuse. After much discussion, registrars have found a 
solution that balances these viewpoints. The ways the data is accessed and used 
makes it impossible to control. In fact the data subject does not know 
what happens to his data and is actually disadvantaged in comparison with the 
data user.â

âConsequently, it would be a big step in the right direction if access to 
sensitive whois data would not be anonymous, but that the party requesting the 
data identify itself and its use of the data in a reliable and standardized 
manner before personal contact data is revealed.â

âFollowing this reasoning WHOIS access can be divided into three levels: 
     1. Data displayed to an anonymous user 
     2. Data displayed to a known user for a known use 
     3. Data displayed to an administrative entity like a Registrarâ

âAll of these levels have to be treated in a different way to maintain the 
balance at one hand and allow administrative actions on the other. 

â1. Data displayed to an anonymous user 

âData displayed to an anonymous user should consist of the following elements 
unless the Registrant or Registrar decides to provide more data:@

    â1.1 Name of the Registrant 
     1.2 Country of the Registrant 
     1.3 Name of the Admin-C 
     1.4 Country of the Admin-C 
     1.5 Name of the Technical Contact
     1.6 Country of the Technical Contact 
     1.7 Point of contact of the Technical Contact i.e. a website  
     1.8 Nameserver names 
     1.9 Registrar of Record 
     1.10 Creation date 
     1.11 The non-auto renewed expiration date 
     1.12 The date the WHOIS information last changed 
     1.13 The domain name itselfâ
âHaving in mind the different uses the whois data is subject to nowadays, it 
is the general view of the Registrar Constituency that the whois service was 
originally established solely to facilitate contacts for technical reasons.â

â2. Data displayed to a known user with known useâ

To enter a Tier 2 request which reveals sensitive/personal data, the party 
requesting the data (the data user) shall identify itself and its use of the 
data in a reliable and standardized manner, to include:
-  its name, address, email and phone number data in a manner which can be 
reliably and automatically verified and authenticated. 
-  State a specific reason out of a still to be established list
-  State a detailed reason for seeking out the sensitive/personal data in a 
short narrative form, (e.g, specific evidence of a legal conflict).  
-  The domain name data requested 
-  Any additional requirements as TF2 recommends.

The data requestor shall agree, upon clear notice and affirmative consent, 
that it will confine its use of the sensitive/personal data solely to the 
specific purpose it entered in the request form, and shall not use the data for any 
secondary purpose.  Further, the data requestor shall affirmatively agree not 
to use the data received for impermissible uses, including spam, direct 
marketing, identity theft, harassment and stalking.  âIt shall be mentioned that not 
all uses of the data as well as the system are permissible and can be ground 
for an exclusion of a user from the system.â

The registrar shall authenticate the requestor and check the completeness of 
the request. Upon compliance with all requirements, the requestor shall be 
eligible to access tier 2 data for that domain name. 

The âdata displayed to a known user with known useâ by individual request â
should consist out of the following elements, unless the Registrant or 
Registrar decides to provide more data:
     2.1 Name of the Registrant 
     2.2 Postal Address of Registrant 
     2.3 Name of Admin-C 
     2.4 Postal Address of Admin-C 
     2.5 Name of the Technical Contact 
     2.6 Postal Address of the Technical Contact 
     2.7 Email Address of the Technical Contact 
     2.8 Telephone number of the Technical Contact 
     2.9 Nameserver information 
     2.10 Registrar of record 
     2.11 Creation date 
     2.12 The non-auto renewed expiration date 
     2.13 The date the WHOIS information last changed 
     2.14 The domain name itselfâ

These requests should be very clearly directed, and the facilities for the 
search, per concerns raised by the European Union, shall include the following 
limitations:  no mass queries, no wildcards, and no cross-object searches. 

Upon delivery to the data requester of a Tier 2 request for 
sensitive/personal data, the Registrar shall, as a default setting, immediately send to the 
domain name registrant, in realtime, by email to the Registrant's listed email 
address, the following data:

1.1  The data requesterâs name, address and phone number
1.2  The method of verification used, and if applicable, the 3rd party who   
verified or certified the data
1.3  The specific reason (out of a still to be established list of acceptable 
uses) and the detailed reason the data requester provided for its access to 
the Tier 2 data
1.4  The domain name itself (for those with multiple domain names)
1.5  And a date and time stamp showing clearly the date and time that the 
name and address were delivered to the data requester.  (While registrars may 
choose to give registrants the option to receive these messages in non-realtime, 
such as once in a week in a cumulative form, the default for notification 
regarding release of sensitive/personal data shall be immediate email.)
1.6 Additional data the registrar may deem appropriate.
"3. Data displayed to an administrative entity like a Registrar or Registry 

âThis level should not be viewed as whois data, but as data necessary for 
administrative means like transfers. Potentially the data would not be displayed 
through the whois service, but made available to the administrative entity by 
other services or protocols like EPP. To ensure that all needed data is 
readily available, such a service must provide at least the following elements 

          â3.1 Name of the Registrant 
     3.2 Postal Address of the Registrant 
     3.3 Email Address of the Registrant 
     3.4 Name of the Admin-C 
     3.5 Postal Address of Admin-C 
     3.6 Email Address of the Registrant 
     3.7 Name of the Technical Contact 
     3.8 Postal Address of the Technical Contact 
     3.9 Email Address of the Technical Contact 
     3.10 Telephone number of the Technical Contact 
     3.11 Nameserver information 
     3.12 Registrar of record 
     3.13 Creation date 
     3.14 The non-auto renewed expiration date 
     3.15 The date were the WHOIS information last changed 
     3.16 The domain name itselfâ



Attachment: Revised Registrar Proposal 5_3.doc
Description: Binary data

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