ICANN/GNSO GNSO Email List Archives


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

RE: [whois-sc] WHOIS sc teleconf : Task force 2 modifications

  • To: "'gnso.secretariat@xxxxxxxxxxxxxx'" <gnso.secretariat@xxxxxxxxxxxxxx>, whois-sc@xxxxxxxxxxxxxx
  • Subject: RE: [whois-sc] WHOIS sc teleconf : Task force 2 modifications
  • From: Steve Metalitz <metalitz@xxxxxxxx>
  • Date: Thu, 2 Oct 2003 15:22:24 -0400
  • Sender: owner-whois-sc@xxxxxxxxxxxxxx

Well then, in the same spirit of posting everything twice.......

-----Original Message-----
From: 	Steve Metalitz  
Sent:	Wednesday, October 01, 2003 6:25 PM
To:	'whois-sc@xxxxxxxx'
Subject:	Proposed terms of reference for our call tomorrow  

Here is a suggested revision of the terms of reference for the data mining
task force as circulated by Bruce just before our previous call.  As I
mentioned then, I found the use of the term "bulk access" in that draft
somewhat confusing.  This revision does not propose a lot of substantive
changes but tries to use some of the terminology in a manner more consistent
with our past usage.  I would be glad to send or post a redline version if
anyone is interested in seeing just what changes I am suggesting.  

Steve Metalitz

Title: Restricting  access to WHOIS data for marketing purposes

- 1 representative from each constituency
- ALAC liaison
- GAC liaison
- ccNSO liaison
- SECSAC liaison
- liaisons from other GNSO WHOIS task forces

Description of Task Force:

In the recent policy recommendations relating to WHOIS:
(see http://www.icann.org/gnso/whois-tf/report-19feb03.htm)
it was decided that the use of bulk access WHOIS data for marketing
should not be permitted.  However, these recommendations did not directly
address the issue of marketing uses of Whois data obtained through either of
the other contractually required means of access:  Port 43 and web-based.
Bulk access under license may be only a minor contributor to the perceived
problem of use of Whois data for marketing purposes. A subset of a
registrar's Whois database that is sufficiently large for data mining
purposes may be obtained through other means, such as a combination of using
free zonefile access (via signing a registry zonefile access agreement - the
number of these in existence approaches
1000 per major registry) to obtain a list of domains, and then using
anonymous (public) access to either port-43 or interactive web pages to
retrieve large volumes of contact information.
Once the information is initially obtained it can be kept up-to-date by
detecting changes in the zonefile, and only retrieving information
related to the changed records.   This process is often described as
"data mining".  The net effect is that large numbers of Whois records are 
easily available for marketing purposes, and generally on an anonymous basis
holders of this information are unknown).

The purpose of this task force is to determine what contractual changes
(if any) are required to allow registrars to protect domain name holder
data from data mining for the purposes of marketing  The focus is on the
technological means that may be applied to achieve these objectives and
whether any contractual changes are needed to accommodate them.  

The purpose of this section to clarify the issues should be considered
in proposing any policy changes.

The task force must ensure that groups such as law enforcement,
intellectual property, internet service providers, and consumers can
continue to retrieve information necessary to perform their functions.
In some cases this may require the provision of searching facilities
(e.g that can return more than one record in response to a query) as
well as look-up facilities (that only provide one record in response to
a query).

The task force must ensure that any access restrictions do not restrict
the competitive provision of value-added services using WHOIS information
example, services that are provided competitively for the purpose of
intellectual property protection), nor restrict the transfer of domain name
records between

To ensure that the task force remains narrowly focussed to ensure that
its goal is reasonably achievable and within a reasonable time frame, it
is necessary to be clear on what is not in scope for the task force.

The task force should not aim to specify a technical solution.  This is
the role of registries and registrars in a competitive market, and the
role of technical standardisation bodies such as the IETF.  Note the
IETF presently has a working group called CRISP to develop an improved
protocol that should be capable of implementing the policy outcomes of
this task force. However, the task force should seek to achieve an
understanding of the various technological means that could be applied to
prevent or inhibit data mining with an eye toward evaluating their impact on
other uses and their compatibility with the currently applicable contracts.

The task force should not review the current bulk access agreement
Provisions, except to the extent that these can be improved to enhance
protection against marketing uses and to facilitate other uses.   These were
the subject of a recent update in policy in March

The task force should not study the amount of data available for public
(anonymous) access for single queries.  Any changes to the data
collected or made available will be the subject of a separate policy
development process.


