<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [dow2tf] Re: FW: [dow1tf] WHOIS Task Force 1, 2, 3 July 20, 2004 - Minutes
- To: <dfares@xxxxxxxxx>, <dow1tf@xxxxxxxxxxxxxx>, <dow2tf@xxxxxxxxxxxxxx>, "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
- Subject: RE: [dow2tf] Re: FW: [dow1tf] WHOIS Task Force 1, 2, 3 July 20, 2004 - Minutes
- From: "Cade,Marilyn S - LGCRP" <mcade@xxxxxxx>
- Date: Tue, 27 Jul 2004 12:58:55 -0400
- Cc: <bruce.tonkin@xxxxxxxxxxxxxxxxxx>, <gnso.secretariat@xxxxxxxxxxxxxx>
- Sender: owner-dow2tf@xxxxxxxxxxxxxx
- Thread-index: AcRzE1/sM9s0FpSQT7GkLwP0vTGNIAA54WGw
- Thread-topic: [dow2tf] Re: FW: [dow1tf] WHOIS Task Force 1, 2, 3 July 20, 2004 - Minutes
I can participate on August 2 or 3rd. Prefer 2nd. Can't do this week though.
Marilyn S. Cade
AT&T Law & Government Affairs
1120 20th Street, NW, Suite 1000N
Washington, DC 20036
202-457-2106v
281-664-9731 e-fax
202-360-1196 c
mcade@xxxxxxx
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
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|