1. Policy Update Marika Konings

2. Agenda 2 Inter-Registrar Transfer Policy Part C Locking of a Domain Name Subject to UDRP Proceedings Fake Renewal Notices Other? (over 20 active projects in the GNSO)

3. Inter-Registrar Transfer Policy Part C 3

4. Why is it important? 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 consumer complaints according to data from ICANN Compliance 4

5. IRTP Part C PDP Working Group IRTP Part C WG tasked to address three issues: a)"Change of Control" function b)Should Form Of Authorization (FOA)s be time-limited c)Should registries be required to use IANA IDs for registrars rather than proprietary IDs. WG conducted data gathering survey – 100 responses received In addition to weekly conference call, email deliberations, public comment forum & SG/C statements Initial Report published on 4 June 2012 5

6. Initial Report Recommendations 6

7. Charter Question A 7 Currently there is no policy in relation to “change of control” or “change of registrant” Having a “change of registrant” policy might address certain issues currently encountered Most ccTLDs have a process in place to manage change of registrant WG recommends the adoption of a change of registrant consensus policy

8. Requirements of New Policy Both the prior registrant as well as the new registrant need to authorize the change of registrant (can be provided in the form of pre-approval or proxy) A change of registrant cannot take place simultaneously with a change of registrar. If both changes need to be made, a change of registrar needs to be completed prior to initiating the change of registrant Process should not create unfair advantage / disadvantage for any of the segments active in the domain name industry and should not prevent innovation & differentiation 8

9. Open Issues 9 Should there be a restriction following a change of registrant to prevent an immediate change of registrar (e.g. 60-day lock)? Which changes qualify as a change of registrant? Should it be a stand-alone policy, part of the IRTP or hybrid solution? Any unforeseen impacts of the proposed policy?

10. Charter Question B 10 Currently no specifications in the IRTP related to timing or limits to use of FOAs. Poses risk that unexpired FOA could be used later on for an unauthorized transfer. Survey conducted by WG found that majority of respondents currently impose a time limit; majority supports time limiting; however, majority had not had or heard of or seen issues as result of no time-limit.

11. Recommendations 11 IRTP to be revised to include: ‘Once obtained, an FOA is valid for (45 or 60) calendar days, or until the domain name expires, or until there is a Change of Registrant, whichever occurs first The FOA is enhanced to support pre- authorized or auto-renewed FOAs by a registrant who has chosen to opt out of time-limiting requirements

12. Open Issues 12 Time-Limit (45 – 60 days, other?) Implementation of this recommendation should be accompanied by the appropriate security measures to protect registrants from hijacking attempts using pre-approval as the attack vector. The details of such security measures are to be discussed in further detail. Any unforeseen impacts of the proposed recommendations?

13. Charter Question C 13 When a registrar accredits with ICANN, an ID is assigned by ICANN to identify that particular registrar When a registrar accredits with a particular registry, that registry may also assign a proprietary ID Primary driver for using proprietary IDs by some registries is security Poses difficulties to identify the registrar correctly at times

14. Charter Question C 14 May be manageable in current environment, but with new gTLDs situation may drastically change Data gathering survey found that majority of respondents: had not experienced problems; felt that standardization would simplify transfers; felt that the effort to standardize IANA IDs would be ‘minimal’ to ‘some’

15. Recommendation 15 All gTLD Registry Operators be required to publish the Registrar of Record’s IANA ID in the TLD’s thick Whois. Existing gTLD operators that currently use proprietary IDs can continue to do so, but they must also publish the Registrar Record’s IANA ID. This recommendation should not prevent the use of proprietary IDs by gTLD Registry Operators for other purposes.

16. Open Issues 16 Any unforeseen impacts of the proposed recommendation?

17. Next Steps 17 Public Comment Forum open until 4 July, reply period open until 25 July - http://www.icann.org/en/news/public- comment/irtp-c-initial-report-04jun12- en.htm http://www.icann.org/en/news/public- comment/irtp-c-initial-report-04jun12- en.htm Workshop on Wednesday from 9.00 – 11.00 (Karlin I/II) WG will review comments received, continue deliberations on open issues and intends to finalize report for submission to the GNSO Council by ICANN Meeting in Toronto (October 2012)

18. Questions 18

19. Locking of a Domain Name Subject to UDRP Proceedings PDP WG 19

