RE: [gnso-irtp-b-jun09] For your review - new proposed language for Recommendation #4

["Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>]

I support these changes, with the caveat that the third sentence in the
Notes/Deliberations section should read that "data on the frequency of
hijackings SHOULD (vice "will") become available through the
introduction of the TEAC (note the added "T") recommended in this
report."  

 

Best, P

 

________________________________

From: owner-gnso-irtp-b-jun09@xxxxxxxxx
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Marika Konings
Sent: Wednesday, May 25, 2011 9:36 AM
To: Gnso-irtp-b-jun09@xxxxxxxxx
Subject: [gnso-irtp-b-jun09] For your review - new proposed language for
Recommendation #4
Importance: High

 

Dear All,

 

Please find below the proposed new language for recommendation #4, as
developed by James and Simonetta. You are encouraged to share your views
(any objections?) / comments and/or proposed edits with the mailing list
as soon as possible.

 

Thanks,

 

Marika

 

========================================

 

Recommendation #4 (NEW): 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 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 that can be used as a best practice for the gTLD
space, and any associated security concerns. The policy recommendations
should include a review of locking procedures, as described in Reasons
for Denial #8 and #9, with an aim to balance legitimate transfer
activity and security. Recommendations should be made based on the data
needs identified in the IRTP-B workgroup discussions and should be
brought to the community for public comment. The WG would like to
strongly encourage the GNSO Council to include these issues (change of
control and 60-day post-transfer lock) as part of the next IRTP PDP and
ask the new working group to find ways to quantify their recommendations
with data.

 

Included as part of the notes / deliberations: The working group
discussed whether the introduction of stricter locking procedures after
a domain name transfer might be prudent to ease the resolution of
hijacking issues, as well as other enforcement / takedown problems. At
this point the working group lacked access to data on the number of
hijacking cases with resolution problems due to the transfer hopping
practice vs. the number of legitimate transfers benefitting of a less
stringent locking policy and could therefore not come to consensus on
the locking topic. Data on the frequency of hijacking cases will become
available through the introduction of the EAC recommended in this
report. Data on legitimate transfer activity benefitting from the
current locking policy wording needs to be collected. The WG notes that
the 60-day post-transfer lock is currently optional (IRTP Reason for
Denial #9), and that most large registrars follow this practice. It is
however currently possible to ask for the removal of a lock (or not
apply it in the first place) which would no longer exist should the
policy be changed.  The WG would like to emphasize that reason of denial
#9 relates to a transfer, not to a change of control (change of
registrant), although the WG realized as a result of its deliberations
that transfers are often closely linked to a change of control. The WG
recommends that the issue of transfer 'hopping' after hijacking be
considered in conjunction with the issue of the lacking "change of
control" function while also taking a review of the domain locking
options in IRTP into account. All three pieces should be included as
part of the Issue Report on "change of control" (see recommendation #4).