Policy Update

Agenda

• Locking of a Domain Name Subject to UDRP Proceedings PDP

• Thick Whois PDP• IRTP Part D PDP• Policy & Implementation• Other efforts?

Locking of a Domain Name subject to UDRP Proceedings

Final Report

4

Final Report

• Submitted on 5 July 2013• Two substantive changes in

response to public comments received

• 17 full consensus Recommendations intended to clarify and standardize the process for locking of a domain name subject to UDRP Proceedings

• #1 Definition of ‘lock’ – preventing any changes of registrar and registrant, without impairing resolution or preventing renewal

• #2 & #9 - Removing obligation for complainant to notify the respondent at the time of filing, but add automatic extension of 4 days to response time upon request by respondent

• #4 – Registrar not allowed to contact registrant until “lock’ has been applied

• #5 - Requiring registrar to apply lock within 2 business days following request for verification

5

Recommendations

• #6 – Best practice recommendation for registrars and UDRP Providers to provide means to identify opening hours / days (i.e. business days)

• #7 – Requirement for registrar to confirm “lock” & verify information in response to verification request from UDRP Provider

• #8 – If compliant, UDRP Provider shall notify parties of commencement no later than 3 business days (change from calendar days)

• #10 – If complaint remains non-compliant, registrar shall within one business day of receipt of withdrawal notice remove the “lock”

6

Recommendations

• #11 – UDRP Provider notifies registrant that any updates to contact information also need to be communicated by the registrant to the UDRP Provider

• #12 – Notification also includes information that any changes as the result of lifting of privacy / proxy services after the “lock” has been applied, need to be reviewed by the UDRP Panel directly. (to be further reviewed as part of the privacy / proxy accreditation program)

• #13 – Registrar must communicate within 3 business days to all parties the date for implementation of the decision – implement immediately after 10 business days if complainant has prevailed, after 15 business days if respondent prevails

7

Recommendations

• #14 – In case of suspension (to agree on settlement), UDRP Provider informs the Registrar of suspension, including expected duration. If settlement is reached, “lock” needs to be removed within 2 business days.

• #15 – Defined process for settlement, which includes the UDRP Provider confirming to the registrar the settlement reached.

• #16 – Development of educational and information materials to assist in implementation of recommendations

• #17 Creation of an Implementation Review Team to assist ICANN staff in the development of the implementation plan

8

Recommendations

Next Steps

• GNSO Council to consider report and recommendations for adoption at Wednesday meeting

• If adopted, public comment forum followed by Board consideration

Thick Whois PDPPresentation of Initial Report

Current Status

• Published for public comment on 21 June

• Public comment forum open until 14 July, followed by a reply period (4 August)

• Workshop in Durban on Wednesday 17 July from 12.30 – 14.00 (see http://durban47.icann.org/node/39777)

Initial Report

Considers:•Response consistency•Stability•Access to Whois data•Impact on privacy & data protection•Cost implications•Synchronization / migration•Authoritativeness•Competition in registry services•Existing Whois applications•Data escrow•Registrar Port 43 Whois requirements

Conclusion

• The provision of thick Whois services should become a requirement for all gTLD registries, both existing and future.

• Recognizes that a transition of the current thin gTLD registries would affect over 120 million domain name registrations - should be carefully prepared and implemented

Next Steps

• Review comments received• Finalize report for

submission to the GNSO Council

IRTP Part D PDPWorking Group Update

Overview

• Fourth and last Working Group (WG) of IRTP-related PDP series

• WG started on 25 February 2013• Community input from BC and RySG

reviewed

Charter Questions• a) Should reporting requirements for registries

and dispute providers be developed in order to make precedent and trend information available to the community and allow reference to past cases in dispute submissions?

• b) Should additional provisions be included in the Transfer Dispute Resolution Policy (TDRP) that set out how to handle disputes when multiple transfers have occurred?

• c) Should dispute options for registrants be developed and implanted as part of the IRTP (currently registrants depend on registrars to initiate a dispute on their behalf)?

Charter Questions• d) Should certain requirements and best

practices be put into place for registrars to make information on transfer dispute resolution options available to registrants?

• e) Are existing penalties for policy violations sufficient or should additional provisions/penalties for specific violations be added into the IRTP?

• f) Did the universal adoption and implementation of EPP AuthInfo codes eliminate the need of Standard Forms of Authorization (FOAs)

