ICANN/GNSO GNSO Email List Archives

[dow1tf]


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

[dow1tf] Summary of Points from Last Call

  • To: "'dow1tf@xxxxxxxxxxxxxx'" <dow1tf@xxxxxxxxxxxxxx>
  • Subject: [dow1tf] Summary of Points from Last Call
  • From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
  • Date: Sun, 11 Apr 2004 21:38:48 -0400
  • Sender: owner-dow1tf@xxxxxxxxxxxxxx

All,

Here are the major points we gathered from the last call.  None of these are
final positions, but they represent our thinking as of the last call.

Please be ready to comment on this on Tuesday's call:

1)  The output of this Whois Task Force depends heavily on the output of
Whois TF 2 (which data elements are included in the publicly available
WHOIS).  The more sensitive the data: (a) the more value there is to the
data; (b) the more likely such data is to be mined and (c)the more this
impacts the privacy rights of individuals.  In such cases, there may be a
need to restrict access to that data.  In our call, we grouped the
individual data elements of Whois into three categories:  1)  Sensitive
Data; 2) Non-Sensitive Data; 3) Data which may be sensitive (i.e., where
there was disagreement).  

Sensitive Data:  

	*	Registrant Phone Number
	*	Registrant Fax Number
	*	Admin Contact Phone Number
	*	Admin Contact Fax Number
	*	Registrant Address Line 1 (i.e., exact street address)
	*	Admin Contact Address Line 1

Non-Sensitive Data

	*	Domain Name
	*	Domain ID
	*	Registrar Name
	*	Registrar ID
	*	Name Server Name
	*	Technical Contact Name
	*	Technical Contact Address (Full information)
	*	Technical Contact Phone Number
	*	Technical Contact Fax Number
	*	Technical Contact e-mail address

Data Which May Be Sensitive (More exploration needed)

	*	Expiration Date
	*	Creation Date
	*	Registrant Name
	*	Registrant E-mail Address
	*	Registrant Address Line 2 (i.e., City, State Zip, Country)
	*	Admin Contact Name
	*	Admin Contact E-mail Address
	*	Admin Contact Address Line 2 (i.e., City, State Zip,
Country)

2) It is believed that if only "Non-Sensitive Data" is to be publicly
displayed (whether on the Web, Port 43 or other automated process), the data
itself has little value, is less likely to be data mined, and has little
effect on privacy rights.  Therefore, imposing restrictions on access to
Non-Sensitive data may not be necessary. 

3)  To the extent that restrictions are imposed on access to Whois
information, this should not be taken to mean that we are addressing all of
the privacy implications nor the entire problem of data mining.  In
addition, as in all cases, National law, as applicable, should be taken into
consideration.

4)  To the extent that Sensitive Data is required to be publicly disclosed
by Whois TF 2, then at a minimum, the requestor of Whois information
("Requestor") should be required to identify themselves to the Whois
Provider (i.e., the Registrar or the Registry [in the case of thick
registries]) along with the reasons for which it seeks the data.  Such
information should be made available to the registrant whose Whois
information is sought ("Registrant").  The group recognizes, however, that
an exception may need to be granted to certain law enforcement officials who
may need the information without having to provide the reasons to the
Registrant.  This point needs to be explored more.

IP Const:  This process should not delay the timely delivery of Whois
information.  In addition, all IP attorneys should fall within this
exception.

ALAC:  IP Owners should not fall within this exception.

Questions:  Who is law enforcement?  How would this be done?

5)  The group has not proposed any mechanisms to deal with Whois information
displayed through the Web except that it was recognized that Web-based GUIs
(i.e., CAPTCHA), is not an effective block for data mining, although it was
acknowledged that it has provided an important obstacle in many cases.

6) What to do about Port 43?

The group discussed this in great length.  

	a)	Currently, Port 43 does not provide a way for a requestor to
identify him or herself or the reasons for which it is seeking the data.  
	b)	If only Non-sensitive Data is displayed, there is little
reason to change anything with respect to Port 43.
	c)	If Sensitive Data will be displayed, then Port 43 not be
able to provide the functionality described in Section 4 above.
	d)	The Group may not be fundamentally opposed to an automated
mechanism to retrieve Sensitive Data as long as the Requestor is identified
and that information is disclosed to the Registrant.


7)  Other Ideas

In addition, if Port 43 were retained, the group discussed the possibility
of having a central authority (not a registry or registrar) to approve
entities that could use Port 43 (i.e., a "White List" of IP addresses).  In
this scenario, a White List would be created of Requestors that have proven
themselves as "legitimate users" of Whois information (i.e.,  Law
Enforcement, Consumer organization, Intellectual Property Organizations,
etc.)  This list would be provided to the registries and registrars and only
those Requestors sending requests through Port 43 would be allowed to access
the Whois information.  Questions arose concerning (a) who would operate
this White List, (b) what would be the criteria for being on this White
List, (c) whether it was actually feasible to implement; and a (d) process
for dealing with abuses.

The group is working on specific questions on the development of a White
List mechanism.

Please feel free to comment.


Jeffrey J. Neuman, Esq. 
Director, Law & Policy 
NeuStar, Inc. 
Loudoun Tech Center 
46000 Center Oak Plaza 
Building X 
Sterling, VA 20166 
p: (571) 434-5772 
f: (571) 434-5735 
e-mail: Jeff.Neuman@xxxxxxxxxx 




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