Sorry, you need to enable JavaScript to visit this website.

WHOIS Task Forces Joint meeting in KL minutes

Last Updated:
31 August 2009
Date

WHOIS Task Force 1, 2, 3 Joint meeting with GNSO Council members in Kuala Lumpur, 20 July, 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)

Amadeu Abril l Abril (tf2)

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.