[council] Public Comment: Inter-Registrar Transfer Policy Part B Working Group Presents Proposed Final Report

[Glen de Saint Géry <Glen@xxxxxxxxx>]

http://www.icann.org/en/announcements/announcement-21feb11-en.htm
Public Comment: Inter-Registrar Transfer Policy Part B Working Group Presents 
Proposed Final Report

Nine (9) Recommendations for Community Consideration

21 February 2011

The GNSO Inter-Registrar Transfer Policy (IRTP) Part B Policy Development 
Process Working Group was tasked to address five issues focusing on issues 
related to domain hijacking, the urgent return of an inappropriately 
transferred name and "lock status". Following review of the public comments 
received on the Initial Report and further deliberations, the Working Group now 
presents its proposed Final Report which contains nine (9) recommendations to 
address the five charter questions it was tasked with. Before finalizing its 
report and submitting it to the GNSO Council for its consideration, the Working 
Group is asking for your input on the proposed Final Report, especially the 
proposed recommendations. Comments can be submitted until 31 March 2011.

For those interested, the IRTP Part B Working Group will present its report and 
proposed recommendations at the ICANN meeting in San Francisco (see 
http://svsf40.icann.org/sched-overview for further details).

The Recommendations
Recommendation #1: The WG is considering recommending requiring registrars to 
provide an Emergency Action Channel (as described in SAC007 [PDF, 400 KB]). The 
WG recognizes that there are further details that would need to be worked out 
in relation to this proposal such as:

Within what timeframe should a response be received after an issue has been 
raised through the Emergency Action Channel (for example, 24 hours - 3 days has 
been the range discussed by the WG)? 
What qualifies as 'a response'? Is an auto-response sufficient? 
Should there be any consequences when a response is not received within the 
required timeframe? 
Is there a limited time following a transfer during which the Emergency Action 
Channel can be used? 
Which issues may be raised through the Emergency Action Channel? 
How/who should document the exchanges of information on the Emergency Action 
Channel? 
Who is entitled to make use of the Emergency Action Channel? 
The WG is requesting input from the ICANN Community on these questions and the 
recommendation itself, so this can be factored into the WG deliberations going 
forward.

Recommendation #2: The WG notes that in addition to reactive measures such as 
outlined in recommendation #1, proactive measures to prevent hijacking are of 
the utmost importance. As such, the WG strongly recommends the promotion by 
ALAC and other ICANN structures of the measures 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). In particular, the IRTP 
WG recommends that registrants consider the measures to protect domain 
registrar accounts against compromise and misuse described in SAC044, Section 
5. These include practical measures that registrants can implement "in house", 
such as ways to protect account credentials and how to incorporate domain name 
registrations into employee or resource management programs typically found in 
medium and large businesses. It suggests ways that registrants can use renewal 
and change notifications from registrars as part of an early warning or 
alerting system for possible account compromise.

Recommendation #3: The WG recommends requesting an Issues Report on the 
requirement of 'thick' WHOIS for all incumbent gTLDs. The benefit would be that 
in a thick registry one could develop a secure method for a gaining registrar 
to gain access to the registrant contact information. Currently there is no 
standard means for the secure exchange of registrant details in a thin 
registry. In this scenario, disputes between the registrant and admin contact 
could be reduced, as the registrant would become the ultimate approver of a 
transfer. Such an Issue Report and possible subsequent Policy Development 
Process should not only consider a possible requirement of 'thick' WHOIS for 
all incumbent gTLDs in the context of IRTP, but should also consider any other 
positive and/or negative effects that are likely to occur outside of IRTP that 
would need to be taken into account when deciding whether a requirement of 
'thick' WHOIS for all incumbent gTLDs would be desirable or not.

Recommendation #4: The WG notes that the primary function of IRTP is to permit 
Registered Name Holders to move registrations to the Registrar of their choice, 
with all contact information intact. The WG also notes that IRTP is widely used 
in the domain name community to affect a "change of control," moving the domain 
name to a new Registered Name Holder. The discussions within the WG and with 
ICANN Staff have determined that there is no defined "change of control" 
function. Therefore, the IRTP-B WG recommends requesting an Issue Report to 
examine this issue, including an investigation of how this function is 
currently achieved, if there are any applicable models in the country-code name 
space, and any associated security concerns.

