[gnso-irtp-b-jun09] 60 day lock minority viewpoint

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

Hi Everybody,

I would like to add a minority viewpoint to the following section of our final 
report (language still needs adjustment, I'm not sure in what format a minority 
viewpoint would usually be written):

[Recommendation #7: The WG notes that the problem of domain transfer 'hopping' 
between registrars is a known issue, and can be used to thwart anti-hijacking 
issues, as well as create other enforcement / takedown problems. 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. The WG, 
therefore, recommends moving reason for denial #8 (‘The transfer was requested 
within 60 days of the creation date as shown in the registry Whois record for 
the domain name.’) and #9 (‘A domain name is within 60 days (or a lesser period 
to be determined) after being transferred (apart from being transferred back to 
the original Registrar in cases where both Registrars so agree and/or where a 
decision in the dispute resolution process so directs)’) out of the criteria 
for which registrars MAY deny a transfer, and create a new section for these 
situations under which registrars SHALL deny a transfer. The WG would like to 
emphasize that reason of denial #9 relates to a transfer, not to a change of 
control (change of registrant). ]

Minority viewpoint:
Based on feedback received from registrants, some registrars and also several 
domain marketplaces I disagree with this recommendation for the following 
reasons:
1) There is considerable concern in the domain community about placing further 
restrictions on domain transfers. There is no quantifiable data on the amount 
of hijacking cases vs. the amount of regular and legitimate domain name 
transfers. Placing additional burdens on legitimate transfer activity does not 
seem justified when there is no data on the frequency of domain hijacking 
cases. In addition there is no data on which subset of hijacked domains start 
transfer hopping from registrar to registrar multiple times. 
2) There are other ways to prevent domain name transfer hopping after a 
hijacking has happened: it would e.g. be possible to stop this behavior by 
placing a registry lock on the name the moment a TEAC communication in regards 
to a hijacking case has been started through RADAR.
3) The recommendation listed above will not prevent hijackings from happening - 
it will however place additional burdens on regular transfer activity. This 
language would e.g make it harder to transfer a domain back should an error 
have been made, makes it harder to consolidate a domain portfolio in one 
location (which in itself poses risks for registrants) or disallows for 
legitimate transfer activity with multiple transfers within a two month period. 
More focus should be placed on preventing hijacking cases in the first place 
rather than attempting to cure one of the symptoms with a measure that has 
undesirable consequences for legitimate transfer activity.
4) No feedback from the community has been received on this recommendation 
language. The language suggests a significant change of the IRTP policy and 
introduces a concept of a mandatory domain lock into a policy that so far only 
knows voluntary locks. I would like to see further discussion on this item to 
ensure that all voices in the community are heard about this proposed change to 
the IRTP policy. This discussion should include some background on why the 
current policy language has been worded as MAY rather than SHALL.
5) We will receive data on the frequency of domain name hijackings through the 
TEAC activity logging. We should wait for this data to then be able to quantify 
the issue in relation to the amount of legitimate transfer activity to see if 
such drastic policy changes are justified.
6) Based on a poll in relation to this question we saw one third of respondents 
disagree with this recommendation. 


Please let me know if this language is clear or if you have questions/comments 
about one of these statements. We can discuss this in today's call.
Best regards,
Simonetta

-----Original Message-----
From: owner-gnso-irtp-b-jun09@xxxxxxxxx 
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Michele Neylon :: 
Blacknight
Sent: Monday, May 23, 2011 3:27 PM
To: Diaz, Paul
Cc: <Gnso-irtp-b-jun09@xxxxxxxxx>; Marika Konings
Subject: Re: [gnso-irtp-b-jun09] Feedback from ICANN Compliance


I'd agree with Paul

I'd also want compliance to give us assurances that any "extenuating 
circumstances" excuse could not be abused ie. while one *could* accept that 
there was something beyond anyone's control that made it impossible for a 
registrar to respond (I'm thinking earthquakes or other BIG issues) once that 
compliance wouldn't allow for "repeat offenders"

Regards

Michele


On 23 May 2011, at 14:03, Diaz, Paul wrote:

> I’m hard pressed to come up with any “extenuating circumstance” that would 
> prevent a gaining registrar from RESPONDING within four hours (again, 
> resolution is not required in this time frame).  If members of the WG feel 
> such a caveat is necessary, however, I would insist that the exception be 
> very tightly defined – otherwise the entire purpose of the Emergency Transfer 
> Contact (I agree with the Registrar Liaison’s input, and like Marika’s 
> formulation) would be undermined.
>  
> Regards, P
>  
> From: owner-gnso-irtp-b-jun09@xxxxxxxxx 
> [mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Marika Konings
> Sent: Monday, May 23, 2011 8:06 AM
> To: Gnso-irtp-b-jun09@xxxxxxxxx
> Subject: [gnso-irtp-b-jun09] Feedback from ICANN Compliance
>  
> Dear All,
>  
> In response to clarifications requested from ICANN Compliance in relation to 
> enforcement / non-compliance with consensus policies, I can share the 
> following:
>       • All ICANN Consensus Policies are incorporated into the RAA, it makes 
> no difference whether the obligation is reflected in a Consensus Policy 
> (IRTP) or be made part of the RAA. Accordingly,  ICANN Compliance will follow 
> the same processes for escalated compliance actions and pursue whatever 
> sanctions or remedies available under the RAA.
>       • At the same time, in relation to the EAC, there might be certain 
> limitations with regard to how easily compliance can pursue non-compliant 
> registrars. For example, there might be valid reasons why the gaining 
> registrar did not respond within 4 hours which means Compliance would have to 
> try and verify or validate the explanation/reasons provided by the gaining 
> registrar. As a result, compliance may not be able to make a quick and 
> straight forward determination due to the nature of the issue or causes of 
> non-compliance.
>       • A possible enhancement could be to add 'absent extenuating 
> circumstances' prior to 'Responses are required within 4 hours of the initial 
> request extenuating circumstances', although it would be helpful if the WG 
> would provide examples of what it would consider extenuating circumstances.
> You'll find attached the slide presentation that was mentioned during last 
> week's meeting which outlines the different escalation paths available to the 
> Compliance Staff under the RAA.
>  
> With best regards,
>  
> Marika

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://invadeeurope.eu/
http://www.gettingbusinessonline.ie/
http://rss.me/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Twitter: http://twitter.com/mneylon

PS: Check out our latest offers on domains & hosting: http://domainoffers.me/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845