ICANN/GNSO GNSO Email List Archives

[whois-sc]


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

[whois-sc] Draft 5 of Task force 2

  • To: <whois-sc@xxxxxxxx>
  • Subject: [whois-sc] Draft 5 of Task force 2
  • From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 22 Oct 2003 15:38:11 +1000
  • Sender: owner-whois-sc@xxxxxxxxxxxxxx
  • Thread-index: AcOYXq1q2xwZN/6hRUqwSJ8LWjor8w==
  • Thread-topic: Draft 5 of Task force 2

Hello All,

Attached is a new red-line draft of Task Force 2.  I require comments on
this draft within the next 24 hours.  I believe I have taken into
account the discussion on the mailing list.

The main changes are:

Description - removed the term "public register" as it seems to have
different meanings to different people, I have kept the sense of the
original wording that in other public databases there are some options
to opt-out of data, and there are some items of data that must be
displayed.

Purpose (b) - I have made the wording of the purpose more open to
reflect that a balance must be achieved between contactability and
privacy.    I note from a privacy point of view the question is often
phrased as "what is the minimal amount of information necessary for the
purpose".  From a contactability point of view the question might be
phrased as "what is the optimal amount of information for
contactability, whilst providing mechanisms for protecting privacy".  I
have chosen somewhere in between these two wording approaches.

Task (2) - has been extensively rewritten.  I have extended the focus to
look not only at the registrant data but also the domain name related
data as suggested by Mark Jeftovic, I have added wording similar to the
purpose (b), and I have explicitly added the option that the some
elements may be made voluntary.  I have removed the accuracy term as
that is the subject of a separate task force (or working group of a task
force :-)).  Of course any new data elements that the task force
recommends would also need to be subject to methods to achieve accuracy
at reasonable cost.  The task force could consider the likelihood of
achieving accuracy with a particular data element without going into
details on how to achieve accuracy.    This would be part of the balance
between contactability and privacy.  I would assume that if you reduce
the amount of information displayed, a trade off might be much better
accuracy for the data elements that are displayed.  The task force could
conclude that accuracy of a particular data element would need to be
improved.  For example it may be easier to achieve an accurate email
address, than it is to achieve an accurate postal address on a global
basis.

See below for a plain text markup.  Changes marked [**

Regards,
Bruce Tonkin



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.  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.  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.  Similarly, the ability of persons 
[** DELETE whose data is listed in various public registers ]
to opt out of public disclosure of 
[** REPLACE these items WITH some data ] 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, 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 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 changes, if any, should be made in the data elements about
registrants that must be collected at the time of registration to 
[** REPLACE maintain adequate contactability WITH achieve an acceptable
balance between the interests of those seeking contact-ability, and
those seeking privacy protection]?

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, 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? 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. 

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.  
[** REPLACE Develop list of optimal required elements for
contact-ability.   WITH Develop a list of data elements about
registrants and their domains that must be collected at the time of
registration to achieve an acceptable balance between the interests of
those seeking contact-ability, and those seeking privacy protection?]
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 of the current elements should be made
voluntary,]
 whether any different elements should be added or substituted to
improve 
[** REPLACE contact-ability WITH the balance between contact-ability and
privacy], and how the data may be acquired 
[** DELETE 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. Document examples of existing local privacy
laws in regard to display/transmittal of data.   Decide what options 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: Draft5taskforce2.doc
Description: Draft5taskforce2.doc



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