New gTLD applications to cost about $250,000

Getting hold of a new gTLD could cost applicants well north of a quarter million dollars in base application fees alone in the next round, according to ICANN.

Presenting the results of its year-long Operational Design Phase to the GNSO Council via Zoom last night, staffers said application fees are likely to be either around $240,600 or $270,000 next time, higher than the $185,000 it charged in 2012.

Those would be the base fees, not including any additional evaluations or contention-related fees.

The Org next week is set to present its board and the community with a stark choice — one big expensive round along the lines of 2012, with a potential five-year wait for the next application window to open, or a cheaper, staggered four-stage round with maybe only 18 months of development time.

The Operational Design Assessment — a 400-page tome the Org has spent the last 14 months developing — is set to be published early next week, outlining two options for how ICANN should proceed on the next round.

One option is to build a highly automated system that fully implements all of the GNSO’s policy recommendations but costs up to $125 million up-front to build and roll out over five years. Application fees would be about $270,000.

The other would cut some bells and whistles and require more human intervention, but would be cheaper at up to $67 million up-front and could be rolled out within 18 months. Application fees would be about $240,600.

ICANN CFO Xavier Calvez, responding to exclamations of surprise via Zoom chat, said that a decade of inflation alone would lead to a 28% price increase to $237,000 if the next round were opened today, but in two or three years the price could be even higher if current economic trends continue.

While many expected the fact that technical evaluations will be conducted on a registry service provider basis rather than a per-application basis would wipe tens of thousands from the application fee, ICANN pointed out that building and executing this RSP pre-evaluation process will also cost it money.

ICANN wants to operate the program on a “cost-recovery basis”, so it neither makes a profit nor has to dig into its operational budget. It expects “more than three dozen vendors will be required” to help run the round.

It seems that the portion of the fee set aside to deal with “risks” — basically, anticipated litigation — is expected to be around a fifth of the total, compared to about a third in the 2012 round.

ICANN is asking its board and the community to decide between what it calls “Option 1 — One Big Round” and “Option 2 — Four Annual Cycles”.

Option 1 would essentially be a replay of 2012, where there’s a single unlimited application window, maybe a couple thousand applications, and then ICANN processes them all in a highly automated fashion using custom-built software.

Option 2 would allow unlimited applications once a year for four years, but it would cap the number processed per year at 450 and there’d be a greater degree of manual processing, which ICANN, apparently unfamiliar with its own history of software development, thinks poses additional risk.

My hot take is that the Org is presenting a false choice here, much like it did in January with its ODA on Whois reform, where one option was so unpalatably time-consuming and expensive that it had most of the community retching into their soy-based lattes.

There’s also an implicit criticism in both ODAs that the community-driven policy-making process has a tendency to make big asks without adequately considering the resources required to actually get them done.

I might be wrong, but I can’t at this early stage see much support emerging for the “One Big Round” option, except perhaps from the most ardent opponents of the new gTLD program.

ICANN expects to deliver the ODA — 100 pages with 300 pages of appendices — to its board on Monday, with wider publication not long after that. It will hold two webinars for the community to discuss the document on Wednesday.

Blind auditions underway for ICANN’s supreme court

An ICANN volunteer committee says it is close to picking a slate of judges for what amounts to ICANN’s much-delayed “supreme court”, but it’s doing so without knowing the identities of the candidates.

The Independent Review Process Community Representatives Group said in a blog post that it expects to wrap up its work — picking at least seven members of an IRP Standing Panel — by the end of the year, though it views the deadline as “challenging”.

The group said that it’s currently reviewing applications for the posts, but with the identities of the candidates redacted, and expects to start interviewing shortly. The members wrote:

While we only see information about various applicants’ qualifications, gender and ICANN regional residency, we do not at this point know the identity of the candidates. These are data points to assist our winnowing process and our endeavor to achieve cultural, linguistic, gender and legal diversity. Diversity by geographic region is indicated in ICANN’s Bylaws.

The skill-set mandated for panelists by ICANN’s bylaws is pretty rarefied — requiring knowledge of international law, arbitration, the DNS and ICANN itself — so it seems likely that LinkedIn and Google could be useful to identity candidates, if CRG members were so inclined.

The CRG said it has a wealth of qualified candidates “a sizeable group of individuals with impressive and suitable backgrounds”, making the selection process “difficult”.

The Standing Panel is envisaged as a kind of supreme court for ICANN. Whenever somebody challenges an ICANN decision with an Independent Review Process complaint, three members of the panel would be selected to hear the case.