20. Following the recommendation of the IRTP Part B WG and the Issue Report on the UDRP, the GNSO Council initiated a PDP limited to the subject of locking of a domain name subject to UDRP Proceedings Currently there is no requirement to lock names in period between filing complaint and commencement of proceedings and no definition of ‘status quo’ Why is it important? 20

21. Should an outline of a proposed procedure that complainant must follow for a registrar to place a domain name on registrar lock, be created Should an outline be created of the steps of the process that a registrar can reasonably expect to take place during a UDRP dispute Should the time frame by which a registrar must lock a domain after a UDRP has been filed be standardized Should what constitutes a “locked" domain name be defined Whether, once a domain name is 'locked' pursuant to a UDRP proceeding, the registrant information for that domain name may be changed Should additional safeguards be created for the protection of registrants in cases where the domain name is locked subject to a UDRP proceeding. Charter Questions 21

22. A WG was formed and has started its deliberations (28 members – all SG represented as well as participants from WIPO & ALAC) One of the first tasks of the WG is to obtain public input WG has developed survey for registrars and UDRP Providers to obtain further input (Please participate!!) GNSO Council has clarified that WG should also consider unlocking Recent Developments 22

23. Deadline for survey responses 10 July Following review of responses received, opening of public comment forum and request for input from SG/C/SO/ACs Timing for publication of Initial Report to be decided – WG is working on work plan & approach Next Steps 23

24. Further Information UDRP Domain Name Lock Open WG Meeting – Thursday 28 June from 9.00 – 10.30 http://prague44.icann.org/node/31807 http://prague44.icann.org/node/31807 https://community.icann.org/display/u drpproceedings/Home https://community.icann.org/display/u drpproceedings/Home 24

25. Questions 25

26. Fake Renewal Notices 26

27. Fake Renewal Notices 27

28. Fake renewal notices are misleading correspondence sent to registrants from an individual or organization claiming to be or to represent the current registrar Registration Abuse Policies WG recommended initiation of PDP on fake renewal notices Council decided to obtain further information on this issue to help inform its deliberations on whether or not to initiate a PDP Why is it important? 28

29. Drafting team formed to prepare a request for information for RrSG DT conducted a survey to obtain input from registrars Nineteen registrars responded to the survey, representing approximately 50% of all gTLD registrations under management Responses were split with registrars either viewing this as a serious problem or not a problem at all Recent Developments 29

30. Report submitted to the GNSO Council in March 2012 Council decided to put report out for public comments - Reply period closed on 11 May, 6 contributions received Council requested DT to review comments received, update report, if deemed appropriate, and report back accordingly Updated report submitted to the GNSO Council on 21 June 2012 Recent Developments (continued) 30

31. Potential Next Steps recommended by DT 31 Options that the GNSO Council may wish to consider as potential next steps: – Add a section to the RAA that addresses Business Practices – Add the issue to the current or one of the upcoming Inter-Registrar Transfer Policy (IRTP) PDPs – Add this issue to the upcoming PDP on the RAA – Add this issue to an upcoming PDP on WHOIS

32. Potential Next Steps recommended by DT 32 – Initiate a Narrowly-Focused Policy Development Process on Fake Renewal Notices – Refer the issue to the At-Large Advisory Committee (ALAC) to encourage better education and awareness of this type of abuse amongst the end-user community – Raise this issue with the Federal Trace Commission (FTC) in the United States to see if the registrar is in compliance with relevant law – Do not proceed with any action at this time

33. Next Steps 33 Council to decide on next steps

34. Fake Renewal Notices Drafting Team Report - http://gnso.icann.org/issues/frn/f ake-renewal-notices-report- 06mar12-en.pdf http://gnso.icann.org/issues/frn/f ake-renewal-notices-report- 06mar12-en.pdf Public comment forum - http://www.icann.org/en/news/pu blic-comment/fake-renewal- notices-report-21mar12-en.htm http://www.icann.org/en/news/pu blic-comment/fake-renewal- notices-report-21mar12-en.htm Further Information 34

35. Questions 35

36. Other Issues 36

37. Over 20 projects active in the GNSO GNSO Project List - http://gnso.icann.org/en/ongoing- work/pending-projects-list.htm http://gnso.icann.org/en/ongoing- work/pending-projects-list.htm Monthly Policy Update - http://www.icann.org/en/resource s/policy/update http://www.icann.org/en/resource s/policy/update Further Information 37

38. Thank You