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

["Sedo :: Simonetta Batteiger" <simonetta@xxxxxxxx>]

Sounds good to me, that change makes sense.
Simonetta

From: owner-gnso-irtp-b-jun09@xxxxxxxxx 
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Diaz, Paul
Sent: Wednesday, May 25, 2011 4:20 PM
To: Marika Konings; Gnso-irtp-b-jun09@xxxxxxxxx
Subject: RE: [gnso-irtp-b-jun09] For your review - new proposed language for 
Recommendation #4

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