Summary and analysis of public comments for the Inter-Registrar Transfer Policy Part B Policy Development Process

[Marika Konings <marika.konings@xxxxxxxxx>]

Disclaimer: This summary is not a full and complete recitation of the relevant 
comments received. It is an attempt to capture in broad terms the nature and 
scope of the comments. This summary has been prepared in an effort to highlight 
key elements of these submissions in an abbreviated format, not to replace 
them. Every effort has been made to avoid mischaracterizations and to present 
fairly the views provided. Any failure to do so is unintentional. The comments 
may be viewed in their entirety at http://forum.icann.org/lists/irtp-b/.

Summary and analysis of public comments for the Inter-Registrar Transfer Policy 
Part B Policy Development Process

Comment period ended: 5 October 2009

Summary published: 14 October 2009

Prepared by: Marika Konings, Policy Director

I.             GENERAL COMMENTS and CONTRIBUTIONS

Seven (7) community submissions from six different parties have been made to 
the public comment forum. The contributors are listed below in alphabetical 
order (with relevant initials noted in parentheses):

Bob Ross (BR)
Charles Christopher (CC)
Patrick Mevzek (PM)
Pieter van Ieperen (PI)
Registrar Constituency by Clarke D. Walton (RC)
WIPO Arbitration and Mediation Center (WIPO)

II.           SUMMARY & ANALYSIS

Three submissions (BR, CC) related to issues not of relevance to the charter 
questions, such as Whois accuracy, privacy and a complaint relating to a 
specific registrar. The other contributors provided input on the different 
charter questions or other related issues for consideration. A summary of all 
comments can be found hereunder.

In relation to the charter questions, the following comments were submitted:

