Registrar Stakeholder Group Position - Inter-Registrar Transfer Policy Part B

["Clarke D. Walton" <clarke.walton@xxxxxxxxxxxxxx>]

August 8, 2010


Registrar Stakeholder Group Position Regarding
Inter-Registrar Transfer Policy Part B


BACKGROUND

The Registrar Stakeholder Group ("RrSG") has been asked to provide feedback 
regarding the Initial Report for the Inter-Registrar Transfer Policy Part B 
("IRTP B").  This position paper captures the overall sentiment expressed by 
the RrSG members who provided feedback about this matter.  Due to time 
constraints, however, no formal vote regarding this position paper was taken.

RrSG POSITION

The RSG's position on each of the five issues contained in IRTP B is currently 
as follows:


 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 (SAC-40)1.

The RrSG opposes the proposed Expedited Transfer Reverse Policy ("ETRP").  The 
proposed ETRP is overly complex, lacks focus and is probably unworkable in its 
current form.

The RrSG recognizes, however, that the existing Transfer Dispute Resolution 
Policy ("TDRP") is a lengthy process that often does not serve the best 
interests of registrants.


 1.  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.


 1.  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.

Regarding Charter Questions B and C, the IRTP Work Group ("WG") should first 
focus its efforts on defining the term "change of registrant." This 
recommendation was originally made in the RrSG's initial IRTP B comments 
published in October 2009.  Clarifying this term is an important precursor to 
settling disputes between Registrant and Admin Contact, as well as 
understanding what might need to happen when contact information is changed 
just before a transfer request.

Regarding Charter Question C specifically, the RrSG encourages the WG to 
examine the existing processes in place for trying to prevent hijacking 
attempts and the RrSG encourages adoption of these processes by registrars as a 
best practice.  For example, WG participant registrars including Go Daddy, 
Network Solutions and MarkMonitor have referenced a range of processes that 
provide useful models for a best practice.

 1.  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).

 2.  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.
Regarding Charter Questions D (use of locks) and E (denial of transfer request 
due to existing lock - so long as "reasonable means" exists to unlock the 
domain name), the RrSG supports the right of registrars to employ locks as a 
security measure as long as the process for their removal remains consistent 
with ICANN policy.

Finally, the RrSG is concerned that the WG focused a disproportionate amount of 
time and effort on developing the proposed ETRP at the expense of other IRTP B 
issues.  As work continues on IRTP B the RrSG recommends that the WG focus more 
time on consideration of the other IRTP B issues.

CONCLUSION

The opinions expressed by the RrSG in this position paper should not be 
interpreted to reflect the individual opinion of any particular RrSG member.