380 likes | 398 Views
The Inter-Registrar Transfer Policy (IRTP) Part C is currently under review to address issues such as "change of control," time limitations for Forms of Authorization (FOA), and the use of standardized IDs for registrars. This policy aims to improve the domain name transfer process and ensure fairness and innovation in the domain name industry.
E N D
Policy Update Marika Konings
Agenda 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)
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 Group • IRTP Part C WG tasked to address three issues: • "Change of Control" function • Should Form Of Authorization (FOA)s be time-limited • 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
Charter Question A 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 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 Issues 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 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 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 Issues 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 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 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 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 Issues Any unforeseen impacts of the proposed recommendation?
Next Steps 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)
Why is it important? • 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’ 20
Charter Questions • 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. 21
Recent Developments • 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 22
Next Steps • 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 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
Why is it important? • 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 28
Recent Developments • 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 29
Recent Developments (continued) • 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 30
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 PotentialNext Steps recommended by DT
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 Potential Next Steps recommended by DT
Council to decide on next steps Next Steps
Further Information • 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 34
Further Information • 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 37