GNSO mulls lawyering up over auction fund dispute

The GNSO Council has started discussing bringing in the lawyers over ICANN’s recent handling of issues related to its $200+ million auction fund and Grant Program.

The Council today raised the possibility of deploying the never-before-used Community Independent Review Process, which would involve every major community group ganging up on ICANN’s board in a protracted quasi-judicial bunfight.

Ironically, the beef concerns the way ICANN is trying to stop people invoking its accountability mechanisms, including the IRP, to challenge decisions it makes under its Grant Program, which hopes to distribute $10 million to worthy causes this year.

ICANN policy is that nobody should be able to challenge grant decisions, because that would mean funneling the available funds into the pockets of worthless lawyers, rather than worthy causes. But how it proposes to achieve that goal is in dispute.

The original community recommendation was for a bylaws amendment that specified that the Grant Program was out-of-bounds for IRP and Request for Reconsideration claims, and the board initially agreed, before changing its mind and instead plumping for a clause in the program’s terms that prevents grant applicants appealing adverse decisions.

After community pushback, the board said it would also propose a bylaws amendment, but many believe the amendment it came up with goes way too far and risks making it far too easy for ICANN to wriggle out of its accountability obligations in future.

Leading the fight against the board is the GNSO’s Intellectual Property Constituency, which filed a Request for Reconsideration in November, asking ICANN to reverse its decision to “contract around” its accountability promises and scale back its over-broad bylaws amendment.

But the RfR was thrown out, with the Board Accountability Mechanisms Committee ruling that the IPC had failed to say how it had been specifically harmed by the board’s actions, accusing the constituency of merely “speculating” about possible future harms.

GNSO Councillor Susan Payne, today expressed the IPC’s disappointment with BAMC’s decision on the Council’s monthly conference call.

“We think that’s wrong,” she said. “If you purport to change a fundamental bylaw by using a process that cuts out the GNSO and effectively therefore also its constituencies and stakeholder groups then clearly there’s a harm there.”

She also noted the financial expense of challenging the board’s decisions.

“Constituencies or stakeholder groups will have real difficulty in withstanding the ICANN machine,” Payne said. “It’s a really expensive process to to challenge these kind of decisions. We asked if other constituencies and stakeholder groups would be able to join the IPC in bringing that RfR and no one had the finances to do it.”

The IPC has joined ICANN in a Cooperative Engagement Process — a kind of informal discussion that is often a precursor to an IRP filing — but Payne raised the possibility of ICANN’s Empowered Community filing its own IRP.

Under ICANN’s bylaws, the EC has the special ability to bring a Community IRP and ICANN has to pay for it. It’s never been used before, and it doesn’t look to me like the complex conditions required to trigger it are close to having been met.

The IPC had broad support in principle from the other Councillors speaking in today’s meeting, but some urged caution due to ICANN’s past behavior when the lawyers are called in.

“Once you get into the IRP process, ICANN buckles down, hands it off to their outside counsel, and you really get a nasty litigation fight,” said Jeff Neuman, a liaison on the Council. “You’re talking about years of litigation, outside counsel, and no progress”.

Fellow council member Thomas Rickert of the ISPs constituency suggested looking for a law firm that would handle the IRP on a no-win-no-fee basis before committing further.

While it seems a Community IRP may be unrealistic for now, the fact that it’s even being discussed shows how seriously the GNSO is taking this apparent power grab by ICANN’s board and lawyers.

Jury still out on ICANN’s content policing powers

Key ICANN community groups have refused to come down on one side or the other in the debate about proposed content policing powers, leaving the question up in the air as ICANN considers a major bylaws amendment.

As I reported last month, ICANN is thinking about changing its governing bylaws to permit it to enforce Registry Voluntary Commitments — contract clauses that could include rules on the content of web sites — on registries in future new gTLD application rounds.

ICANN’s board is convinced that it needs to amend the Org’s bylaws, which explicitly prevent it policing content, in order to do this. It is concerned that “there are political, practical, and reputational risks associated with ICANN negotiating and entering into contract provisions that have the effect of restricting content in gTLDs”.

Such an amendment would require the consent of the five-member Empowered Community, to which ICANN answers, and so far there’s little indication that it would be able to secure the three votes needed.

