ICANN/GNSO GNSO Email List Archives


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

RE: [whois-sc] DRAFT 3: Task force 2

  • To: <whois-sc@xxxxxxxx>, <metalitz@xxxxxxxx>, <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Subject: RE: [whois-sc] DRAFT 3: Task force 2
  • From: "Milton Mueller" <Mueller@xxxxxxx>
  • Date: Thu, 09 Oct 2003 18:45:08 -0400
  • Sender: owner-whois-sc@xxxxxxxxxxxxxx

Hi, all
Most of Steve's changes are unacceptable. I do not
object to clarifying the role of accuracy in the TF if in fact
such a consideration explicitly recognizies the role of
greater privacy and more limited data collection in ensuring 
greater accuracy. We do need to keep the TF focused, and
I see in Steve's modifications a dangerous and unwelcome
attempt to completely change the topic of the TF.

To take it one by one:

>>> Steve Metalitz <metalitz@xxxxxxxx> 10/09/03 04:03PM >>>
>[+++ 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

We have already defined inaccuracy as out of scope except
insofar as it is related to the user's inability to protect
their own data from disclosure. So this addition would have
to be modified as follows:

"While many users of Whois perceive that inaccuracy in Whois 
data compromises its ability to facilitate identifying and 
contacting registrants, others have asserted that the use of 
inaccurate or less than optimal contact data by registrants 
may be due to its public, anonymous accessibility."

>{+++INSERT+++ The Security and Stability Advisory Committee
>has expressed concerns about the impact of inaccurate Whois data on the
>ability to contact needed parties when technical problems arise.]

No. IF in fact SECSAC has expressed such concerns (and where
is the citation?) I would have to see the context, because the idea 
that the stability of the Internet rests upon contacting any individual 
registrant of a SLD, is a very hard case to make. I would challenge any 
assertion to that effect. In general the "stability of the Internet" hand
has been overplayed so often that the bluff needs to be called. Some
of us actually have a pretty good idea of how DNS works. 

>[+++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 very limited.]

Here we have a nice tautology: you can't prevent "public disclosure"
of information in "public registers." But of course that begs the
question: is Whois a public register or not? How public should it
be? That is precisely the issue the TF is supposed to resolve. 
That statement has to go.

>b) What {+++ INSERT +++ changes, if any, should be made in 
>the data elements] {+++ DELETE +++ is the minimum required 
>information] about registrants that must
>be collected at the time of registration [+++INSERT+++ ,and 
>the manner of their collection and maintenance,] to maintain 
>adequate contact-ability [+++INSERT+++ ,including data reliability]?

Completely unacceptable. 

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

I can see where this is going. Let me just remind Steve that 
the TF itself could easily move toward classification of registrants 
whether or not this modification is added. So why waste
our time on this type of modification? 

>The task force should [+++DELETE+++ not] study 
>new methods or policies for
>ensuring the
>accuracy of the required data,  
>[+++DELETE +++ [**INSERT as this will be subject of a separate task force]. 
>However, it should study+++END DELETE+++] [+++INSERT+++ including]
> 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. [+++NOTE:  The preceding sentence should be moved from the "out of
>scope" section.] 

No. The old wording is more logical and preferable. This
is not an accuracy TF.  We just had an accuracy TF. As part of 
that TF, there was an insistence that we defer privacy and collection
issues. Now we are dealing with collection and the possibility of 
opt-out, and touch on accuracy only insofar as opting out creates 
opportunities to improve accuracy. 

All of Steve's proposed modifications of item 2 are unacceptable.

>2. Conduct an analysis of the existing uses of the registrant data
>elements currently captured as part of the domain name registration
>process [+++INSERT+++ and the methods intended to promote the accuracy of
>the data elements.] Develop list of [+++INSERT+++ optimal] {+++DELETE +++
>minimal] required elements [+++ INSERT +++ and collection methods +++] for
>contact-ability [+++INSERT +++ including data reliability].
>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
>[+++INSERT +++ the data] [+++ DELETE +++ they] may be acquired with the
>greatest accuracy, least cost, and in compliance with applicable privacy,
>security, and stability considerations.

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