- collect requirements (e.g., volume, frequency, format of query results)
from non-marketing users of contact information
(this could be extracted from the Montreal workshop and also by GNSO
constituencies, and should also include accessibility requirements (e.g
based on W3C standards)
[milestone  1 date]
- review general approaches to prevent automated electronic data mining
and ensure that the requirements for access are met (including
accessibility requirements for those that may for example be visually
[milestone 2 date]
- determine whether any changes are required in the contracts to allow
the approaches to be used above   (for example the contracts require the
use of the port-43 WHOIS protocol and this may not support approaches to
prevent data mining)
[milestone 3 date]

Each milestone should be subject to development internally by the task
force, along with a public comment process to ensure that as much input
as possible is taken into account.

-----Original Message-----
From: GNSO SECRETARIAT [mailto:gnso.secretariat@xxxxxxxxxxxxxx]
Sent: Thursday, October 02, 2003 3:08 PM
To: whois-sc@xxxxxxxxxxxxxx
Subject: [whois-sc] WHOIS sc teleconf : Task force 2 modifications

[To: whois-sc@xxxxxxxxxxxxxx]

The Task Force 2 proposed terms of reference were modified by Milton Mueller
on September 24. Please find the modified version below for discussion
during the WHOIS Steering committee teleconference scheduled at:

9am Wellington, New Zealand (3 October)
7am Melbourne, Australia (3 October)
5pm, Washington, DC, USA (2 October)
6pm, Buenos Aires, Brazil (2 October
2pm, California, USA (2 October)
10pm, London, UK     (2 October)
11pm, Bonn, Germany  (2 October)

GNSO Secretariat

Milton Mueller wrote:
I have made some modifications and additions to
Bruce's original draft, keeping within its spirit but
narrowing the focus and adding milestones.

Title: Review of data collected and displayed

- 1 representative from each constituency
- ALAC liaison
- GAC liaison
- ccNSO liaison
- SECSAC liaison
- liaisons from other GNSO WHOIS task forces

Description of Task Force:

There are domain name holders that are concerned about their privacy,
both in terms of data that is collected and held about them, and also in
terms of what data is made available to other parties.

Extensive contact information can assist a registrar or network provider
to contact a domain name holder in the event of a technical problem or
in the event of domain name expiration.  However, a domain name
holder may be prepared to make a personal decision to accept a lower
standard of service (e.g take their own steps to be reminded of when a
domain expires) in return for greater privacy.  A domain name holder
may be prepared to provide extensive contact information to their domain
name provider, but would prefer to control what information is available
for public access.  For example a telephone customer may provide
detailed address information to a telephone service provider, but may
elect not to have this information displayed in a public whitepages
directory.  Note however that national laws often permit access to the
complete information to groups such as law enforcement and emergency
services personnel.  Another issue is that there is limited public
understanding of the present contractual obligations.  Most domain name
holders are unaware that their information is being displayed publically via
the present port-43 and interactive web access methods.

The purpose of this task force is to determine:

a) What is the minimum required information about registrants that
must be collected at the time of registration to maintain adequate

b) Should domain name holders be allowed to remove certain
parts of the required contact information from anonymous (public)
access, and if so, what data elements can be withdrawn from public
access and what contractual changes (if any) are required to enable
this? Should registrars be required to notify domain name holders when
the withheld data is released to third parties?

c) What is the best way to inform registrants of what information about
themselves is made publicly available when they register a domain
name and what options they have to restrict access to that data and
receive notification of its use?

To ensure that the task force remains focussed and that
its goal is achievable and within a reasonable time frame, it
is necessary to be clear on what is out of scope for the task force.


The task force should not examine the mechanisms available for
anonymous public access of the data - this is the subject of a separate
task force.

The task force should not examine mechanisms for law enforcement
access to the data collected.  This is generally subject to varying local
laws, and may be the subject of a future task force.

The task force should not study new methods or policies for ensuring
the accuracy of the required data. However, it should study
whether giving registrants the ability to withhold data from public,
anonymous access will increase user incentives to keep the contact
information they supply current and accurate.

The task force should not consider issues regarding registrars' ability
to use Whois data for their own marketing purposes, or their claims
of proprietary rights to customers' personal data.

This Task Force would begin at the same time as the other one and
execute its duties in the following order:

1. Conduct an analysis of the existing uses of the registrant data
elements currently captured as part of the domain name registration
process. Develop list of minimal required elements for  contact-ability. The
intent is to determine whether all of the data
elements now collected are necessary for current and foreseeable
needs of the community, and if so, how they may be acquired with
the greatest accuracy, least cost, and in compliance with applicable
privacy, security, and stability considerations. 4-5 months?

2. Decide what options will be given to registrants to remove data
elements from public access and what contractual changes  (if any) are
required to enable this. 3 months?

3. Examine the current methods by which registrars and their resellers
inform registrants of the purpose for which contact data is collected,
and how that data will be released to the public. Examine whether policy
changes (or published guidelines) are necessary to improve how this
information is provided to registrants. 2 months?

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