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

["Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>]

Mike

It would be helpful if you were to explain the rationale behind this or are you 
planning on joining the call today?

Regards

Michele


On 24 May 2011, at 13:49, Mike Rodenbaugh wrote:

> 
> I agree with Sedo's minority statement, with thanks to Simonetta for drafting 
> it so clearly.
> 
> Mike Rodenbaugh
> RODENBAUGH LAW
> tel/fax:  +1 (415) 738-8087
> http://rodenbaugh.com 
> 
> 
> -----Original Message-----
> From: owner-gnso-irtp-b-jun09@xxxxxxxxx 
> [mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Sedo :: Simonetta 
> Batteiger
> Sent: Tuesday, May 24, 2011 4:54 AM
> To: Gnso-irtp-b-jun09@xxxxxxxxx
> Subject: [gnso-irtp-b-jun09] 60 day lock minority viewpoint
> 
> 
> 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 tra!
> nsfer. 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
> 
> 
> 
> 
> 
> 
> 
> 

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://b.log.ie/
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