[council] Fake renewal notices

[Mason Cole <mcole@xxxxxxxxxx>]

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