ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [council] Fake renewal notices


Thanks Mason.

Councillors, we will be discussing this on Thursday.

Stéphane Van Gelder
Directeur Général / General manager
INDOM NetNames France
----------------
Registry Relations and Strategy Director
NetNames
T: +33 (0)1 48 01 83 51
F: +22 (0)1 48 01 83 61


Le 11 sept. 2012 à 18:52, Mason Cole a écrit :

> Councilors --
>  
> You recall we discussed the issue of fake renewal notices in our July meeting 
> and deliberated possible ways to address the problem.  I volunteered to 
> discuss this with the RrSG and return to the council with the registrars' 
> thoughts before deciding how to proceed.
>  
> Forgive the length of this email, but I want to be sure all the issues are on 
> the table.  As is often the case, regrettably, a seemingly simple issue is 
> not so simple as you peel back the layers.  Also, registrars must take care 
> in discussions about competitive activity and particular competitors so as 
> not to violate antitrust protections.
>  
> The problem
> Certain providers send what appear to be renewal notices but are in fact 
> disguised requests to transfer a name from one registrar to another.  
> Unsuspecting customers of ours who don't carefully read the communication 
> wind up moving their names from the original registrar to the one sending the 
> communication.  Customers must then deal with a new entity they likely didn't 
> consciously choose.
>  
> Working group options
> As Mikey O'Connor and his WG informed us in Costa Rica, the WG looked at a 
> number of options for addressing the issue.  This included launching a full 
> PDP, attaching the issue to an existing PDP, crafting an amendment to the 
> RAA, and reporting the offending entities to authorities in relevant 
> jurisdictions.
>  
> History
> There's a link in the DT's report to the council describing activity various 
> authorities have undertaken to address the practice, particularly in the US 
> and Canada.  I recommend review of this section to understand what's happened 
> to this point.  This includes action from governments and the courts.
>  
> Why does the problem yet persist?  As one of our members put it, every time 
> there's a legal ruling, some of the craftiest attorneys around carefully 
> write language in the renewal notices that work around new legal 
> requirements.  It may also be the case that regulatory authorities are not 
> aware of the ongoing violations, or that they don’t have effective 
> jurisdiction over the perpetrators.
>  
> PDP issue
> The registrars recognize the attractiveness of addressing the situation via 
> PDP (it's perceived as an "easy" issue that could be acted on quickly to 
> demonstrate council responsiveness and agility).  However, we should proceed 
> with care for the following reasons:
>  
> 1. Drafting policy language that limits certain activity could inadvertently 
> restrain marketing efforts (unattractive and deceptive as they may be in this 
> instance -- and be clear, the RrSG is not defending it).  As has been 
> repeatedly pointed out, the registrar marketplace is very competitive and 
> almost all of us work in good faith to attract business in various ways.  
> ICANN cannot make judgment calls on what is good and bad "copy," so 
> prohibiting or proscribing certain language very easily spills into 
> regulation of speech.  The council is not a regulator of speech, and this is 
> a very slippery slope.
>  
> 2. It doesn't in fact appear to be an "easy" issue that could be quickly 
> resolved, unfortunately.  The RrSG is mindful of the politics of the 
> situation; however, while politics may be important, more important is making 
> sure efforts are effective.  If they are not effective, the politics will be 
> worse later, and we'll still have the problem behavior.  Effective, in this 
> context, means something compliance could enforce with its limited budget and 
> manpower.
>  
> Issues with the RAA
> There have beens suggestions to just write a line or two into the RAA to 
> prohibit this activity.  The RrSG's observation is that if legal language 
> meant to prohibit activity were so easy, the problem would have been cleared 
> up long ago, by contracts, courts and/or consumer protection agencies.  
>  
> Addressing the behavior through the RAA may eventually be useful.  Again, 
> however, language must be effective -- if authorities in Canada and the US, 
> with court rulings behind them, are still unable to find enforceable language 
> to use, that's a signal that ICANN would need to take extreme care in 
> attempting the same so the offender's lawyers don't continue to "write 
> around" the issue.
>  
> Next steps
> The RrSG is interested in finding the most effective way to handle this 
> issue, which harms consumers and law abiding registrars.  While it deplores 
> this type of behavior, the RrSG believes that we should be cautious about 
> putting ICANN in the role of law enforcement via the registry and registrar 
> agreements, particularly when evidence suggests that enforcement is tricky.  
> In particular, creating a contractual obligation that is difficult for ICANN 
> to enforce will only subject ICANN to more criticism about its compliance 
> program without actually changing the behavior. From here, we recommend the 
> following steps:
>  
> 1. Discuss the issue with ICANN Compliance to make SG and GNSO concerns 
> known, as previous legal actions may impact renewal of offenders' 
> accreditation agreements.  
> 2. Communicate to jurisdictional authorities as a SG to make our concerns 
> known and to assess renewed enforcement – especially authorities like the FTC 
> and the Canadian consumer agency that have already brought cases and may have 
> stronger enforcement tools (e.g., civil penalties for violations of 
> settlement agreements, etc.) that can be used.  In particular, it may make 
> sense to schedule a discussion with interested consumer protection 
> authorities in Toronto.
> 3. Report findings to the GNSO Council.
> 4. Investigate whether or not enforceable contract language can be crafted, 
> and the extent to which it could be equally or more effective than 
> enforcement actions to date.  For example, rather than requiring ICANN to 
> make a determination about the behavior, a contractual provision that says 
> accreditation can be revoked where a registrar has been found to be in 
> violation of a court order or regulatory cease and desist order.
> 
> The registrars would welcome the renewal notice WG's ongoing participation in 
> these efforts, of course.
>  
> I look forward to the discussion of this matter on our call Thursday.
>  
> Mason



<<< Chronological Index >>>    <<< Thread Index >>>