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

[Marika Konings <marika.konings@xxxxxxxxx>]

Disclaimer: This summary is not a full and complete recitation of the relevant 
commentsreceived. 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-proposed-final-report/.

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

Comment period ended: 31 March 2011

Summary published: 5 April 2011

Prepared by: Marika Konings, Senior Policy Director


I.               BACKGROUND


The Inter-Registrar Transfer 
Policy<http://www.icann.org/en/transfers/policy-en.htm> (IRTP) 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:

a)     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);
b)     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;
c)     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;
d)     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);
e)     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.


The IRTP Part B PDP Working Group published its Initial Report on 29 May 2010. 
Following review of the comments received on the Initial Report and 
furtherdeliberations, the Working Group published its Proposed Final 
Report<http://gnso.icann.org/issues/transfers/irtp-b-proposed-final-report-21feb11-en.pdf>
 and opened a public comment forum.


II.              GENERAL COMMENTS and CONTRIBUTIONS

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

At-Large Advisory Committee by Olivier Crepin-Leblond (ALAC)
Commercial & Business Users Constituency by Steve DelBianco (BC)
GoDaddy.com by James Bladel (GD)
gTLD Registries Stakeholder Group by David Maher (RySG)
Internet Commerce Association by Philip Corwin (ICA)
Internet Committee of the International Trademark Association by Claudio Di 
Gangi (INTA)
Registrar Stakeholder Group by Clarke Walton (RrSG)


III.            SUMMARY & ANALYSIS



General Comments



ALAC and RrSG express their general support for all the recommendations in the 
Report, in addition to some specific comments that can be found below.



Charter Question A / Recommendation #1



In relation to recommendation #1, the RrSG, RySG, INTA, BC and GD note their 
general support for the concept and intent of requiring an Emergency Action 
Channel(EAC).



The RySG notes that a longer response time (up to 72 hours) ‘may be necessary 
to accommodate smaller registrars that are not staffed 24X7’. The RySG also 
raises the point to what extend registries should be involved in an EAC, as in 
sponsored registries the registrant may be known and the registry may be able 
to assist.



INTA expresses its support for the development of a policy to accompany the ECA 
which ‘takes into account criteria including immediacy of harm to 
theregistrant, magnitude of the harm to third parties, and escalating impact, 
if the transfer is not reversed’.



ICA notes that ‘many important elements […] remain to be worked out’ and 
recommends that these should be developed consistent with ‘true emergency 
situations and not to cause substantial potential disruption to the secondary 
domain marketplace’.



The RrSG recommends that the IRTP Part B WG remains responsible for the ‘design 
and implementation of a proposed Emergency Action Channel’.



In the public comment forum, the WG asked a number of specific questions in 
relation to the ECA:



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



