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

["David Fares" <dfares@xxxxxxxxx>]

Thanks Jeff.  The August dates work for me.  I would 
not be able to participate on either this Thursday or 
Friday.

Best regards,
David



From:           	"Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
To:             	"'dow1tf@xxxxxxxxxxxxxx'" <dow1tf@xxxxxxxxxxxxxx>,
  	"'dow2tf@xxxxxxxxxxxxxx'" <dow2tf@xxxxxxxxxxxxxx>
Copies to:      	"'bruce.tonkin@xxxxxxxxxxxxxxxxxx'" <bruce.tonkin@xxxxxxxxxxxxxxxxxx>,
  	"'gnso.secretariat@xxxxxxxxxxxxxx'" <gnso.secretariat@xxxxxxxxxxxxxx>
Subject:        	FW: [dow1tf] WHOIS Task Force 1, 2, 3  July 20, 2004 - Minutes
Date sent:      	Mon, 26 Jul 2004 06:09:24 -0400

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

David A. Fares
Director, Electronic Commerce
U.S. Council for International Business
dfares@xxxxxxxxx
Tel: 212-703-5061
     212-354-4480
Fax: 212-575-0327