The EC is made up of the ASO, the ccNSO, the GNSO, the ALAC and the GAC, and so far only the ALAC has said that it supports a bylaws amendment. The GNSO is split, with contracted parties dead against the amendment, and would be unlikely to vote in favor. The GAC seems to be on the fence.

The ASO and ccNSO both declined to express an opinion, saying matters related to gTLDs are outside of their remit, but ICANN chair Tripti Sinha pressed the groups to reconsider in letters this March.

Now, both groups have responded by digging their heels in — nope, it’s none of our business, they say.

“The topics addressed in the consultation are outside the scope of the ASO, so we respectfully decline the invitation to provide input at this time,” the ASO said.

“After careful consideration, we still do not see conditions which warrant our participation in the implementation of the next round of new gTLDs,” the ccNSO said.

The ccNSO added that it could only comment on a proposed bylaws amendment if it could see the draft text of the amendment, and that is not yet available.

If ICANN leadership was hoping for clarity on whether a content policing bylaws change is even feasible, it looks like it doesn’t have it yet.

It now takes TWO WEEKS to get a Whois record with RDRS

There’s been a shocking increase in the time it takes to get a Whois record disclosed under ICANN’s Registration Data Request Service, according to the latest monthly data.

It took on average 14.09 days to have a request for private Whois data approved using RDRS in April, more than double the previous high, recorded in February, of 6.92 days, the data shows. The average since the system launched at the end of November is 6.73 days.

The average time to have a request denied was 11.26 days, up from 6.17 days in March, the data also shows.

RDRS is a mechanism that allows people — largely intellectual property interests and law enforcement — to request unredacted domain ownership information. ICANN doesn’t handle the requests, it just forwards them to the responsible registrar.

It’s not obvious from the data why requests in April suddenly took so much longer to approve. Any number of reasons, from technical problems to a shift in the mix towards particularly sluggish registrars, could have thrown the average.

The percentage of requests that were approved was down very slightly compared to March, at 19.16% compared to 20.26%. Denied requests were up to 71.26% compared to 69.5% in March. Requests were largely denied because of data protection law or because the requester didn’t provide enough information.

Since RDRS launched five months ago, there have been 1,215 disclosure requests, 210 of which were approved. That works out to about 1.36 approved requests per day.

Registrar coverage improved a little in April, with three registrars newly listed and one (Sweden’s Ilait AB, which has about 6,000 domains) removed. The number of gTLD domains covered as a percentage remained flat at 57%.

ICANN has spent almost $2 million on RDRS to date. It’s a two-year pilot, and at some point it will have to be decided whether the expense is worth it.

Travel expenses push ICANN into the red again

ICANN is spending millions of dollars more than expected in its current financial year, which it blames mainly on inflation pushing up the price of flights and hotels.

The latest quarterly financial report, for the nine months to March 31, shows ICANN operations spent $112 million in the period, which was $6 million more than it had budgeted for. Funding was $113 million, $3 million more than expected, leading to a total deficit of $3 million.

ICANN said the costs were “driven by higher than planned costs for ICANN78, ICANN 79, community programs, and support of meetings other than ICANN Public meetings… primarily due to inflationary increases to travel and venue costs”.

ICANN 79, which took place in Puerto Rico in March, cost $600,000 more than budget. This was due to higher flight and hotel prices and more sessions than had been planned. ICANN said in February that October’s meeting in Hamburg had come in $900,000 over budget.

Funding for the nine months came in ahead of budget largely due to better-than-expected registrar fees, most likely related to drop-catching registrar Gname’s decision to buy 150 more registrar accreditations last December.

The report, which covers the third quarter of ICANN’s fiscal 2024, also breaks out how much some of the Org’s important projects have cost.

The Grant Program, which launched at the end of the quarter, has cost almost $1.4 million in development and operating expenses since July 2022, about $18,000 over budget. That’s obviously a big chunk of the $10 million ICANN intends to hand out this year, but nothing compared to the auction proceeds fund that the grants come from — that was up $9 million to $226 million since last July based on investment gains.

The Registration Data Request Service, which launched last November, has cost just shy of $2 million to develop and run since December 2022. Compare this to the $100 million a year ICANN had predicted before the ambitions of the original proposed project were massively scaled back.

Overall, ICANN’s financial position is still incredibly healthy. Its total funds under management was up $11 million to $529 million over the nine months due to investment gains.