Key Issues under Discussion

• Modification of Transfer Dispute Resolution Policy; its usefulness and effectiveness are subject to WG debate

• Should registrant should be given direct dispute options?

• Are there issues from earlier IRTP WG’s that should be revisited, given changes that have taken place?

Future Milestones

• Initial Report envisaged for early August 2013

• Final Report envisaged for ICANN 48 Buenos Aires

• Info: www.tinyurl.com/irtphome

Policy & ImplementationUpdate

Proposed Charter – Key Assumptions

• Policy development process are well defined• Implementation processes are less well

defined• Exact delineation between policy and

implementation may be difficult to define, but there is a need to establish a framework that takes relationship between the two into account

• Appropriate level of multi-stakeholder participation needs to be included in all processes

Proposed WG Charter – Mission

WG to develop:1.A set of principles that underpins any GNSO policy & implementation related discussions2.A process for developing “Policy Guidance” that can be used instead of a PDP for developing policy other than “Consensus Policy”3.A framework for implementation related discussions4.Criteria to be used to determine whether an action should be addressed by a policy or implementation process5.Further guidance on how GNSO Review Teams are expected to function and operate

Proposed Charter – Objectives & Goals

• Develop at a minimum an Initial and Final Recommendations Report

• Recommendations may include proposed changes to the GNSO Operating Procedures and/or Bylaws

• Includes recommended WG tasks, deliverables as well as questions that may be helpful for completing the work

• Other sections follow GNSO Working Group Guidelines ‘standard’ language

Next Steps

• GNSO Council consideration of Charter• If/when adopted, formation of Working

Group

Further information

• Proposed Charter - http://gnso.icann.org/en/drafts/policy-implementation-charter-04jul13-en.pdf

• DT Workspace - https://community.icann.org/x/wiJ-Ag

Other

Other Projects

• Translation & Transliteration PDP• IGO/INGO PDP• Purpose of Registration Data PDP• RAA PDP• Reporting and Metrics WG• Whois Survey Requirements Survey

WG

Questions?

Annex – BackgroundLocking of a Domain Name

subject to UDRP Proceedings

• PDP limited to the subject of locking of a domain name subject to UDRP Proceedings

• Currently no requirement to lock names in period between filing and commencement of proceedings

• No definition of ‘status quo’which has resulted in different interpretations

Why is it important?

31

32

• Initial Report published for community input prior to Beijing

• 5 submissions received – mostly in support, but some important issues raised (loss of informal response time, how to address suspension / settlement)

• WG addressed comments received and finalized report in time for submission to GNSO Council in Durban

Recent Developments

32

33

• Final Report - http://gnso.icann.org/en/issues/locking/domain-name-final-05jul13-en.pdf

• Initial Report – http://gnso.icann.org/en/issues/locking/domain-name-initial-15mar13-en.pdf

• Public comment forum – http://www.icann.org/en/news/public-comment/locking-domain-name-15mar13-en.htm

• WG workspace – https://community.icann.org/x/xq3bAQ

Further Information

33

Annex – Background InfoThick Whois PDP

Why is this important?• ICANN specifies Whois requirements through the

registry and registrar agreements

• Registries use different services to satisfy their obligations:

– ‘thin’Whois: A thin registry only stores and manages the information associated with the domain name

– ‘thick’Whois: Thick registries maintain and provide both sets of data (domain name and registrant) via Whois.

• ‘Thick’ Whois has certain advantages e.g. transfers, but there may be negative consequences that should be explored in order to determine whether ‘thick’ Whois should be required for all

Background

• WG started its deliberations in November 2012

• Created a number of sub-teams to address charter questions

• Formed ad-hoc Expert Panel• Requested input from other ICANN

SO/ACs & GNSO SG / C• Worked its way through input received

topic by topic

Additional Information

• Initial Report - http://gnso.icann.org/en/issues/whois/thick-initial-21jun13-en.pdf

• Public Comment Forum - http://www.icann.org/en/news/public-comment/thick-whois-initial-21jun13-en.htm

Annex – Background InfoPolicy & Implementation

Background

• GNSO agreed to create a DT in Beijing to develop a charter for a Working Group to address issues that have been raised in the context of the recent discussions on policy & implementation that affect the GNSO

• DT was formed and started its discussions on 10 June

• Proposed charter submitted to GNSO Council for consideration on 5 July