RE: more discussion on call of 13 April 2004: [dow1tf] Summary of Points from Last Call (6 April 2004)

[Paul Stahura <stahura@xxxxxxxx>]

On the Tech contact part:
I thought the idea was more like this:

suggestion for technical contact information: instead of displaying 
technical contact information, a means would be available via 3rd party 
(e.g. registrar) to send a message to the technical contact without
displaying the contact data

Than this

suggestion for technical contact information: instead of displaying 
technical contact information, a means would be available via 3rd party 
(e.g. registrar) to obtain data


-----Original Message-----
From: owner-dow1tf@xxxxxxxxxxxxxx [mailto:owner-dow1tf@xxxxxxxxxxxxxx] On
Behalf Of Barbara Roseman
Sent: Tuesday, April 13, 2004 9:05 AM
To: dow1tf@xxxxxxxxxxxxxx
Subject: more discussion on call of 13 April 2004: [dow1tf] Summary of
Points from Last Call (6 April 2004)

this version represents further discussion from the call today (13 April
2004).

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

d) creates an incentive for the person to make the data innaccurate.

>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

Registrant email

>         *       Admin Contact Phone Number
>         *       Admin Contact Fax Number

Admin contact email

>         *       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
>         *

suggestion for technical contact information: instead of displaying 
technical contact information, a means would be available via 3rd party 
(e.g. registrar) to obtain data

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

beyond the technical capacity of the average registrar (potential burden to 
registrars in terms of bandwidth and server capacity)


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

implication for how ICANN contracts are structured in terms of conflicts in 
law (what if local law contradicts ICANN contract) -- Keep competition 
equitable, so what happens if there is an advantage or disadvantage because 
of national law. Which company's laws are applicable to the contract. 
Structure contract for least common denominator?

>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 legitimate users

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

Legitimate users should have a process that is simple, effective, and 
timely for their access. It will require additional work to determine who 
constitutes a "legitimate user."

Action item: look back at first Whois taskforce data to see if this issue 
of sharing restricted information has been discussed already? Particularly 
look for .name information about burden of costs involved in notification 
practices. [Tony Harris]

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

except as it imposes a burden to registrar resources

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