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

["Mike O'Connor" <mike@xxxxxxxxxx>]

several thoughts.

on page 24 of Marika's draft, in the notes/deliberations leading up to 
Recommendation 6, we have the following language:

The WG requested specific input on this issue in its proposed Final Report and 
discussed the option of making the 60-day lock following a transfer and/or 
initial registration mandatory instead of optional. However, as concerns were 
expressed in relation to the lack of data (e.g. how often do hijackings occur 
which are further complicated by transfer “hopping”, how often are legitimate 
repeated transfers made that would be hindered by a mandatory lock, how many 
registrars already use the 60-day lock following a transfer or initial 
registration), the WG decided that further discussion and research would need 
to be conducted in conjunction with the ‘change of control’ issue (see 
recommendation #4).
 are we planning to replace this?  if not, we'll want to reword it to be 
consistent with Simonetta/James' proposal


hijacking data
another point.  TEAC data will give us *some* insight into the number of 
hijackings, but (hopefully) a very small percentage of them -- because most 
hijackings are resolved without having to invoke a TEAC.   so i would suggest 
strengthening this sentence:


"Data on the frequency of hijacking cases will become available through the 
introduction of the [T]EAC recommended in this report."

to read something like...

"Data on the frequency of hijacking cases is a pivotal part of this analysis.  
Mechanisms should be explored to develop accurate data around this issue in a 
way that meets the needs of registrars to protect proprietary information while 
at the same time providing a solid foundation for data-based policy-making."

domain name community

i'd broaden this sentence:

"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"

by removing the reference to the domain name community -- it's true that they 
use it that way, but lots of other people use the transfer process to 
accomplish the change of control, even though they wouldn't consider themselves 
part of the domain name community.  so how about this

"The WG also notes that IRTP is widely used to affect a "change of control," 
moving the domain name to a new Registered Name Holder"



On May 25, 2011, at 8:35 AM, Marika Konings wrote:

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

- - - - - - - - -
phone   651-647-6109  
fax             866-280-2356  
web     http://www.haven2.com
handle  OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)