[dow2tf] A Compromise Proposal
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
clarifications.
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
registrar.
â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 |