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

Mon Feb 21 21:47:23 SAST 2011

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 at icann.org 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 at gnso.icann.org
http://gnso.icann.org