ICANN bloat to continue as new gTLD program begins

ICANN expects to hire so many new staffers over the next few years that it’ll need to rent a second office in Los Angeles to store them all in, according to a newly published new gTLD program planning document.

We’re looking at about 100 more people on the payroll, about 25% above the current level, judging by ICANN figures.

The Org said in the Operational Design Assessment published last night that the next new gTLD round will need it to hire another 25 to 30 dedicated staff during implementation of the program, along with 10 to 15 contractors, and then an additional 50 to 60 permanent staff to help manage the program going forward.

The number could be even higher if the board of directors and community encourage ICANN to speed up the roll-out of the round by reducing automation and relying more on the manual processing of applications.

The ODA says that ICANN has already identified an option to lease more office space close to its LA headquarters, to house the newcomers.

The budget for ICANN’s current fiscal year expects the Org to average 423 operational staff and another 25 employees dedicated to the new gTLD program.

ICANN reckons that the next round will require 125 full-time equivalents (FTE) during the implementation phase, reduced to 114 after the application phase kicks off.

For comparison, in May 2012, shortly after ICANN closed the application window for the last round, the whole organization comprised just 143 people. A year later, it had grown to 239.

The ODA does not break down how many additional staffers it will need to hire if the community plumps for the low-automation “Option 2”.

ICANN spunks a year, $9 million, on new gTLD plans destined for trashcan

ICANN has published the Operational Design Assessment for the next round of the new gTLD program, a weighty tome of 400 pages, most of which are likely destined to be torn up, burned, or used as toilet paper.

The ODA is the document, prepared by staff for board consideration, that lays out how the Org could implement the community’s policy recommendations for the next application round, how much it would cost, and how long it would take.

As I wrote last week, the paper outlines two options, the more expensive of which would take five years and cost $125 million before a single application fee is collected.

This option “reflects the goal of delivering on all outputs of the SubPro Final Report [the community’s 300-odd policy recommendations] to the maximum extent possible”.

This would see the clock ticking the moment ICANN gets the board’s nod and begins the implementation work — best case scenario, probably the first half of next year — and the first applications accepted at least five years later.

So, no new gTLD applications would be received until the first half of 2028 at the earliest. The first registry go-live would not happen until the 2030s, three decades after the first application window closed.

The second option, which was discussed on a webinar last week, would take about 18 months to roll out and cost half as much in up-front costs, but would not necessarily give the community every last thing it has asked for.

In this scenario, the next application window could open as early as 2025, followed by windows in 2026, 2027 and 2028. There’d be no per-window limit on applications, but ICANN would only start to process 450 each year, with the lucky applications selected by lottery.

What’s surprising about the ODA is how little airtime is given to the second option — known as the “cyclical” or “batching” option — which doesn’t really get a serious look-in until page 354.

The large majority of the document is devoted to the single-round, long-runway, more-expensive option, which Org surely knows will prove repellent to most community members and would, if approved, surely confirm that ICANN is mortally unfit for purpose.

Yet ICANN has nevertheless spunked over a year and $9 million of domain buyers’ money assessing an operational design it surely knows has no chance of ever going operational. It’s pure, maddening, bureaucratic wheel-spinning.

ICANN will hold two webinars tomorrow to discuss the document, so if you’re interested in the debate, best settle in for a night of tedious and rather frustrating reading.

The ODA itself is here (pdf).

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.