ICANN preparing for ONE HUNDRED registry back-ends

The number of gTLD registry back-end providers could more than double during the next new gTLD application round, ICANN’s board of directors has been told.

There are currently about 40 registry services providers serving the gTLD industry, but ICANN is preparing for this to leap to as many as 100 when it launches its Registry Service Provider Evaluation Program for the 2026 application round.

“We’re preparing, I think, for roughly a hundred or so applications which will include the 40 existing providers that we’re aware of, and another 60 or so is sort of our rough market sizing,” Russ Weinstein, a VP at ICANN’s Global Domains Division, told the board during a meeting in Paris last week.

The number is based on what ICANN is preparing to be able to handle, rather than confirmed applicants to the RSP program, it seems.

“We are hoping to see some diversification and new entrants into the space,” Weinstein said.

Board member Edmon Chung elaborated that he expects most of the new entrants to be ccTLD registries hoping to break into the gTLD market.

“We can expect a few more ccTLD registries that might be be interested,” he said. “We’re probably not expecting a completely new startup that just comes in and becomes a registry, but beyond the 40, probably a few more ccTLDs.”

ccTLD registries already active in the gTLD market following the 2012 application round include Nominet, Nic.at and AFNIC, which tend to serve clients that are based in the same timezone and use the same native language.

A new way to game the new gTLD program

It may not help you win a gTLD, but a new method for screwing over your enemies in ICANN’s new gTLD program has emerged.

As I reported earlier today, it seems quite likely that ICANN is going to add a new step in the new gTLD evaluation process for the next round — testing each applied-for string in the live DNS to see if it causes significant name collision problems, breaking commonly deployed software or leading to data leaks.

The proposed new Technical Review Team would make this assessment based in part on how much query traffic non-existent TLDs receive at various places in the DNS, including the ICANN-managed root. A string with millions of daily queries would be flagged for further review and potentially banned.

The Name Collision Analysis Project Discussion Group, which came up with the new name collisions recommendations, reckons this fact could be used against new gTLD applicants as a form of sabotage, as it might be quite difficult for ICANN to figure out whether the traffic is organic or simulated.

The group wrote in its final report (pdf):

In the 2012 round, the issue of name collisions included an assumption that the existence of any name collision was accidental (e.g., individuals and organizations that made a mistake in configuration). In future rounds, there is a concern on the part of the NCAP DG that name collisions will become purposeful (e.g., individuals and organizations will simulate traffic with an intention to confuse or disrupt the delegation process)…

Determining whether a name collision is accidental or purposeful will be a best-effort determination given the limits of current technologies.

We’re basically talking about a form of denial of service attack, where the DNS is flooded with bogus traffic with the intention of breaking not a server or a router but a new gTLD application filed by a company you don’t like.

It probably wouldn’t even be that difficult or expensive to carry out. A string needs fewer than 10 million queries a day to make it into the top 25 non-existent TLDs to receive traffic.

It would make no sense if the attacker was also applying for the same gTLD — because it’s the string, not the applicant, that gets banned — but if you’re Pepsi and you want to scupper Coca-Cola’s chances of getting .coke, there’s arguably a rationale to launch such an attack.

The NCAP DG noted that such actions “may also impact the timing and quantity of legal objections issued against proposed allocations, how the coordination of the next gTLD round is designed, and contention sets and auctions.”

“Name collisions are now a well-defined and known area of concern for TLD applicants when compared to the 2012 round, which suggests that individuals and organizations looking to ‘game’ the system are potentially more prepared to do so,” the report states.

I’d argue that the potential downside of carrying out such an attack, and getting found out, would be huge. Even if it turns out not to be a criminal act, you’d probably find yourself in court, with all the associated financial and brand damage that would cause, regardless.

.home, .mail and .corp could get unbanned

The would-be new gTLDs .home, .mail and .corp — which were some of the most hotly contested strings in the 2012 application round before ICANN banned them — could get a new lease of life if ICANN adopts the recommendations of a panel of security experts.

More than 20 applications for the three strings were first put on hold, and then rejected outright in 2018, due to the risk of name collisions — where a TLD in the public DNS clashes with a domain used extensively on private networks.