1.    Whether a process for urgent return/resolution of a domain name should be 
developed, as discussed within the Security and Stability Advisory Committee 
(SSAC) hijacking report 
(http://www.icann.org/announcements/hijacking-report-12jul05.pdf [PDF, 400K]); 
see also (http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm);

PM questions whether the incidence of a few hijacking cases warrants the 
development of a new procedure and recommends that the WG first assesses the 
effectiveness of the existing Transfer Dispute Resolution Policy (TDRP) to 
determine whether any modifications should be made there or whether it should 
be replaced. PM also wonders how it would be possible to unite urgent return 
with due diligence, as the latter requires sufficient time while the former 
requires rapid action. As in his view the problem does not lie with the actual 
transfer, but with the DNS change, he suggests to recommend 'no domain updates 
possible for one week after a finished transfer, so that it gives time to 
intervene if it happens that the transfer by itself was fraudulous'.

The RC also supports the possible adjustment and refinement of the TDRP to 
reduce the overall timeframe to resolve disputes, which might make the need for 
a separate procedure obsolete. In addition, the RC suggests discussion of 'best 
practices for the voluntary transfer of names in cases of fraud'.

2.    Whether additional provisions on undoing inappropriate transfers are 
needed, especially with regard to disputes between a Registrant and Admin 
Contact (AC). The policy is clear that the Registrant can overrule the AC, but 
how this is implemented is currently at the discretion of the registrar;

PM proposes that either the AC is made the authoritative contact which would 
not allow the reversal of a transfer by the Registrant, or the approval of both 
the Admin Contact and the Registrant would be required to complete a transfer.

WIPO suggests the inclusion of provisions that would require a registrar to 
undo an inappropriate transfer of a domain name that is subject to UDRP 
proceedings, which would therefore be in violation of an obligation of the 
registrant under paragraph 8 of the UDRP policy.

In the opinion of the RC, the current policy is clear concerning disputes 
between the Admin Contact and the registrant. The RC notes that if the policy 
is not adhered to by registrars, ICANN should consider providing additional 
guidance to registrars in the form of an advisory.

3.    Whether special provisions are needed for a change of registrant when it 
occurs near the time of a change of registrar. The policy does not currently 
deal with change of registrant, which often figures in hijacking cases;

PM supports that 'any kind of changes such as transfers or contacts / 
registrant change should be followed by a cooling off period where nothing else 
could happen', but proposes that such a cooling off period should not be longer 
than 10 days.

4.    Whether standards or best practices should be implemented regarding use 
of a Registrar Lock status (e.g. when it may/may not, should/should not be 
applied);

PM recommends that 'any discussion be put in line with the current protocols as 
"Registrar-Lock" was used with RRP which is now superseded by EPP'. He notes 
that as a result, there are a number of different statuses available to the 
registrar and assumes that this question relates to the 
'clientTransferProhibited' status value. In his view, the use of this status by 
registrars should not be limited, but instead it should be possible for 
registrants 'to change this status online through their respective registrars'. 
PM points out that 'in EPP, each status value can be associated with a message 
(in any language) [...], explaining the reason of the status. This message is 
optional and seems to be seldom used, but it could be useful for registrars to 
provide it as it would give an explanation for the basis that enabled this 
status value'.

PI proposes specific language for inclusion in chapter 3 (Obligations of the 
Registrar of Record) of the transfer policy similar to that in chapter 5 (EPP - 
based Registry Requirements for Registrars) to ensure that the domain is 
unlocked within five days of receipt of a request by registrant, unlocking is 
not more restrictive than other mechanisms used to make changes and unlocking 
is not refused on the basis of a conflict between the registrant and registrar 
over payment. PI also advocates that the lock status in the registry should be 
the same as the lock status at the registrar, so no hidden lock.

WIPO recommends the 'inclusion of provisions strengthening that domain names 
subject to UDRP proceedings must be locked by the Registrar of Record for the 
pendency of a UDRP proceeding', in addition to additional guidance to 
registrars on how to use the lock status in the case of UDRP proceedings. PI 
proposes specific language to address this issue.

5.    Whether, and if so, how best to clarify denial reason #7: A domain name 
was already in 'lock status' provided that the Registrar provides a readily 
accessible and reasonable means for the Registered Name Holder to remove the 
lock status.

PM recommends that registrars 'should be required to document why a domain is 
in clientTransferProhibited status'. In addition, yearly checks should be 
carried out to verify that clients can lock and unlock as they please.

General comments and other considerations

As a general comment, PM questions the need for policy development to address 
issues that have only occurred once or twice pointing out that 'whatever 
policies and technical solutions are put in place, there always will be a 
percentage of unavoidable problems'.

WIPO requests that the WG also gives consideration to the potential impact on 
the Uniform Domain Name Dispute Resolution Policy (UDRP) and points to 
confusion over and the different interpretations of the provisions relating to 
denial of a transfer of domains subject to UDRP proceedings. WIPO points out 
that the current provisions state that the registrar of record 'may' deny a 
transfer if the domain name is subject to a UDRP proceeding, while 'must' 
should be the appropriate term and request the WG to consider 'the inclusion of 
such safeguard provisions in the Policy'.

The RC points to the importance of developing definitions for the different 
terms used in the charter questions to ensure correct understanding of the 
different concepts. In addition, the RC notes that 'domain name transfer issues 
must always be considered along with relevant security issues'.

III.           NEXT STEPS

The Inter-Registrar Transfer Policy Part B Working Group is expected to 
consider all the relevant comments as part of their deliberations on the 
charter questions.

IV.              BACKGROUND

The Inter-Registrar Transfer Policy (IRTP) 
<http://www.icann.org/en/transfers/policy-en.htm> aims to provide a 
straightforward procedure for domain name holders to transfer their names from 
one ICANN-accredited registrar to another. The policy is an existing GNSO 
consensus policy (for more information about consensus policies, please see 
http://www.icann.org/en/general/consensus-policies.htm) that was implemented in 
late 2004 and is now being reviewed by the GNSO Council. In order to facilitate 
this review, the Council has sub-divided the issues and initiated a Policy 
Development Process (PDP) on those issues grouped together in part B on 24 June 
2009. An IRTP Part B Working Group was chartered to review and provide 
recommendations on the following issues:


 *   Whether a process for urgent return/resolution of a domain name should be 
developed, as discussed within the Security and Stability Advisory Committee 
(SSAC) hijacking report 
(http://www.icann.org/announcements/hijacking-report-12jul05.pdf [PDF, 400K]); 
see also (http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm);
 *   Whether additional provisions on undoing inappropriate transfers are 
needed, especially with regard to disputes between a Registrant and Admin 
Contact (AC). The policy is clear that the Registrant can overrule the AC, but 
how this is implemented is currently at the discretion of the registrar;
 *   Whether special provisions are needed for a change of registrant when it 
occurs near the time of a change of registrar. The policy does not currently 
deal with change of registrant, which often figures in hijacking cases;
 *   Whether standards or best practices should be implemented regarding use of 
a Registrar Lock status (e.g. when it may/may not, should/should not be 
applied);
 *   Whether, and if so, how best to clarify denial reason #7: A domain name 
was already in 'lock status' provided that the Registrar provides a readily 
accessible and reasonable means for the Registered Name Holder to remove the 
lock status.