Policy Update for the Registrar Stakeholder Group Margie Milam, Marika Konings, Liz Gasster

Overview of the Uniform Dispute Resolution Policy (UDRP) Preliminary Issue Report 2

Issue Report Request 3 3 Feb GNSO Council request for Issue Report on the current state of the UDRP The Issue Report to cover: − How the UDRP has addressed the problem of cybersquatting to date, and any insufficiencies/inequalities associated with the process − Whether the definition of cybersquatting inherent within the existing UDRP language needs to be reviewed or updated − Suggestions for how a possible PDP on this issue might be managed

Current Approach & Next Steps 4 Webinar 10 May heard from experts on the current state of the UDRP Questionnaire to UDRP providers submitted facts for Issue Report Preliminary Issue Report published for public comment UDRP Session- Wed 8:30 -10:30 Padang Room Final Issue Report to be released after Singapore GNSO Council to vote on whether to initiate a PDP on the UDRP

Current State of the UDRP 5 Widely Recognized as a Success Over 30,000 complaints filed over last decade Four service providers approved by ICANN providing choice and competition Viable alternative to costly litigation involving parties from differing jurisdictions Served as a model for ccTLDs Significant service provider resources in education and publishing decisions

Community Opinion of the UDRP 6 The UDRP is cost effective, as compared to traditional litigation The UDRP is flexible and fair to respondents- rarely challenged in court The UDRP is predictable and transparent The UDRP is unfair to brand holders, who spend million$ on cybersquatting Although not perfect, more harm than good can result from a PDP If the UDRP is to be reviewed at all, focus on process improvements Consensus - a PDP could undermine the effectiveness of the UDRP

Staff Recommendation 7 Given the Community view that the UDRP should not be tampered with, Staff recommends against initiating a PDP If the GNSO Council believes that the UDRP should be reviewed: Staff suggests convening a team of experts Experts to focus on process recommendations only PDP could be initiated later if there is a continued desire to review the policy

8 Issues Identified by the Community Policy Issues Bad Faith Requirement “Or” instead of “And” Missing Safe Harbors Policy should reference free speech and fair use No Appeals Policy should include an appeals process

Issues Identified by the Community Early Mediation Lock Down of Domain Billing Contact Data Not Provided Panel Appointment Timeline Meaning of Status Quo Privacy/Proxy Registrations Verification Process Multiple UDRPs against single Respondent Identity of Respondent Electronic Communications WHOIS UpdatesCopy of Complaint Registrar Obligations Language of Proceedings Timing of Complaint Copies 9 Process Issues

Issues Identified by the Community Forum ShoppingDefault Reverse Domain Name Hijacking Registrar Cooperation Conflicts of law Uniform Procedures for Transfers Dropping names from Respondents in Complaint LachesAppeals to Courts Contact Data of the Parties Evidence Registry Notice to Registrars Stays/Case Suspensions ICANN Compliance Activity Registry Role In Implementation Timing of ResponseRules on Supplemental Submissions Prevailing Party Cooperation 10 Process Issues

Issues Identified by the Community UDRP Cases as Precedence Sanctions for Rule Violations Loser Pays Nothing Review of Bad Cases ICANN Contracts with Providers Three Member Panel Fees Uniform application of rules by providers Renewal Fees Penalties for abusive filings Uniform File/Decision formats Expiration & Deletions Deadlines and timings 11 Process Issues

Additional Information 12 The UDRP- Review archive of the Webinar on the Current State of the UDRP: Participate in the public comment forum on the Preliminary Issue Report- until 15 July ment-2-27may11-en.htm ment-2-27may11-en.htm

Inter-Registrar Transfer Policy (IRTP) Part B PDP Working Group 13

Background Inter-Registrar Transfer Policy (IRTP) Straightforward process for registrants to transfer domain names between registrars Currently under review to ensure improvements and clarification – nr 1. area of complaint according to data from ICANN Compliance IRTP Part B PDP Working Group – second in a series of five PDPs 14