The RySG response to this question ranges from 24 hours (more than half of the 
registries, 48 hours (one registry) to 72 hours (one registry).



INTA and GD would support a response time of 24 hour maximum.



ALAC and the BC support a ‘short a period as practical’ with ALAC noting that 
this should be well under 24 hours and the BC recommending 6-12 hours.



What qualifies as a response?



‘Most members of the RySG feel that at a minimum, a positive confirmation of 
receipt and initial human contact is appropriate’.  The BC also notes that a 
non-automated response would be preferable but ‘would defer to registrars and 
registries in determining what qualifies as “a response” (email, phone call, 
fax, etc.)’.



ICA noted that the different responses ‘must be clearly delineated and 
mechanisms must be set in place to prevent abuse of the EAC in non-emergency 
situations’.



Is an auto-response sufficient?



ALAC as well as most registries are of the view that an auto-response is not 
sufficient. In addition, the RySG notes that ‘the goal of the EAC should be to 
resolve the issue not to merely advise the receiving registrar that an issue 
exists’. INTA also agrees that an auto-response is not sufficient, but does 
support ‘auto-responses during the process to keep the parties informed of the 
progress of the complaint’.



GD suggests that ‘ICANN Compliance test this channel periodically to ensure a 
non-automated response’.



Should there be any consequences when a response is not received within the 
required timeframe?



ALAC, INTA and the RySG agree that there should be consequences when a response 
is notreceived. The RySG notes that such consequences might follow defined 
escalation paths, including warnings and could even include termination of the 
accreditation by ICANN in case of multiple violations. INTA proposes that 
consequences could range ‘from requiring specific remedial actions by the 
registrar, composing monetary fines, to imposing liability on the registrar’. 
ALAC suggests that ‘consequences should include a provision for the registry 
unilaterally reversing the transfer and possible fines’. The RySG suggests that 
in the first year of implementation, ‘consequences should be more lenient’.



GD suggests that ICANN Compliance ‘issue reports or warnings’ in case 
registrars do not provide non-automated responses.



ICA furthermore recommends that ‘effective sanctions must be established 
against a domain seller who initiates an illicit reversal action’.



The BC notes its response for modifying the IRTP ‘to mandate a transfer-undo in 
cases where the gaining registrar does not respond in a timely way to an 
emergency-action request regarding a suspected domain name hijacking’.



Is there a limited time following a transfer during which the Emergency Action 
Channel can be used?



Responses varied to this question in the RySG, but the RySG recommends that 
‘this channel must be invoked within 7 days of the alleged incident. After this 
period, and for other non-urgent or non-emergency situations, the existing 
communication channels and Transfer Dispute Resolution Policy process could be 
used’.



INTA recommends that action should be taken by the registrant ‘within three 
days of discovering the transfer’. INTA notes that ‘if a time limit was set 
based on the transfer date, hijackers would likely take advantage of this by 
waiting to inflict harm until just after the time limit expired’.



ICA notes that ‘the time period in which a domain transfer reversal can be 
sought must be far shorter than six months post transfer’.



Both the ALAC and BC would support a reasonably long window, with the BC 
suggesting a range of 60-180 days.



Which issues may be raised through the Emergency Action Channel?



Registry responses also varied to this question, but the RySG notes that ‘the 
criteria detailed in the SSAC report would be a good starting point’.



ICA is of the view that the ECA should only be used for ‘true crisis situations 
under a clear and narrow definition of “emergency” that is based upon current 
and reliable metrics of actual, non-hypothetical instances of abuses, 
includingthose arising from fraud and deception’. The RrSG also agrees that 
‘the nature of emergencies to be handled via such channel must be precisely 
defined’.



The BC and ALAC note that the ECA might also be useful for issues outside the 
scope of this PDP, and although not in scope for consideration by this WG, 
should not be precluded.



How/who should document the exchanges of information on the Emergency Action 
Channel?



The BC ‘defers to registries and registrars when it comes to documenting 
successful exchanges’ as well as ‘how those unsuccessful exchanges are 
documented and communicated to the registry’.



Who is entitled to make use of the Emergency Action Channel?



Again, opinions vary in the RySG; some registries are of the opinion that it 
should ‘only be available to the registrant’, others are of the view that ‘it 
should be limited to an authorized list of registrar and registry contacts’ and 
‘approved contacts of recognized security and stability oriented groups’. The 
RySG notes that ‘more analysis / discussion is warranted’.



INTA is of the opinion that the ECA may be used by ‘aggrieved registrants to 
raise the issues of hijacking or erroneous transfers’.



GD recommends that ‘use be reserved for inter-registrar and ICANN-registrar 
communications, and only in situations where a timely response is critical’.



The RrSG assumes the ECA can only be used by registrars and/or ICANN, and notes 
it only supports the ECA if communication is limited between those parties to 
serious and urgent domain name related emergencies.



The BC notes that it ‘does not envision that registrants’ would have access to 
the ECA.



Charter Question A / Recommendation #2



The RySG notes that ‘most of the registries agree with this recommendation’.



ALAC recognizes the importance of registrant education and notes that ‘ALAC and 
At-Large may be considered one of the possible channels’ for the implementation 
of this recommendation.



The BC also notes its support for a proactive approach and offers its support 
for ‘developing and promoting best practices in this area’.



Charter Question B – Recommendation #3



The RySG notes that ‘all but one registry agreed with this recommendation’. The 
one registry that did not agree with this recommendation noted that ‘ICANN 
staff and GNSO volunteers are overloaded at this time’.



INTA expresses its support for this recommendation.



GD recognizes the benefits of thick WHOIS in the context of transfers, but 
recommends that ‘unintended consequences of requiring this change, particularly 
with large incumbent registries’ should also be considered.



ICA notes no objection to this recommendation.



The BC also notes its support for this recommendation, but also suggest that an 
alternative approach that could be explored would be direct conversations with 
incumbent “thin” registries about a possible change to “thick” WHOIS.



Charter Question B – Recommendation #4



The RySG notes that ‘all but one registry agreed with this recommendation’. The 
one registry that did not agree with this recommendation noted that ‘ICANN 
staff and GNSO volunteers are overloaded at this time’.



INTA, the BC and GD express support for this recommendation.



ICA notes no objection to this recommendation



Charter Question B – Recommendation #5



The RySG notes that again ‘all but one registry agreed with this 
recommendation’. The registry that did not agree pointed out that ‘notification 
would be a good thing but only if the registrant is not held hostage by the 
losing registrar presenting misleading information’. GD similarly supports the 
recommendation as long as ‘the transfer is not delayed or dependent upon any 
action on the part of the “losing” registrar’.



The BC also expresses its support for this recommendation.



Charter Question C



The BC notes its support for ‘requiring a lock after WHOIS information is 
updated when that update effects a change of registrant’, in addition to 
‘prohibiting a transfer of a domain name registration for 60-days following a 
transfer, which is currently an option under reason of denial #9 in the IRTP’.



Charter Question C – Recommendation #6



The RySG notes that ‘most registries agree with this recommendation’, although 
one registry did point out that the term “reasonable” must be clearly defined 
‘as ‘some registrants have been asked for rather onerous documentation 
requirements when a contact is no longer an employee/associated with a domain 
and a new contact is trying to prove that they are an authorized agent for the 
domain’. In addition, a registry recommended that ‘the clarification needs to 
accommodate court orders’.



INTA expresses its support for this recommendation, noting that ‘it would help 
with both preventing fraudulent transfer and allowing legitimate owners to 
recover domain names and place them with their registrar of choice within an 
acceptable period’.  INTA does request that an exception should be considered 
for registrations acquired as part of a successful UDRP since ‘if a change of 
registrant occurs after a UDRP or equivalent action, it is very likely that the 
domain name is being transferred back to the rightful owner and no limitations 
should exist as to how long the rightful owner should be required to keep the 
domain at a particular registrar’.



GD and the BC also note their support for this recommendation.



Charter Question D – Recommendation #7



The RySG expresses its support for this recommendation.



ICA notes no objection to this recommendation.



The BC expresses its support for this recommendation, noting that it ‘would 
also support elevating this recommendation from an optional “best practice” to 
a policy change that makes this kind of lock mandatory’. Furthermore the BC 
‘would also support proceeding with this change as part of this PDP’.



Charter Question D – Recommendation #8



All but one member of the RySG support this recommendation. The one registry 
memberthat disagrees noted that ‘it must be done in accordance with any 
existing ICANN/registry agreement requirements’.



The BC also expresses its support for this recommendation.



Charter Question E – Recommendation #9



The BC and the RySG express support this recommendation.



ICA notes no objection to this recommendation.



IV.            NEXT STEPS


The Inter-Registrar Transfer Policy Part B Working Group is expected to 
consider all the relevant comments as part of their deliberations and efforts 
to finalize the report for submission to the GNSOCouncil.