The idea is that IRP should become more consistent, objective and speedy, retaining more institutional knowledge, with a stable set of rotating panelists. The current system has ICANN and complainants select their panelist.

ICANN’s bylaws have been calling for the creation of a Standing Panel since April 2013, but ICANN is ICANN and the panel has been delayed by years of foot-dragging and red tape. The CRG was only created to audition candidates in February 2022.

Many IRP cases over the last near-decade have been complicated and delayed by the absence of the panel, even resulting in a lawsuit.

This is great for lawyers who bill by the hour, not so great for complainants and ICANN’s credibility as an accountable organization.

The CRG has seven members drawn from the GNSO, ALAC, ccNSO and GAC, including government representatives of Iran and Nigeria. It’s chaired by Verisign’s David McAuley.

You can’t appeal a UDRP appeal, ICANN Ombudsman says

ICANN’s independent Ombudsman has called an Indian vaccine maker’s second Request for Reconsideration over a failed UDRP case a “misuse” of the Org’s appeals process.

Zydus Lifesciences lost its UDRP over the domain zydus.com earlier this year, with a finding of Reverse Domain Name Hijacking, then used the RfR process to try to get ICANN’s board of directors to overturn the WIPO decision.

The Board Accountability Mechanisms Committee dismissed the complaint because Reconsideration is designed for challenging ICANN’s actions and WIPO is not ICANN.

Zydus immediately filed a second RfR, calling WIPO “an extension of ICANN itself” and that BAMC’s inaction on the first RfR meant the case was now subject to the board’s jurisdiction.

In a rare intervention, Ombudsman Herb Waye poo-poos that notion, writing: “Decisions by the WIPO Panel in a domain name dispute are not sufficient basis for an RfR (hence the BAMC had no ‘jurisdiction’ other than the jurisdiction necessary to dismiss the Request).”

I feel that [the second RfR] has placed the BAMC in the awkward position of policing itself; hence perhaps, its hesitancy to summarily dismiss a Request concerning its own actions. A clear attempt by the requestor to appeal the decision in [the first RfR]. An unfortunate situation that, to me, amounts to misuse of this accountability mechanism.

He concluded that for the BAMC to consider the complaint would be a “waste of resources” and that it should be dismissed.

Zydus will still be able to appeal the UDRP in court, but that of course will be much more expensive.

Is ICANN toothless in the face of DNS abuse?

Concerns have been raised that ICANN may lack the tools to tackle DNS abuse using its contracts with registries and registrars.

The new report from the GNSO’s “small team” on abuse has highlighted two “gaps” in the current Compliance regime that may be allowing registrars to get away with turning a blind eye to abusive customers.

The current version of the standard Registrar Accreditation Agreement calls for registrars to maintain an abuse contact email and to “take reasonable and prompt steps to investigate and respond appropriately to any reports of abuse.”

The problem, the small team report finds, is that ICANN Compliance doesn’t seem to have a standard definition of “reasonable”, “prompt”, and “appropriately”. The contract doesn’t require any specific remediations from the registrar.

“Members of the small team are concerned that this interpretation may allow DNS abuse to remain unmitigated, depending upon the registrar’s specific domain name use and abuse policies,” the report states.

Judging by conversations at ICANN 75 last month, it’s apparently the first time Compliance has gone on the record about how it enforces this part of the contract.

It’s quite rare for ICANN to issue a public breach notice to a registrar over its failure to respond to abuse reports and when it does, it tends to relate to the registrar’s failure to keep records showing how it responded.

I can’t find any instances where Compliance has canned a registrar for allowing abusive domains — typically defined as those hosting malware, phishing, botnets, pharming and some spam — to remain active after an abuse report.

The small team’s report also thinks there’s a blind spot in ICANN’s standard Registry Agreement, which in turn requires registries to include, in their Registry-Registrar Agreements, provisions requiring anti-abuse terms in the registrars’ Registration Agreements.