CharterQuestions Charter Questions Should there be a process or special provisions for urgent return of hijacked registration, inappropriate transfers or change of registrant? Registrar Lock Status (standards / best practices & clarification of denial reason #7) 15

RecentDevelopments Recent Developments PDP was initiated in June 2009 Publication of Initial Report on 29 May 2010 Publication of Proposed Final Report for public comment on 21 February 2011 Following review of comments, publication of Final Report on 30 May 2011, containing 9 recommendations for GNSO Council consideration 16

Overview Total of 9 recommendations: 4 recommendations for changes and/or additions to the existing IRTP, Transfer Emergency Action Contact, section 3 of the IRTP, Denial Reason #6 and Denial Reason #7 2 recommendations requesting an Issue Report related to ‘thick’ WHOIS and ‘change of control & denial reason #8 and #9 1 recommendation for the promotion of an SSAC report 1 recommendation to defer an issue 1 recommendation for ICANN staff to standardize and clarify WHOIS status messages 17

Recommendations Requiring registrars to provide a Transfer Emergency Action Contact (TEAC) for urgent communications relating to transfers. The goal of the TEAC is to quickly establish a real-time conversation between registrars in case of an emergency such as hijacking. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer. (#1) Promoting proactive measures to prevent hijacking such as outlined in the recent report of the Security and Stability Advisory Committee on 'A Registrant's Guide to Protecting Domain Name Registration Accounts (SAC 044). (#2) 18

19 Requesting an Issue Report on the requirement of 'thick' WHOIS for all incumbent gTLDs. (#3) Requesting an Issue Report to examine the 'change of control' function as well as a review of locking procedures as described in IRTP Reasons for Denial #8 and #9. (#4) Modifying section 3 of the IRTP to require that the Losing Registrar notifies the Registrant of the transfer out. (#5) Clarifying IRTP Reason for Denial #6 to make it clear that the registrant must give some sort of informed opt-in express consent of having registrar-specific locks applied, and the registrant must be able to have the lock removed upon reasonable notice and authentication. (#6)

If a review of the UDRP is conducted in the near future, the issue of requiring the locking of a domain name subject to UDRP proceedings is taking into consideration. (#7) Standardizing and clarifying WHOIS status messages regarding Registrar Lock status. (#8) Deleting IRTP Reason for Denial #7 and instead replace it by adding a new provision in a different section of the IRTP on when and how domains may be locked or unlocked. (#9) 20

NextSteps Next Steps GNSO Council to consider motion on IRTP Final Report and recommendations on Wednesday’s GNSO Council meeting 21

Further Information IRTP Part B PDP Final Report - tp-b-final-report-30may11-en.pdf tp-b-final-report-30may11-en.pdf IRTP Part B Public Comment Review Tool attachments/ /Public+comment +review+tool+-+Proposed+Final+Report+- +5+May FINAL.pdf?version=1&modificationDate= attachments/ /Public+comment +review+tool+-+Proposed+Final+Report+- +5+May FINAL.pdf?version=1&modificationDate= Inter-Registrar Transfer Policy

Post-Expiration Domain Name Recovery WG 23

To what extent should registrants be able to reclaim their domain names after they expire? Issue brought to the GNSO by ALAC PDP initiated in June 2009 PEDNR WG examines five questions relating to expiration and renewal practices and policies WG is expected to make recommendations for best practices and / or consensus policies Why is it important? 24

Initial Report Published in May 2010 – did not include any recommendations WG reviewed public comments and continued deliberations Published proposed Final Report on 21 Feb containing 14 recommendations, in combination with opening of public comment forum Following review of public comments, WG has now finalized its report, containing 18 recommendations Recent Developments 25

The WG believes that the recommendations: − will provide additional guarantees to registrants; − will improve registrant education and comprehension; − are in line with current registrar practices and will have minimal impact on most registrars and other affected stakeholders. All recommendations have full consensus support and are considered inter-dependent In General 26

General Define “Registered Name Holder at Expiration (RNHaE) (Rec #1) Post Expiration Behavior and Ability to Renew Provide a minimum of 8 days after expiration for renewal by registrant (Rec#2) Website must explicitly say that registration has expired and instructions on how to redeem (Rec#3) RNHaE cannot be prevented from renewing as a result of WHOIS changes (Rec#4) The Recommendations 27

Registrar Disclosure and Expiration Warning Fees charged for renewal must be posted (Rec#5) Clear indication of methods used to deliver pre- and post-expiration notifications (Rec#6) At least two notices prior to expiration at set times, one after expiration (Rec#7 & 8) Notifications must not solely be done by methods which require explicit action by Registrant (Rec#9) Best practice: Post-expiration notifications should be sent to some other contact point (Rec#10), provide notice of where notification s will be sent from (Rec#11), provide secondary point of contact (Rec#12) The Recommendations (continued) 28

The Recommendations ( continued ) Redemption Grace Period All gTLDs and registrars must offer Redemption Grace Period (RGP), with the exception of sponsored gTLDs (Rec#13 & 14) Transfer of a domain name during the RGP should not be allowed (Rec#15) Registrant Education & Awareness ICANN to develop educational materials on how to properly steward a domain name and prevent unintended loss (Rec#16) If web content is developed as per Rec#16, registrars to link / distribute such information (Rec#17) 29

The Recommendations ( continued ) Monitoring & Follow up ICANN Compliance to provide updates on a regular basis in relation to the implementation and effectiveness of the proposed recommendations. (Rec#18) 30

Next Steps Draft motion developed, possibly considered at GNSO Council meeting in July 31

Post-Expiration Domain Name Recovery Final Report - final-report-14jun11-en.pdf final-report-14jun11-en.pdf PEDNR WG Workspace - y/gnsopednr/PEDNR+WG+-+Home y/gnsopednr/PEDNR+WG+-+Home Further Information 32

Discussion Paper on the creation of non-binding best practices to address the abusive registrations of domain names 33

Background In its Final Report, the Registration Abuse Policies (RAP) Working Group recommended ‘the creation of non- binding best practices to help registrars and registries address the illicit use of domain names’. At its meeting on 3 February 2011, the GNSO Council requested ICANN Staff to prepare a discussion paper on this topic 34

Status Staff working on discussion paper that will raises a number of questions and identifies existing best practices Workshop in Singapore to get community input on this topic (see 623) Taking into account community input, staff to prepare discussion paper for submission to the GNSO Council following Singapore meeting 35

Additional Information RAP Final Report- final-report-29may10-en.pdf final-report-29may10-en.pdf GNSO Council Resolution - (motion ) Best Practices Workshop on Thursday 23 June from – (see

The new GNSO Policy Development Process PDP-WT Final Report

Objective The PDP-WT is responsible for developing a new GNSO policy development process that incorporates a working group approach and makes it more effective and responsive to ICANN’s policy development needs. The primary tasks are to develop: 1.Appropriate principles, rules and procedures applicable to a new policy development process; and 2.An implementation/transition plan

Approach PDP-WT formed in February 2009 Initial Report published in May 2010, proposed Final Report published in February 2011 WT has reviewed public comments, continued deliberations on open issues and has now submitted its Final Report Final Report includes 48 recommendations, new Annex A and proposed PDP Manual Report has full consensus support of the PDP- WT

Next Steps Public comment forum open by the GNSO Council – comments may be submitted until 9 July. Based on comments received, GNSO Council will need to decide whether comments and report will need to be passed back to the PDP-WT for further consideration, or whether GNSO Council can consider the report for approval.

Further Information Public Comment Forum - comment/#pdp-final-report comment/#pdp-final-report PDP-WT Final Report - report-final-31may11-en.pdf report-final-31may11-en.pdf Public Comment Review tool - comments-review-tool-24may11-en.pdf comments-review-tool-24may11-en.pdf PDP – WT Workspace - sc/PDP-WT+Home sc/PDP-WT+Home

WHOIS Update Liz Gasster 42

Questions? 43

Thank You