The three non-existent TLDs receive more than 100 million queries per day at the DNS root due to queries leaking out from private networks, creating the risk of stuff breaking or sensitive data being stolen if they were to ever be delegated.

But now ICANN has been told that it “should not reject a TLD solely based on the volume of name collisions” and that it should submit .home, .mail and .corp to a new, more nuanced “Name Collision Risk Assessment Process”.

The recommendations comes in a newly published and rather extensive final report (pdf) from the Name Collision Analysis Project Discussion Group, which has been looking into the name collisions problem for the last four years.

While NCAP says ICANN should create a Collision String List of high-risk strings that new gTLD applicants could consult, it stopped short of recommending that the Org preemptively ban strings outright with a “do not apply” list, writing:

Regarding .CORP, .HOME, and .MAIL, high query volume is not a sufficient indicator of high-risk impact. The complexity and diversity of query sources further complicate the assessment of risk and impact. It is impractical to create a pre-emptive “do-not-apply” list for gTLD strings due to the dynamic nature of the DNS and the need for real-time, comprehensive analysis.

.corp might have a relatively easier time getting unblocked. NCAP figured out that most queries for that TLD are due to one “globally dominant software package” made by Microsoft that uses .corp as a default setting. This problem would be easier to fix than .home, which sees bogus traffic from a huge range of sources.

.mail also might be safe to delegate. NCAP noted that at least six gTLDs with more pre-delegation query traffic — .network, .ads, .prod, .dev, .office and .site — were subsequently delegated and received very low numbers of collision reports from live deployment.

Instead of banning any string, NCAP instead proposes a new Name Collision Risk Assessment Framework.

Under the framework, a new Technical Review Team would be in charge of testing every applied-for gTLD not already considered high risk for collision risks and placing the high-risk ones on a Collision String List of essentially banned strings.

To do so, the applied-for gTLD string would have to be actually delegated to the live DNS root zone, under the control of the TRT rather than a registry or applicant, while data is gathered using four different methods of responding to query traffic not unlike the “controlled interruption” method currently in use.

This would be a huge break from the current system, under which gTLDs only get delegated after ICANN has contracted with a registry operator, but it would mean that IANA would be able to quickly yank a gTLD from the DNS, if it started causing serious problems, without stepping on anyone’s commercial interests or inviting legal action.

There’s little doubt that the proposed framework would add friction to the new gTLD evaluation process in the next round, but the fact that NCAP has delivered its recommendations ahead of its original schedule is good news for those hoping for no more delays to the next round actually launching.

The NCAP study was considered on the critical path to the next round. It’s already been approved by the Security and Stability Advisory Committee and is expected to be considered by ICANN’s board of directors at an upcoming meeting. Implementing the recommendations would obviously take some time, but I doubt that would delay the expected Q2 2026 opening of the next application window.

The new recommendations on .corp, .home and .mail mean those gTLDs could well come back into play in the next round, which will come as cold comfort to the applicants who had their $185,000 application fees tied up for years before ICANN finally decided to ban them in 2018, offering a full refund.

There were seven applicants for .mail, six for .corp, and a whopping 11 for .home. Applicants included GoDaddy, Google, Amazon, and Identity Digital.

According to ICANN’s web site, Google never actually withdrew its applications for .home, .corp and .mail, and Amazon never withdrew its application for .mail. If that’s accurate, it could lead to some interesting disputes ahead of the 2026 application round.

Unstoppable to apply for Women in Tech gTLD

Unstoppable Domains and Women in Tech Global have announced that they plan to apply for a new gTLD when ICANN opens the next application round.

They want .witg, which Unstoppable has already launched on its blockchain-based naming system. They cost $10 a pop.

Unstoppable says the names come with some social networking features, as well as the usual ability to address cryptocurrency wallets.

The company has also recently announced gTLD application partnerships with POG Digital for .pog, Clay Nation for .clay and Pudgy Penguin for .pudgy.

Unstoppable is mainly competing here with D3 Global, which is also recruiting blockchain businesses that want to embrace the DNS when the next round opens.

GoDaddy getting a free pass from porn jail?

ICANN has shirked its compliance duties and is handing GoDaddy a “Get Out of Jail Free” card with proposed changes to their .xxx registry agreement, according to critics.

A recently closed public comment period saw a mixed response from the community on whether GoDaddy should be allowed to throw out inconvenient and costly terms of its 10-year-old registry contract and operate .xxx more of less like any other open gTLD.

