Policy Update

Marika Konings

AgendaAgenda

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)

Inter-Registrar Transfer Policy

Part C

3

Why is it important?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

IRTP Part C PDP Working GroupIRTP Part C PDP Working Group

• IRTP Part C WG tasked to address three issues: a) "Change of Control" functionb) Should Form Of Authorization (FOA)s be time-

limitedc) 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

Initial Report Recommendations

6

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

Requirements of New PolicyRequirements 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

Open IssuesOpen 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?

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.

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

Open IssuesOpen 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?

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

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’

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.

Open IssuesOpen Issues

16

• Any unforeseen impacts of the proposed recommendation?

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

• 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)

Questions

18

Locking of a Domain Name Subject to UDRP Proceedings PDP WG

19

• 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

• 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

• 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

• 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

Further Information

• UDRP Domain Name Lock Open WG Meeting – Thursday 28 June from 9.00 – 10.30 http://prague44.icann.org/node/31807

• https://community.icann.org/display/udrpproceedings/Home

24

Questions

25

Fake Renewal Notices

26

Fake Renewal NoticesFake Renewal Notices

27

• 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

• 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

• 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

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

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

Next Steps

33

• Council to decide on next steps

• Fake Renewal Notices Drafting Team Report - http://gnso.icann.org/issues/frn/fake-renewal-notices-report-06mar12-en.pdf

• Public comment forum - http://www.icann.org/en/news/public-comment/fake-renewal-notices-report-21mar12-en.htm

Further Information

34

Questions

35

Other Issues

36

• Over 20 projects active in the GNSO

• GNSO Project List - http://gnso.icann.org/en/ongoing-work/pending-projects-list.htm

• Monthly Policy Update - http://www.icann.org/en/resources/policy/update

Further Information

37

Thank You