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 PDP Presentation 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 – (see 777) 777

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 PDP Working 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:

Policy & Implementation Update

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 discussions 2.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 discussions 4.Criteria to be used to determine whether an action should be addressed by a policy or implementation process 5.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 - implementation-charter-04jul13-en.pdf implementation-charter-04jul13-en.pdf DT Workspace -

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 – Background Locking 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 - n-name-final-05jul13-en.pdf n-name-final-05jul13-en.pdf Initial Report – n-name-initial-15mar13-en.pdf n-name-initial-15mar13-en.pdf Public comment forum – comment/locking-domain-name-15mar13- en.htm comment/locking-domain-name-15mar13- en.htm WG workspace – Further Information 33

Annex – Background Info Thick 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 - ois/thick-initial-21jun13-en.pdf ois/thick-initial-21jun13-en.pdf Public Comment Forum - ic-comment/thick-whois-initial- 21jun13-en.htm ic-comment/thick-whois-initial- 21jun13-en.htm

Annex – Background Info Policy & 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