ICANN/GNSO GNSO Email List Archives

[whois-sc]


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

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


On 2003-10-14 17:50:54 +1000, Bruce Tonkin wrote:

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

Milton had a valid comment here, namely that it is not clear whether
WHOIS is a public register.  I'd suggest to strike this insert, as
it adds no value, but creates confusion.

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

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

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

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

>  required elements for contact-ability. 

Or is this supposed to mean that "optimal contact-ability" should be
the target of this task force?

> 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,]

Making improved contact-ability the sole measure by which to assess
the need to collect mandatory data elements is neither useful, nor
acceptable:  If implemented, these terms of reference would generate
a task force that is chartered to turn a wishlist from data users
into policy.

That would not contribute to actually addressing the privacy issues
at hand.

Please strike this insertion.

>  and [** DELETE if so,] how [** REPLACE they WITH the data] may be
> acquired with the greatest accuracy, least cost, and in compliance with
> applicable privacy, security, and stability considerations.

Since accuracy issues are the topic of a different task force, I'd
suggest to drop the word "accuracy" from this sentence.

> 3. Document existing methods by which registrants can maintain anonymity
> and assess their adequacy. 
> [** INSERT Document examples of existing local privacy laws in regard to
> display/transmittal of data.]   
> Decide what options [** INSERT 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.
> 
> 
> 
> 



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



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