Recommendation #5: The WG recommends modifying section 3 of the IRTP to require 
that the Registrar of Record/Losing Registrar be required to notify the 
Registered Name Holder/Registrant of the transfer out. The Registrar of Record 
has access to the contact information for the Registrant and could modify their 
systems to automatically send out the Standardized Form for Losing Registrars 
("Confirmation FOA") to the Registrant. 

Recommendation #6: The WG does recognize that the current language of denial 
reason #6 is not clear and leaves room for interpretation especially in 
relation to the term 'voluntarily' and recommends therefore that this language 
is expanded and clarified to tailor it more to explicitly address 
registrar-specific (i.e. non-EPP) locks in order to make it clear that the 
registrant must give some sort of informed opt-in express consent to having 
such a lock applied, and the registrant must be able to have the lock removed 
upon reasonable notice and authentication. The WG recommends to modify denial 
reason #6 as follows: Express objection to the transfer by the Transfer 
Contact. Objection could take the form of specific request (either by paper or 
electronic means) by the Transfer Contact to deny a particular transfer 
request, or a general objection to all transfer requests received by the 
Registrar, either temporarily or indefinitely. In all cases, the objection must 
be provided with the express and informed consent of the Transfer Contact on an 
opt-in basis and upon request by the Transfer Contact, the Registrar must 
remove the lock or provide a reasonably accessible method for the Transfer 
Contact to remove the lock within five (5) calendar days.

Recommendation #7: The WG recommends that 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 taken into consideration.

Recommendation #8: The WG recommends standardizing and clarifying WHOIS status 
messages regarding Registrar Lock status. The goal of these changes is to 
clarify why the Lock has been applied and how it can be changed. Based on 
discussions with technical experts, the WG does not expect that such a 
standardization and clarification of WHOIS status messages would require 
significant investment or changes at the registry/registrar level. The WG 
recommends that ICANN staff is asked to develop an implementation plan for 
community consideration which ensures that a technically feasible approach is 
developed to implement this recommendation.

Recommendation #9: The WG recommends deleting denial reason #7 as a valid 
reason for denial under section 3 of the IRTP as it is technically not possible 
to initiate a transfer for a domain name that is locked, and hence cannot be 
denied, making this denial reason obsolete. Instead denial reason #7 should be 
replaced by adding a new provision in a different section of the IRTP on when 
and how domains may be locked or unlocked. The WG recommends that ICANN staff 
is asked to develop an implementation plan for community consideration 
including proposed changes to the IRTP to reflect this recommendation.

Background
The IRTP Part B Policy Development Process (PDP) is the second in a series of 
five PDPs that address areas for improvements in the existing Inter-Registrar 
Transfer Policy. The Inter-Registrar Transfer Policy (IRTP) aims to provide a 
straightforward procedure for domain name holders to transfer their names from 
one ICANN-accredited registrar to another should they wish to do so. The policy 
also provides standardized requirements for registrar handling of such transfer 
requests from domain name holders. The policy is an existing community 
consensus policy that was implemented in late 2004 and is now being reviewed by 
the GNSO.

Deadline and how to submit comments

Comments are welcome via e-mail to irtp-b-proposed-final-report@xxxxxxxxx until 
31 March 2011.

Access to the public comment forum from which comments can be posted can be 
found at: 
http://www.icann.org/en/public-comment/public-comment-201103-en.htm#irtp-b-proposed-final-report

An archive of all comments received will be publicly posted at: 
http://forum.icann.org/lists/irtp-b-proposed-final-report/

Further information

IRTP Part B PDP Proposed Final Report [PDF, 734 KB]
IRTP Part B PDP Proposed Final Report - Executive Summary only [PDF, 320 KB]

IRTP Part B PDP Initial Report [PDF, 765 KB]

Inter-Registrar Transfer Policy (IRTP)

Staff responsible: Marika Konings


Glen de Saint Géry
GNSO Secretariat
gnso.secretariat@xxxxxxxxxxxxxx
http://gnso.icann.org