ICANN/GNSO GNSO Email List Archives

[whois-sc]


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

[whois-sc] DRAFT 4 of Task force 2

  • To: <whois-sc@xxxxxxxx>
  • Subject: [whois-sc] DRAFT 4 of Task force 2
  • From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Date: Tue, 14 Oct 2003 17:50:54 +1000
  • Sender: owner-whois-sc@xxxxxxxxxxxxxx
  • Thread-index: AcOSJ+Sni1C2Jry9Ssi7h9MW5zUCNA==
  • Thread-topic: DRAFT 4 of Task force 2

Hello All,

I have attached a new draft of task force 2.

I have incorporated the comments from Tom Keller and also Steve
Metalitz's comments (but stopped short of actually adding methods of
improving accuracy to this task force).  

Note with respect to documenting local privacy laws, I have added
documenting "examples" of local privacy laws.  As Steve has pointed out
we can't hope to comprehensively deal with all local laws, but we can be
informed by some examples of local laws that may assist us in the policy
development process.

For now I think we should refine terms of reference for a task force
that specifically looks at accuracy issues.  These accuracy issues will
generally apply to any outcomes of task force 1 and 2 - ie it is a
mostly independent area of activity - although there are benefits in
studying all three together.  I think further improvements in accuracy
can be made while addressing some of the longer term policy issues
associated with which data elements should be collected, and who should
have access to them.  I am working with the ICANN President to ensure
that we can get staff support to attempt to operate all three task
forces together.  There seems to be reasonable support (based on a
recent teleconference I have had with the chairs/liaisons of the other
groups) from the other areas of ICANN to address the issues identified
so far by the GNSO WHOIS Steering Group.

I will have another go at developing a terms of reference for the
accuracy task force based on Steve's comments on task force 2, and the
WHOIS Privacy issues report.

I will schedule another teleconference to discuss accuracy for:
Tuesday 21 Oct, 2pm Los Angeles, 5pm Washington DC time, 10pm London,
7am (wed) Melbourne

I have marked up the changes since the last draft in the attached
document, and also in the text below.

Regards,
Bruce


Title: Review of data collected and displayed

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:
==========================

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.  [** INSERT In
this regard it should be mentioned that there already is existing local
law in several jurisdictions regulating this matter.]


At the same time, domain names, associated email addresses, and web
sites located by domain names can be used in connection with fraud,
criminal activity, and intellectual property infringement.  This gives
rise to a need for accurate identification of the registrant, and/or a
need to reliably contact the individual or organization that is the
registered name holder.  [** INSERT Many users of Whois perceive that
there is an unacceptable level of inaccuracy in Whois data that
compromises its ability to facilitate identifying and contacting
registrants.]

Similar trade-offs between privacy concerns and identification affect
the technical functions of Whois.  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. 

Identifiers in other media typically attempt to balance identification
and privacy concerns.  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.  [** INSERT Similarly, the ability of persons whose
data is listed in various public registers to opt out of public
disclosure of these items may be limited.]

Although the GNSO has in the past adopted new policies (See
http://www.icann.org/gnso/whois-tf/report-19feb03.htm) regarding the
accuracy of data and bulk access, the prior Task Force chose to defer
considerations of privacy to a future point.

Another issue is that there is limited public understanding of the
present contractual obligations, 
[** INSERT including the obligations to disclose to those who provide
data the uses to which it will be put, and to obtain their consent.]
 Most domain name holders are [** INSERT probably] unaware that their
information is being displayed publicly via the present port-43 and
interactive web access methods,
or is made available to third parties under the bulk WHOIS access
agreement.

The purpose of this task force is to determine:


a) 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?

b) What 
[**REPLACE is the minimum required information about 
** WITH changes, if any, should be made in the data elements] 
about registrants that must be collected at the time of registration to
maintain adequate contact-ability?

c) 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, [** INSERT by
which registrants], 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?   
[** MOVED FROM OUT OF SCOPE If registrants have the ability to withhold
data from public, anonymous access will this increase user incentives to
keep the contact information they supply current and accurate.]

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.

Out-of-scope
============

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, as this will be subject of a separate
task force. 

[** MOVED TO IN SCOPE SECTION 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. 


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

1. 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. 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 
[** REPLACE minimal ** WITH optimal]
 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, [** INSERT whether any different
elements should be added or substituted to improve contact-ability,]
 and [** DELETE if so,] how [** REPLACE they WITH the data] may be
acquired with the greatest accuracy, least cost, and in compliance with
applicable privacy, security, and stability considerations.

3. Document existing methods by which registrants can maintain anonymity
and assess their adequacy. 
[** INSERT Document examples of existing local privacy laws in regard to
display/transmittal of data.]   
Decide what options [** INSERT if any] will be given to registrants to
remove data elements from public access and what contractual changes (if
any) are required to enable this.

4. Taking into account the outcomes in 2 and 3, re-examine the methods
by which registrars inform registrants of the use of their contact data
by third parties and the options registrants might have to remove data
elements from public view.




Attachment: Draft4taskforce2.doc
Description: Draft4taskforce2.doc



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