FW: [dow1tf] WHOIS Task Force 1, 2, 3 July 20, 2004 - Minutes

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

All,
 
At the GNSO Council meeting in KL, it was decided to officially combine Task
Forces 1 and 2.  I would like to know if it would be possible to have a call
later this week or early next week to discuss our meetings in KL and a
strategy for moving forward.
 
Please let me know your availability (off list) on the following dates:
(note the date with the most people attending will be selected....hopefully
we will have at least one person from each constituency).
 
 
Thursday, July 29th:  9-11 am EST (2-4pm UTC)
Friday, July 30th, 9-11 am EST
Monday, August 2, 9-11 am EST
Tuesday August 3, 9-11 am EST

I know there will be people out on vacation, but we should try to push this
project along.

Thanks.
 
Jeff Neuman
 
-----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.