The promise not to sue ICANN that all new gTLD applicants made when they applied is legally enforceable, a California judge has ruled.
Judge Percy Anderson on Monday threw out Donuts’ lawsuit against ICANN over the controversial $135 million .web auction, saying the “covenant not to sue bars Plaintiff’s entire action”.
He wrote that he “does not find persuasive” an earlier and contrary ruling in the case of DotConnectAfrica v ICANN, a case that is still ongoing.
Donuts sued ICANN at first to prevent the .web auction going ahead.
Donuts argued that ICANN failed to adequately vet NDC to uncover its secret sugar daddy. It wanted $22.5 million from ICANN — roughly what it would have received if the auction had been privately managed, rather than run by ICANN.
But the judge ruled that Donuts’ covenant not to sue is enforceable. Because of that, he made no judgement on the merits of Donuts’ arguments.
Under the relevant law, Donuts had to show that the applicant contract was “unconscionable” both “procedurally” and “substantively”.
Basically, the question for the judge was: was the contract unfairly one-sided?
The judge ruled (pdf) that it was not substantively unconscionable and “only minimally procedurally unconscionable”. In other words: a bit crap, but not illegal.
He put a lot of weight on the fact that the new gTLD program was designed largely by the ICANN community and on Donuts’ business “sophistication”. He wrote:
Without the covenant not to sue, any frustrated applicant could, through the filing of a lawsuit, derail the entire system developed by ICANN to process applications for gTLDs. ICANN and frustrated applicants do not bear this potential harm equally. This alone establishes the reasonableness of the covenant not to sue.
Donuts VP Jon Nevett said in a statement yesterday that the fight over .web is not over:
Donuts disagrees with the Court’s decision that ICANN’s required covenant not to sue, while being unconscionable, was not sufficiently unconscionable to be struck down as a matter of law. It is unfortunate that the auction process for .WEB was mired in a lack of transparency and anti-competitive behavior. ICANN, in its haste to proceed to auction, performed only a slapdash investigation and deprived the applicants of the right to fairly compete for .WEB in accordance with the very procedures ICANN demanded of applicants. Donuts will continue to utilize the tools at its disposal to address this procedural failure.
It looks rather like we could be looking at an Independent Review Process filing, possibly the first to be filed under ICANN’s new post-transition rules.
Donuts and ICANN are already in the Cooperative Engagement Process — the mediation phase that usually precedes an IRP — with regards .web.
Second-placed bidder Afilias is also putting pressure on ICANN to overturn the results of the auction, resulting in a bit of a public bunfight with Verisign.
TL;DR — don’t expect to be able to buy .web domains for quite a while to come.
ICANN’s new domain Transfer Policy, which comes into effect tomorrow, creates risks for users of privacy/proxy services, registrars and others haved warned.
The policy could lead to private registrants having their contact information published in the public Whois for 60 days, the GNSO Council expects to formally tell ICANN this week.
“This could threaten privacy for at-risk registrants without clear benefit,” the Council says in a draft letter to the ICANN board.
The revised Transfer Policy was designed to help prevent domain hijacking.
The main change is that whenever there’s a “change of registrant”, the gaining and losing registrants both have to respond to confirmation emails before the change is processed.
However, “change of registrant” is defined in such a way that the confirmation emails would be triggered even if the registrant has not changed.
For example, if you change your last name in your Whois records due to marriage or divorce, or if you change email addresses, that counts as a change of registrant.
It now turns out that ICANN considers turning a privacy service on or off as a change of registrant, even though that only affects the public Whois data and not the underlying customer data held by the registrar.
The GNSO Council’s draft letter states:
ICANN has advised that any change to the public whois records is considered a change of registrant that is subject to the process defined through IRTP-C. Thus, turning a P/P service on or off is, from ICANN’s view, a change of registrant. It requires the CoR [change of registrant] process to be followed and more importantly could result in a registrant exposing his/her information in the public whois for 60 days. This could threaten privacy for at-risk registrants without clear benefit.
My understanding is that the exposure risk outlined here would only be to registrants who attempt to turn on privacy at their registrar then for whatever reason ignore, do not see or do not understand the subsequent confirmation emails.
Depending on implementation, it could lead to customers paying for a privacy service and not actually receiving privacy.
On the other side of the coin, it’s possible that an actual change in registrant might not trigger the CoR process if both gaining and losing registrants both use the same privacy service and therefore have identical Whois records.
The Council letter also warns about a possible increase in spam due to the changes:
many P/P services regularly generate new email addresses for domains in an effort to reduce spam. This procedure would no longer be possible, and registrants may be subject to unwanted messaging. Implementing the CoR for email changes that some providers do as often as every 3-5 days is not feasible.
ICANN has been aware of these issues for months. Its suggested solution is for registrars to make themselves the “Designated Agent” — a middleman permitted to authorize transfers — for all of their customers.
As we reported earlier this week, many large registrars are already doing this.
But registrars and the GNSO Council want ICANN to consider reinterpreting the new policy to exclude privacy/proxy services until a more formal GNSO policy can be created.
While the Policy Development Process that created the revised transfer rules wound up earlier this year, a separate PDP devoted to creating rules of privacy/proxy services is still active.
The Council suggests that this working group, known as PPSAI, could assume the responsibility of clearing up the mess.
In the meantime, registrars are rather keen that they will not get hit with breach notices by ICANN Compliance for failing to properly implement to what seems to be a complex policy.
A new anti-hijacking domain name transfer policy comes into effect this week at all ICANN-accredited registrars, potentially complicating the process of not only selling domains but also updating your own Whois records.
But many registrars have already rewritten their terms of service to make the new rules as hassle-free as possible (and essentially pointless).
From December 1, the old ICANN Inter-Registrar Transfer Policy starts governing inter-registrant transfers too, becoming simply the Transfer Policy.
Now, when you make updates to your Whois records that appear to suggest new ownership, you’ll have to respond to one or two confirmation emails, text messages or phone calls.
The policy change is the latest output of the interminable IRTP work within ICANN’s GNSO, and is designed to help prevent domain hijacking.
But because the changes are likely to be poorly understood by registrants at the outset, it’s possible some friction could be added to domain transfers.
Under the new Transfer Policy, you will have to respond to confirmation emails if you make any of the following:
- A change to the Registered Name Holder’s name or organization that does not appear to be merely a typographical correction;
- Any change to the Registered Name Holder’s name or organization that is accompanied by a change of address or phone number;
- Any change to the Registered Name Holder’s email address.
While registrars have some leeway to define “typographical correction” in their implementation, the notes to the policy seem to envisage single-character transposition and omission errors.
Registrants changing their last names due to marriage or divorce would apparently trigger the confirmation emails, as would transfers between parent and subsidiary companies.
The policy requires both the gaining and losing registrant to verify the “transfer”, so if the registrant hasn’t actually changed they’ll have to respond to two emails to confirm the desired changes.
Making any of the three changes listed above will also cause the unpopular 60-day transfer lock mechanism — which stops people changing registrars — to trigger, unless the registrant has previously opted out.
Registrars are obliged to advise customers that if the change of registrant is a prelude to an inter-registrar transfer, they’d be better off transferring to the new registrar first.
The new policy is not universally popular even among registrars, where complexity can lead to mistakes and therefore support costs.
Fortunately for them, the Transfer Policy introduces the concept of “Designated Agents” — basically middlemen that can approve registrant changes on your behalf.
Some registrars are taking advantage of this exception to basically make the confirmation aspects of the new policy moot.
Calling the confirmation emails an “unnecessary burden”, EuroDNS said last week that it has unilaterally made itself every customer’s Designated Agent by modifying its terms of service.
Many other registrars, including Tucows/OpenSRS, NameCheap and Name.com appear to be doing exactly the same thing.
In other words, many registrants will not see any changes as a result of the new Transfer Policy.
The truism that there’s no domain name policy that cannot be circumvented with a middleman appears to be holding.
Almost a quarter of ICANN’s board of directors were replaced at the organization’s annual general meeting in Hyderabad last week.
Five of the 21-strong board are fresh faces, though many will be familiar to regular ICANN and industry watchers.
They hail from five different countries in four of ICANN’s five regions. One is female.
They replace Bruce Tonkin, Erika Mann, Suzanne Woolf, Kuo-Wei Wu and Bruno Lanvin, each of whom have served terms between three and nine years.
The newcomers all get initial, renewable, three-year terms.
Here’s some abbreviated bios of the newly appointed directors.
Appointed by the Nominating Committee, Botterman is an internet governance consultant with strong historic ties to the registry industry.
From the Netherlands, he was chairman of .org manager Public Interest Registry for eight years until July 2016 and served as its interim CEO for several months in 2010.
Prior to that, he held advisory roles in the Dutch and European Union governments.
American Burr replaces term-limited Bruce Tonkin as the GNSO contracted parties representative to the board. Since 2012 she’s been chief privacy officer of Neustar. Before that, she was a lawyer in private practice.
There are very few people more intimately familiar with ICANN. In the late 1990s, while working at the US National Telecommunications and Information Administration, she was a key player in ICANN’s creation.
Koubaa, a Tunisian, is founder of the Arab World Internet Institute, a non-profit dedicated to improving internet knowledge in the Arab region, and until recently head of Middle-East and North Africa public policy at Google.
He was selected by the NomCom. He is also a former member of NomCom, having sat on it during its 2008/9 session. He’s also been a volunteer adviser to PIR in the past.
Hailing from Japan, Maemura works for IP address registry JPNIC. He was selected for the ICANN board by the Address Supporting Organization.
Until recently, he was chair of the executive council of APNIC, which is responsible for distributing IP addresses in the Asia-Pacific region.
Iranian-born, Netherlands-based Ranjbar is chief information officer of RIPE NCC, the European IP address authority.
He was appointed to the ICANN board by the Root Server System Advisory Committee.
The new gTLD .food went live in the DNS on Friday, but nobody except the registry will be able to register domains there.
In what I would argue is one of the new gTLD program’s biggest failures, .food will be a dot-brand, closed to all except the “brand” owner.
The registry is Lifestyle Domain Holdings, a subsidiary of US media company Scripps Networks.
Scripps runs the Food Network TV station in the States and the site Food.com. It has a trademark on the word “Food”.
Its registry agreement for .food, signed back in April, includes Specification 13, which allows registries to restrict all the second-level domains to themselves and their affiliates.
So food producers, restaurants, chefs and the like will never be able to use .food for their web sites.
ICANN signed the contract with Scripps despite objections from several entities including the Australian government, which warned “restricting common generic strings, such as .food, for the exclusive use of a single entity could have a negative impact on competition”.
Under ICANN rules hastily cobbled together after outrage over so-called “closed generics”, a registry cannot run as a dot-brand a gTLD that is:
a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others.
Almost all applications flagged as closed generics were subsequently amended to make them restricted but not brand-exclusive. Scripps was the major hold-out.
The loophole that allowed .food to stay in exclusive hands appears to be that Scripps’ trademark on “Food” covers television, rather than food.
If .food winds up publishing content about food, such as recipes and healthy eating advice, I’d argue that it would go against the spirit of the rules on closed generics.
It would be a bit like Apple getting .apple as a Spec 13 dot-brand and then using the gTLD to publish content about the fruit rather than computers.
No sites are currently live in .food.