ICANN/GNSO GNSO Email List Archives

[whois-sc]


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

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

  • To: Tom Keller <tom@xxxxxxxxxx>, Steve Metalitz <metalitz@xxxxxxxx>
  • Subject: RE: [whois-sc] DRAFT 3 of Task force 1
  • From: Steve Metalitz <metalitz@xxxxxxxx>
  • Date: Thu, 9 Oct 2003 11:43:28 -0400
  • Cc: "'Bruce Tonkin'" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>, whois-sc@xxxxxxxx
  • Sender: owner-whois-sc@xxxxxxxxxxxxxx

Tom,

Thanks for your prompt contribution. I don't object to dropping this
sentence from the Terms of Reference but offer the following comments.

First, as Bruce's post pointed out, the availability (or not) of search
capability remains a relevant issue here because that is the kind of
value-added service that can be achieved through bulk access but not
(currently) through either of the other contractually required methods of
access to Whois data.

Second, just a reminder that ICANN's General Counsel rendered an opinion in
2000 that registrars were in fact required under the RAA to offer more than
simple look-up capability on the domain name only.  In other words, we are
not talking here about adding a new obligation.

Finally, regarding your reference to local privacy laws, can you be more
specific about which search capabilities are prohibited by which privacy
laws?  Feel free to respond off line if that would be more appropriate. 

Steve Metalitz     

-----Original Message-----
From: Thomas Keller [mailto:tom@xxxxxxxxxx]
Sent: Thursday, October 09, 2003 10:40 AM
To: Steve Metalitz
Cc: 'Bruce Tonkin'; whois-sc@xxxxxxxx
Subject: Re: [whois-sc] DRAFT 3 of Task force 1


Hello Steve,
   
as Bruce already pointed out correctly there is a dissent inside the
Registrar Constituency in regard to the implementation of further search
capabilities. Please note that the RC was always supportive of the needs 
of legitimate parties, but lacking a contractual or other definition of a 
"legitimate party" there is a general feeling that the development of such 
a service might bring the registrars into a situation where they would have 
to bear the costs for no benefit in return plus an extended possibility for 
detailed data mining. Besides the cost factor there is the problem that 
extensive search capabilities are often prohibited by local privacy laws.

In light of these difficulties I would like to suggest that the sentence in 
question is not included into the draft.

Best,

tom


Am 07.10.2003 schrieb Steve Metalitz:
> 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.   
> 
> Thanks.
> 
> 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
> 2003.
> 
> Regards,
> Bruce Tonkin
> 
> 
> Title: Restricting  access to WHOIS data for marketing purposes
> 
> Participants:
> - 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.  
> 
> In-scope
> ========
> 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
> WHOIS access and transfers, AND ON THE COMPETITIVE PROVISION OF
VALUE-ADDED
> SERVICES USING WHOIS INFORMATION.]
> 
> 
> Out-of-scope
> ============
> 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 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.
> 
> Tasks/Milestones
> ================
> 
> - 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
> impaired)
> [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.]
> 
> 

Gruss,

tom

(__)        
(OO)_____  
(oo)    /|\	A cow is not entirely full of
  | |--/ | *    milk some of it is hamburger!
  w w w  w  



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