This complex chain of contractual provisions doesn’t seem to be enforced, the small team notes, saying “further consideration may need to be given to what Registries are doing to ensure the text is indeed included in the Registration Agreement (ie Registries enforcing their own Registry-Registrar Agreements”.

The small team recommends that contracted parties talk further with ICANN about possible contract changes or best practices documents before going ahead with policy-making. The GNSO Council will address the recommendations later this month.

ICANN to mull bulk registration ban

ICANN policymakers are to take a look at banning bulk domain registrations in ongoing efforts to combat DNS abuse.

While in the very early stages of discussion, the GNSO Council is being urged to start gathering data “to further explore the role that bulk registrations play in DNS Abuse” and “to consider whether further action on bulk registrations is deemed necessary”

The recommendation is among several in a newly published report of a cross-constituency GNSO “small team”, which may lead to “tightly focused and scoped policy development”.

While acknowledging “there are also examples in which bulk registrations are used for legitimate purposes”, the report states:

The small team recommends that the GNSO Council requests the Registrar Stakeholder Group and others (for example, ICANN org, the RySG and the DNSAI) to further explore the role that bulk registrations play in DNS Abuse as well as measures that Registrars may have already put in place to address this vector. Based on the feedback received, the GNSO Council will consider whether further action on bulk registrations is deemed necessary.

The report is to be considered later this month at the GNSO Council’s monthly meeting. Any actual policy outcome, if any, will be years away.

ICANN dodges bullet as American elected to ITU top job

The International Telecommunications Union has elected Doreen Bogdan-Martin as Secretary-General, comfortably defeating a Russian candidate who could have caused serious problems for ICANN’s legitimacy.

She won 139 votes out of 172 cast at the agency’s plenipotentiary in Bucharest, the ITU said.​​ She only needed 83. Rashid Ismailov of the Russian Federation, the only other candidate, received 25 votes.

A couple of weeks ago, ICANN CEO Göran Marby took a rare political stance against the Russian’s platform, warning that it could lead to a fragmented internet and the death of ICANN.

Ismailov would have pushed for multilateral internet governance, with the ITU absorbing the functions of ICANN and other multistakeholder organizations.

Bogdan-Martin is American and much more amenable to the status quo.

Paraguay to chair the GAC

Paraguayan government official Nicolas Caballero has been elected as the next chair of ICANN’s Governmental Advisory Committee.

He ran unopposed, in an election that had to extend its nomination period because nobody put themselves forward in time for the original August deadline.

He will replace Egypt’s Manal Ismail, who will leave the chair following ICANN’s meeting in Cancun next March.

The role comes with a non-voting liaison position on ICANN’s board of directors.

Caballero, a technical advisor in Paraguay’s Office of the President, has been on the GAC for about 10 years.

He’s the first GAC chair from South America.

ICANN approves ccTLD-killer policy

ICANN has formally adopted a policy that would enable it to remove ccTLDs from the DNS root when their associated countries cease to exist, raising the possibility of the Soviet Union’s .su being deleted.

Last Thursday at ICANN 75 in Kuala Lumpur, the board of directors rubber-stamped the ccNSO Retirement of ccTLDs Policy, which sets out how ccTLDs can be deleted in an orderly fashion over the course of several years.

The policy calls for ICANN and the ccTLD registry to form a “Retirement Plan” when the ccTLD’s string is removed from the ISO 3166-1 Alpha-2 standard, which defines which two-letter strings are reserved for which countries.

Strings are typically removed from this list when a country changes its name (such as Timor-Leste) or breaks up into smaller countries (such as the Netherlands Antilles).

The Retirement Plan would see the ccTLD removed from the root five years after ISO made the change, though this could be extended if the registry asks and ICANN agrees.

In February, I set out the case for why the policy may allow ICANN to retire .su, the thriving ccTLD for the Soviet Union, three decades after that nation was dismantled.

ICANN returning to Puerto Rico

ICANN has put Puerto Rico back on its list of future meeting venues after cancelling this year’s trip to San Juan due to the pandemic.

The Org will summon the true believers to the Puerto Rico Convention Center from March 2 to March 7, 2024, for ICANN 79, it announced this week.

That’s two years after the cancelled meeting from this March, which ultimately went ahead online only.

It will be six years after ICANN last visited the island, in the wake of Hurricane Maria.

It will be ICANN’s third visit to the country, a US territory. It first held a meeting there in 2007.

ICANN was forced to cancel a Puerto Rico visit in 2016 due to an outbreak of the Zika virus (remember that?).

Of the in-person meetings canceled due to the Covid-19 pandemic, now all have been rescheduled or have already taken place.

It’s ICANN versus the blockchain in Kuala Lumpur

Internet fragmentation and the rise of blockchain-based naming systems were firmly on the agenda at ICANN 75 in Kuala Lumpur today, with two sessions exploring the topic and ICANN’s CTO at one point delivering a brutal gotcha to a lead blockchain developer.

Luc van Kampen, head of developer relations at Ethereum Name Service, joined a panel entitled Emerging Identifier Technologies, to talk up the benefits of ENS.

He did a pretty good job, I thought, delivering one of the clearest and most concise explanations of ENS I’ve heard to date.

He used as an example ICANN’s various handles across various social media platforms — which are generally different depending on the platform, because ICANN was late to the party registering its name — to demonstrate the value of having a single ENS name, associated with a cryptographic key, that can be used to securely identify a user across the internet.

Passive aggressive? Maybe. But it got his point across.

“We at ENS envisage a world where everyone can use their domain as a universal identifier,” he said. Currently, 600,000 users have registered 2.4 million .eth domains, and over 1,000 web sites support it, he said.

He described how ENS allows decentralized web sites, is managed by a decentralized autonomous organization (DAO) and funded by the $5 annual fee for each .eth name that is sold.

Van Kampen had ready responses to questions about how it would be feasible for ENS to apply to ICANN to run .eth in the consensus root in the next new gTLD application round, suggesting that it’s something ENS is thinking about in detail.

While not confirming that ENS will apply, he described how a gateway or bridge between the Ethereum blockchain and the ICANN root would be required to allow ENS to meet contractual requirements such as zone file escrow.

What did not come up is the fact the the string “eth” is likely to be reserved as the three-character code for Ethiopia. If the next round has the same terms as the 2012 round, .eth will not even enter full evaluation.

But the real gotcha came when ICANN CTO John Crain, after acknowledging the technology is “really cool”, came to ask a question.

“What kind of safeguards and norms are you putting in place regarding misbehavior and harm with these names?” Crain asked.

Van Kampen replied: “Under the current implementation of the Ethereum Name Service and the extensions that implement us and the integrations we have, domains are unable to be revoked under any circumstances.”

“So if I understand correctly, under the current solution, if I’m a criminal and I register a name in your space, I’m pretty secure today,” Crain asked. “I’m not going to lose my name?”

Van Kampen replied: “Under the current system, everything under the Ethereum Name Service and everything registered via us with the .eth TLD are completely censorship resistant.”

Herein lies one of the biggest barriers to mainstream adoption of blockchain-based alt-roots. Who’s going to want to be associated with a system that permits malware, phishing, dangerous fake pharma and child sexual abuse material? Who wants to be known as the maker of the “kiddy porn browser”?

If I were Crain I’d be feeling pretty smug after that exchange.

That’s not to say that ICANN put in a wholly reassuring performance today.

Technologist Alain Durand preceded van Kampen with a presentation pointing out the substantial problems with name collisions that could be caused by blockchain-based alt-roots, not only between the alt-root and the ICANN root, but also between different alt-roots.

It’s a position he outlined in a paper earlier this year, but this time it was supplemented with slides outlining a hypothetical conversation between two internet users slowly coming to the realization that different namespaces are not compatible, and that the ex-boyfriend of “Sally” has registered a name that collides with current boyfriend “John”.

It’s meant to be cute, but some of the terminology used made me cringe, particularly when one of the slides was tweeted out of context by ICANN’s official Twitter account.

To learn more about alternative naming systems, read #ICANN's OCTO publication >> https://t.co/LFYjy1KX3w | Emerging Identifier Technologies #ICANN75 pic.twitter.com/mWN7fCc7eR

— ICANN (@ICANN) September 21, 2022

Maybe I’m reading too much into this, but it strikes me as poor optics for ICANN, an organization lest we forget specifically created to introduce competition to the domain name market, to say stuff like “Market, you are a monster!”.

I’m also wondering whether “icannTLD” is terminology that plays into the alt-root narrative that ICANN is the Evil Overlord of internet naming. It does not, after all, actually run any TLDs (except .int).

The language used to discuss alt-roots came under focus earlier in the day in a session titled Internet Fragmentation, the DNS, and ICANN, which touched on blockchain alt-roots while not being wholly focused on it.

Ram Mohan, chief strategy officer of Identity Digital and member of ICANN’s Security and Stability Advisory Committee, while warning against ICANN taking a reflexively us-versus-them stance on new naming systems, wondered whether phrases such as “domain name” and “TLD” are “terms of art” that should be only used to refer to names that use the consensus ICANN-overseen DNS.

We ought to have a conversation about “What is a TLD”? Is a TLD something that is in the IANA root? Is a domain name an identifier that is a part of that root system? i think we ought to have that conversation because the place where I worry about is you have other technologies in other areas that come and appropriate the syntax, the nomenclature, the context that all of us have worked very hard to build credibility in… What happens if that terminology gets taken over, diluted, and there are failures in that system? … The end user doesn’t really care whether [a domain] is part of the DNS or not part of the DNS, they just say “My domain name stopped working”, when it may not actually be a quote-unquote “domain name”.

Food for thought.