ICANN/GNSO GNSO Email List Archives

[whois-sc]


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

Re: [whois-sc] DRAFT 4 of Task force 2

  • To: Steve Metalitz <metalitz@xxxxxxxx>
  • Subject: Re: [whois-sc] DRAFT 4 of Task force 2
  • From: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
  • Date: Fri, 17 Oct 2003 18:27:21 +0200
  • Cc: Milton Mueller <Mueller@xxxxxxx>, Bruce.Tonkin@xxxxxxxxxxxxxxxxxx, whois-sc@xxxxxxxx
  • In-reply-to: <ED4EC3C54C514942B84B686CDEC7FC05859873@smsvr2.local.iipa.com>
  • Mail-followup-to: Steve Metalitz <metalitz@iipa.com>,Milton Mueller <Mueller@syr.edu>, Bruce.Tonkin@melbourneit.com.au,whois-sc@dnso.org
  • References: <ED4EC3C54C514942B84B686CDEC7FC05859873@smsvr2.local.iipa.com>
  • Sender: owner-whois-sc@xxxxxxxxxxxxxx
  • User-agent: Mutt/1.5.4i

In a context where there is no agreement of what "good" means --
with views ranging from "full anonymity" to "full contact data" --
terms like "optimal" or "best" are equally meaningless.

Minimizing data elements under the constraint that contactability be
maintained is a clear task that can be addressed in a rational
policy discussion; the balance that you allude to in the second part
of your message is captured quite well by that language.

-- 
Thomas Roessler  <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/






On 2003-10-16 19:14:18 -0400, Steve Metalitz wrote:
> From: Steve Metalitz <metalitz@xxxxxxxx>
> To: Milton Mueller <Mueller@xxxxxxx>,
> 	Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>,
> 	Bruce.Tonkin@xxxxxxxxxxxxxxxxxx
> Cc: whois-sc@xxxxxxxx
> Date: Thu, 16 Oct 2003 19:14:18 -0400
> Subject: RE: [whois-sc] DRAFT 4 of Task force 2
> X-Spam-Level: 
> 
> Milton seems to want a gate that swings only one way.  Minimal focuses on
> what is least; optimal focuses on what is best.  That may be more or less
> than we have now, or neither more nor less but different.  
> 
> Aren't we dealing with a spectrum here?  If Whois contained only one data
> element -- say the fax number of the administrative contact -- a
> registrant's privacy would be much more protected, but contactability would
> be very low, though not zero.  If it contained much more contact data than
> it does now, then leaving aside the issue of data accuracy -- which I don't
> believe we should leave aside, though others clearly disagree -- then
> contactability would be much higher, but there could be a negative impact on
> the privacy of registrants.  This Task Force should seek to find the optimal
> balance.  I support Bruce's formulation here.
> 
> Steve Metalitz  
> 
> 
> 
> -----Original Message-----
> From: Milton Mueller [mailto:Mueller@xxxxxxx]
> Sent: Tuesday, October 14, 2003 10:06 AM
> To: roessler@xxxxxxxxxxxxxxxxxx; Bruce.Tonkin@xxxxxxxxxxxxxxxxxx
> Cc: whois-sc@xxxxxxxx
> Subject: Re: [whois-sc] DRAFT 4 of Task force 2
> 
> 
> 
> >>> Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx> 10/14/03 05:13AM >>>
> >> 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?
> 
> >As this question is phrased now, the answer is "none"; the question
> >does not provide useful and clear guidance for future policy-making.
> >
> >Answering the question that was originally asked would actually
> >generate the kind of input that is needed for a rational policy
> >decision.  Please undo this change.
> 
> I want to emphasize the importance of what Thomas is saying
> here. We can have a real policy debate and discussion of what
> data elements are required for contactability while maximizing
> privacy. We cannot have such a decision or debate about 
> the question as phrased above. Whatever one's policy position,
> we need to have a real issue/question before us. 
> 
> >> 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. 
> 
> >"optimal" is ill-defined in this context, since it is not clear
> >*what* should actually be optimized.  Please keep the original
> >wording which actually formulates a well-posed problem.
> 
> I agree. However, by using the word "minimal" the old wording was not 
> intended to imply that we "will" decide data elements will be
> eliminated or reduced, it is simply an attempt to define a 
> benchmark. If other constituencies are uncomfortable with
> the implications of that word (minimal) I am flexible about changing
> it, but the focus of the TF on "what data elements are required"
> (no more, no less) MUST be retained. 
> 
> >Or is this supposed to mean that "optimal contact-ability" should be
> >the target of this task force?
> 
> Clearly, it is not. We must focus on the privacy/contactibility 
> trade off. That is what this TF is about. Efforts to divert 
> attention from that must cease.
> 
> 



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