[dow1tf] RE: Proposal re priorities for discussion tomorrow

["Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>]

Thanks Steve.  

I agree with respect to Numbers 1 and 2 on your list.  However, and we will
discuss this tomorrow, I am not sure that we should limit ourselves on what
you have suggested for number 3.  

Perhaps, and this would be my suggestion, we should start by discussing and
trying to come to consensus on defining the tiers (i.e., what data should be
in which tier) first (or at least in parallel).   

Lets discuss tomorrow.

Jeff

 

-----Original Message-----
From: Steve Metalitz [mailto:metalitz@xxxxxxxxxxxxx]
Sent: Monday, August 02, 2004 4:18 PM
To: Jeff Neuman; dow1tf@xxxxxxxxxxxxxx; dow2tf@xxxxxxxxxxxxxx
Cc: bruce.tonkin@xxxxxxxxxxxxxxxxxx; GNSO Secretariat
Subject: RE: Proposal re priorities for discussion tomorrow 


 
TF 1 and 2 colleagues -

In his summary of the discussions in KL (as shared with GNSO Council last
week, see
http://gnso.icann.org/mailing-lists/archives/council/msg00531.html), Bruce
Tonkin called on the joint task force to-- 

"prioritise the recommendations that (1)  have the best consensus, (2)
provide a tangible improvement for the Internet community, and (3)  are
likely to be implementable within the short term (months rather than years)"

Applying these three criteria to the output of TFs 1 and 2, I propose that
we consider the following priorities on our call tomorrow:

(1)  Conspicuous notification to, and obtaining consent from, registrants re
availability of Whois data.  (See TF 2, recommendation 1.)  This was also on
Jeff's list. 

(2)  Establishing a process for handling (and, if possible, resolving) cases
of conflict between applicable national privacy laws and ICANN contractual
obligations with regard to Whois.  (See TF 2, recommendation 3, and TF 1,
recommendation 3.)  This was not on Jeff's list but I think it would score
well on all 3 criteria.  

(3)  Investigating the implementability of methods for
identifying/authenticating Whois requesters.  This may be a good place to
start on the further exploration of tiered access (which was on Jeff's list,
but which I think when considered as a whole would not fare well under
Bruce's criteria).  Eliminating the anonymity of at least some Whois queries
is a feature of all the various flavors of tiered access that were discussed
within the two task forces.  The merged task force could make a useful
contribution by finding out more about the costs (in terms of time, money,
and other resources) and the reliability of the available methods for
achieving this.  I think there is a consensus that this issue be explored,
and it may be something on which we can hope to reach a conclusion within
the short term.  It's hard to evaluate whether Bruce's second criterion can
be met until we have actually done the work. 

I hope that this proposal will be a useful starting point for our discussion
tomorrow.  Of course we will also need to talk at some point about timeline
and about experts whom we may wish to invite to brief us on these topics.  

Steve Metalitz

  
-----Original Message-----
From: owner-dow2tf@xxxxxxxxxxxxxx [mailto:owner-dow2tf@xxxxxxxxxxxxxx] On
Behalf Of Neuman, Jeff
Sent: Wednesday, July 28, 2004 8:34 AM
To: 'dow1tf@xxxxxxxxxxxxxx'; 'dow2tf@xxxxxxxxxxxxxx'
Cc: 'bruce.tonkin@xxxxxxxxxxxxxxxxxx'; GNSO Secretariat
Subject: [dow2tf] Meeting Tuesday August 3rd (9-11am EST; 2-4pm UTC)

All,

The majority of people polled indicated that they could meet on August 3rd.
I believe only one person said that he or she could not attend.  I believe
the agenda for the meeting should be:

(1) Review Activities in KL

(2) Selection of chair for TF1 and TF2

(3) Select priority recommendations for further work
- e.g registrant consent, tiered access

(4) Break into sub-groups to develop reference implementations
*	E.g registrant consent
*	Tiered access (break into two subgroups
	- what data is in each tier 
	- how to accredit/identify users of tier 2 

Please let me know your thoughts on this agenda and whether you have
anything to add.  There is a lot to cover, so I blocked out 2 hours.  If it
takes les time, great. 

Glen, can you please send around a call-in number for this meeting as well
as plan for an mp3 recording?

Thanks.

Jeff

-----Original Message-----
From: gnso.icann [mailto:gnso.secretariat@xxxxxxxxxxxxxx]
Sent: Thursday, July 22, 2004 11:36 PM
To: 1DOW1tf
Subject: [dow1tf] WHOIS Task Force 1, 2, 3 July 20, 2004 - Minutes

[To : Whois task forces 1, 2, 3]
WHOIS Task Force 1, 2, 3 July 20, 2004 - Minutes
ATTENDEES:
Participants:
Bruce Tonkin meeting chair
Jeff Neuman - Chair tf 1
David Fares (tf1)
David Maher tf1 (also representing tf2)
Antonio Harris (tf1)
Milton Mueller (tf1 alternate tf2)
Tom Keller (tf2)
Ken Stubbs (tf3)
Greg Ruth (tf3)
Ross Rader (tf3)
Alick Wilson
Demi Getschko
Carlos Afonso
Cary Karp
Philip Sheppard
Tony Holmes
Niklas Lagergren
ICANN Vice President, Policy Development Support: Paul Verhoef ICANN Staff
manager: Barbara Roseman GNSO Secretariat: Glen de Saint Géry 


General Objectives - next steps
Review proposed recommendations
Review consensus policy recommendations already made, but not yet
implemented, and whether they have relevance for current recommendations
Implementation analysis for proposed recommendations 

o Reference implementation
Assess Implementability, technical and otherwise How long to implement Cost
of implementation - impact on ICANN budget, registrars, registries,
registrants, user community Should aspects of implementation be standardised
(specified as part of the
policy) or left to the market 

o Funding model for additional costs
Prioritise implementation work
Take small steps forward 

TF1/TF2 discussion
Current state: all data available for anonymous public access Port 43/web
based (bulk access is out of scope) 

TF2: conspicuous notice to registrants of current policy need to clearly
define "conspicuous notice". 
Consider defining a reference implementation for conspicuous notice and
assess whether parts of the implementation should be standardised (ie
explicitly included in the policy specification) 

How does current status of datacontractual requirements relate to national
laws on privacy? 

This issue is tightly associated with the degree of consent as discussed
above. This will need to be assessed once the policy is improved. 

Tiered Access 

Basic data (e.g for purposes of contactability) (Tier 1) Public, anonymous,
doesn't matter who sees it The working group needs to clearly recommend what
information should be included in tier 1. Full data (e.g for purposes of
accountability) (Tier 2) Someone needs to be accountable for what happens
with the use of this domain name Identify the requestor of data 

Questions: What falls into each set of data?
TF 1 made a suggestion for how to distinguish the data TFs both need to make
clear what the definitions of the data sets would be (Which data included in
which set) 

Need to determine how to implement the process of identifying the requestor
Some suggestions approaches include: 
Centralised white list (user agreement w/license for multiple uses) How
would this scale? 
Who maintains, how operated? 
Who manages enforcement of license agreement? 
Distributed white list
Each registrar creates white list and determines access Trust model for
sharing accreditation? 
Cost effectiveness? 
Individual use access
Can we do a combination of both centralised and distributed?
What work is required for identifying the requestor? 
Log the requests (e.g identity of requestor, domain name record retrieved,
date)
How to conform with national privacy considerations on collection of
information on WHOIS requestors Log reason for request (e.g law enforcement,
trademark enforcement, copyright enforcement, etc) Do users requesting data
on behalf of third parties need to identify the third parties? 
How to prevent retrieved data being passed on to other parties? 
Notify registrant?
Immediate and/or
After some time
Issues with registrant contact in reseller chains Provide information on
request of registrant Immediate and/or After some time (supply reason for
delay) *ICANN or registrar or White List maintainer could maintain log for
statistical/oversight purposes -- Council could define appropriate
measurements, data to be reported on For what use? To what end? How do
decisions based on measurements get fed back into enforcement, or changed
rules, or changed policy? Much more discussion needed 

TF3 Discussion
Registrants have an obligation to provide accurate data Registrars have an
obligation to notifiy registrants of their responsibility WDRP Reasonable
attempt to ensure registrant corrects the data Proposed work to be performed
by ICANN staff Centralised complaint form Notify registrar of complaint
Compile report on activity of complaint system Study effectiveness of WDRP
Need to determine if achievable within ICANN budget or whether additional
funds required. 

General comments on TF3 recommendations 

The report refers to ICANN in several places. In some cases it seems to be
referring to work required by ICANN staff, and in other cases it is
referring to further policy development which would be ultimately done by a
WHOIS task force (ie ourselves). 
In some cases the report discusses issues associated with implementation and
enforcement of new policies (e.g data verification) without making clear
that the report proposes a new policy.

In discussion of needing to improve implementation practices of existing
policy - if it is the task force's view that such practices should become
standardised - then these should be formulated in the form of additional
policy recommendations (ie contractual obligations). 
Thus the task force needs to clarify the use of language in the report to
clearly identify where a new policy (and hence contractual obligation) is
being proposed, where a refinement of an existing policy is being proposed ,
and where a request is being made to the ICANN staff to perform additional
tasks. 
Once the policy recommendations are clear, each recommendation will require
work on iImplementability as per TF 1 and TF2. 
Cost, resources, how enforced? 
Sanctions? How is effectiveness evaluated? 

Data analysis of other registrations by same registrant, or with similar
registration data?

New obligation - requires implementation analysis Additional measurements
requested by ICANN 

Is this covered in existing budget? Does it need additional resources
assigned in future budgets? 

Data verification 

New obligation (or replacement of existing policy) Implementability --
Costs, etc. 
Through email verification, or other, progressively more costly means
Affects every registrant if done at time of registration affects every
registrant, or could be done following a complaint, perhaps with some sort
of reconnection charge when inaccurate data discovered. 

Conclusion: 
- Prioritise those policy recommendations that "could" be implemented in the
short term. 
- E.g conspicuous notice, tiered access, monitoring improvements,
improvement to process for responding to complaints about WHOIS accuracy
- Design reference implementations for new recommendations (new contractual
obligations in the case of registries and registrars)
- Determine impact of implementations - costs, other issues
- Aim to get some recommendations completed quickly, and then continue
implementation analysis of further refinements
- Measure impact of actual implementations of recommendations approved by
the Board and use this to inform whether further refinement is necessary 

Thanks to Barabara Roseman, ICANN staff Manager, who took notes and Bruce
Tonkin for edits.


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