ICANN/GNSO GNSO Email List Archives


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

RE: [whois-sc] DRAFT 3 of Task force 1

  • To: "'Bruce Tonkin'" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>, whois-sc@xxxxxxxx
  • Subject: RE: [whois-sc] DRAFT 3 of Task force 1
  • From: Steve Metalitz <metalitz@xxxxxxxx>
  • Date: Tue, 7 Oct 2003 11:58:59 -0400
  • Sender: owner-whois-sc@xxxxxxxxxxxxxx

Bruce,  these all look fine to me with two exceptions (the last two
"in-scope" paragraphs).  See my suggestions in CAPS in the text below.  

Your redline version reflects that the next to last in-scope paragraph was
"removed at the request of members of the registrars constituency."  Your
first paragraph refers to comments "from registrars that were not directly
represented on the call."  My recollection is that there was a
representative of the registrar constituency on the call, so I don't
understand this reference.  Additionally, this deletion was not discussed on
the call (as far as I recollect, and your first paragraph seems to indicate
that this was the case), so at a minimum I suggest that the reason for the
proposed deletion be circulated to the list by the constituency proposing
it.  Pending that circulation, I suggest this language be restored.  

The revision to the last in-scope paragraph completely deletes one of its
two original foci so my proposed language (in CAPS) would seek to restore
that.  I recall that one member of the Steering Group articulated a moral
objection to such value-added services, but the existing RAA recognizes that
they perform a useful function, and I suggest that the impact of any
recommended changes on the viability of such services is an appropriate
topic for proposed Task Force 1.   


Steve Metalitz  

-----Original Message-----
From: Bruce Tonkin [mailto:Bruce.Tonkin@xxxxxxxxxxxxxxxxxx]
Sent: Friday, October 03, 2003 9:32 AM
To: whois-sc@xxxxxxxx
Subject: [whois-sc] DRAFT 3 of Task force 1

Hello All,

The attached draft 3 is an enhancement of Draft 1 (presented at the 1st
teleconference), and Draft 2 (modified by Steve Metalitz and presented
at the last teleconference).  This text incorporates comments received
during the call, and also from registrars that were not directly
represented on the call.

Look for [** to detect changes, or see attached red-line copy.

I invite further input, with the view to finalising by Friday 10 Oct

Bruce Tonkin

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 (the 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 [** REPLACE must ensure that groups ** WITH** should
consider the effects of any proposed policy changes on the ability of
groups ] such as law enforcement, intellectual property, internet
service providers, and consumers to continue to retrieve information
necessary to perform their functions.

RESTORE THE FOLLOWING DELETED TEXT [** DELETE 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).]

[** REPLACE The task force must ensure that any access restrictions do
not restrict the competitive provision of value-added services using
WHOIS information (for example, services that are provided competitively
for the purpose of intellectual property protection), nor restrict the
transfer of domain name records between registrars.
WITH** The task force should consider the effects of any proposed policy
changes on the competitive provision of domain name services including

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
the subject of a recent update in policy in March 2003.

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]

[** REPLACE 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.
provided to registrants.
**WITH** Each milestone should be subject to development internally by
the task force, along with an appropriate public comment processes (e.g
seeking specific advice from the technical community, or from WHOIS
service operators)  to ensure that as much input as possible is taken
into account.]

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