While the deal’s chief critic, consultant and former ICANN director Michael Palage, has made a detailed case explaining why he thinks the amendments should not go ahead, other commenters agree with GoDaddy that some of its stricter registration policies are no longer needed.

Tucows said that the current .xxx rules, which require registrants to verify their identities, are “cumbersome or non-transparent”, not only adding unnecessary friction to the registration path but also amounting to the “surveillance of sex workers”.

Palage managed to persuade the At-Large Advisory Committee to submit its own comments, in which ALAC claims that GoDaddy has already “walked away” from three important contractual commitments on registrant verification and abuse reporting “unilaterally and without consequence from ICANN Contractual Compliance”.

According to Palage, when GoDaddy acquired ICM Registry from MMX a few years ago it unilaterally decided to stop verifying the identities of its registrants and did away with the unique community membership IDs that enabled it to deactivate a registrant’s entire portfolio if it was found to be in breach of the rules by, for example, publishing child sexual abuse material.

ICM also stopped donating $10 for every registration to its oversight body, IFFOR, which in turn spent the money it did receive on director salaries rather than making cash grants to child protection causes, Palage says. I’ve previously gone into some depth on this.

“I am concerned that instead of ICANN compliance holding ICM Registry accountable to these representations, they’re essentially giving them a get out of jail card free and potentially removing the ability for third parties to hold ICM Registry accountable to those representations,” Palage said during a March presentation to the ALAC.

His draft comments for the ALAC were subsequently submitted under his own name; ALAC submitted a shorter, somewhat watered down version drafted by chair Jonathan Zuck.

But ALAC and Palage are in agreement that GoDaddy should have gone through the usual Registry Services Evaluation Process if it wanted to change the terms of its contract, and that the proposed amendments set a terrible precedent. ALAC wrote:

ALAC believes that commitments made in order to operate a TLD by a Registry Operator should be enforceable, subsequently implemented by the Registry Operator, and enforced by ICANN Contractual Compliance… The ALAC is concerned that the removal of commitments, through a contract renewal, could set a precarious precedent for non-compliance without repercussion for existing Registry Operators

The Business Constituency echoed ALAC’s concerns in its own comments, as did registry operator CORE Association.

Comments in favor of the .xxx amendments came from two veteran, dissenting voices from the At-Large community, Evan Leibovitch and Carlton Samuels. They said removing the extra requirements from the .xxx contract would reduce confusion and were worthless anyway:

Given the benefit of hindsight, the “Sponsored gTLD” program and designation have not on the whole provided any significant benefit to the Internet-using public. As such, we welcome the removal of this designation — and any associated extra contract requirements — from all applicable Registry Agreements going forward.

Tucows’ support for the amendments are based largely on what a pain in the neck it can be — for registrant and registrar — to register a .xxx domain. Its comments explain:

Currently, to register a .xxx domain, one must become a member of the Sponsored Community, which involves a separate application process to verify eligibility. This extra step is a barrier for those looking to quickly secure a domain. Additionally, the domain cannot resolve—meaning it cannot be used to host a website—without a valid Membership ID, which is only issued after this verification process… This activation involves additional interactions between the registry, the registrant, and the registrar. Additional steps in the registration process can be a significant deterrent as they introduce complexity and time delays.

I’m not really buying the “surveillance of sex workers” claim. Porn producers in many jurisdictions, including the US, already routinely verify the identities of their performers, and keep copies of their identity documents on file, as a legal requirement to ensure their employees are not underage.

ICANN is due to publish its summary of the public comment period by May 20.

How ICANN handles the renewal of and amendments to the .xxx contract will be interesting to watch. Will the Governmental Advisory Committee get a chance to weigh in before the deal is signed? Will the board pass a resolution, or will we see a repeat of the .org renewal debacle?

Correction: Sinha’s seat is safe

Last Friday, I speculated that, based on my back-of-the-envelope calculations, ICANN chair Tripti Sinha could find herself ineligible to continue on the ICANN board of directors this November, due to geographic diversity quotas.

My calculations were incorrect, it turns out. While she still needs to be reappointed by the Nominating Committee, Sinha is not limited by the geographic diversity limits. I’ve deleted the article and apologize for the error.