|
||
|
||
I have been thinking about the multistakeholder model’s remedy problem for some time now. We talk extensively about accountability, transparency and mechanisms for challenging institutional decisions. We talk far less about what happens after those mechanisms establish that the institution got it wrong.
The 2026 applicant needs to know what happens after they win. The record is not reassuring.
The 2026 gTLD applicant is walking into a system that has been tested. Not in theory. In practice. By real applicants who won real accountability rulings and still walked away empty-handed.
Afilias won its IRP against ICANN over .web. The panel found that ICANN had violated its own rules. Afilias did not get .web.
Altanovo, formerly Afilias, went back to IRP a second time. It withdrew that proceeding in July 2026. It still did not get .web.
DCA won its IRP against ICANN over .africa in 2015. The panel found that ICANN had violated its Bylaws. DCA did not get .africa.
When DCA went to court instead of initiating another IRP, ICANN argued that DCA should have gone back to IRP. When Afilias actually did go back to IRP, it still did not get the string.
The system offers multiple doors. None has demonstrated a reliable path to an effective remedy.
That is the problem. Accountability can become a procedural maze that exhausts the applicant without restoring what the applicant lost. ICANN loves to send people on a merry-go-round pretending there is accountability.
This is a pattern I have seen before. I call it obfuscation by repetition: the repeated presentation of another accountability procedure as though the existence of another procedure answers the absence of a remedy.
It does not.
Repeat IRPs can create an appearance of abundant accountability while obscuring the more consequential question: what are these proceedings actually empowered to remedy? Counting procedures is not the same as measuring outcomes.
Process cannot become the remedy for the failure of process.
When Altanovo sought relief that could ultimately deliver .web, ICANN argued that the panel’s remedial authority did not extend to ordering the substantive actions necessary to produce that result.
That history has an important parallel in .africa.
The .africa IRP panel found that ICANN’s Board had acted inconsistently with its Articles and Bylaws. But the IRP framework in place at the time focused on Board conduct. It did not provide the same reach over staff conduct that exists under today’s Bylaws.
That distinction became critical after DCA’s IRP victory. When subsequent evaluation decisions again blocked DCA’s application, DCA went to court rather than start another trip around ICANN’s accountability machinery.
When DCA went to court, ICANN advanced the narrative that DCA should have gone back to IRP. DCA argued the opposite: neither the rules then in force nor the IRP framework provided a basis for using another IRP to reach the staff conduct at issue.
There was another fact sitting underneath that decision. Evidence developed in the litigation concerning the African Union Commission endorsement process, including sworn testimony from ICANN’s former CEO about his role in drafting language associated with the endorsement. Yet ICANN later maintained in court that DCA could have pursued another IRP.
DCA disputed that proposition. The record included testimony from ICANN’s own former Global Domains Division president concerning whether the evaluation decisions at issue could have been reviewed through IRP under the framework then applicable.
Nevertheless, the proposition that DCA could, or should, have returned to IRP made its way into the judicial narrative.
That is precisely why the later .web experience matters.
Afilias did what DCA was faulted for not doing. It went back. Altanovo’s second IRP sought substantive relief connected directly to obtaining .web. ICANN opposed that relief, including on the ground that the panel lacked authority to order the substantive remedies Altanovo sought.
Then the proceeding was withdrawn.
The applicant still did not have the string.
So we now have something better than theory. We have both routes tested. DCA took the courthouse route. Afilias took the repeat-IRP route. Neither route answers the fundamental question: where is the remedy?
Afilias went back to IRP a second time. I chose not to. I had already seen how the first trip ended.
The 2026 Applicant Guidebook makes that question even more important. Its Terms and Conditions contain sweeping releases and waivers concerning judicial challenges to ICANN’s application decisions. Applicants are entering the program knowing that their ability to seek conventional judicial relief against ICANN is contractually constrained.
Think about what that means commercially. You accept significant limitations on your ability to sue before you even know what dispute may arise. You are narrowing your access to the courthouse before you know what you might need the courthouse to remedy.
ICANN’s accountability architecture is broader than it was in 2012. That should be acknowledged. Staff conduct can now fall within IRP Covered Actions, and the accountability reforms adopted since the previous round addressed some important weaknesses in the earlier system.
But expanding the scope of accountability does not solve the problem of remedy.
What can an IRP panel actually order?
The Altanovo proceeding exposed that tension directly. When Altanovo sought relief that could ultimately deliver .web, ICANN argued that the panel’s remedial authority did not extend to ordering the substantive actions necessary to produce that result.
A declaration that ICANN acted improperly is valuable. It establishes accountability. It creates precedent. The .africa IRP proved exactly how important such a precedent can become.
But if the injury is the loss of a unique commercial opportunity, the applicant needs more than a declaration. The applicant needs to know whether the accountability mechanism can restore it to the position it would have occupied had the improper conduct not occurred.
The record does not provide a reassuring answer.
ICANN has learned from the previous round. Its accountability architecture is broader. But institutional learning should not end with creating better ways to identify institutional error. It must eventually confront what happens to the party injured by that error.
The IRP docket tells a story. Applicants can win significant findings against ICANN without necessarily obtaining the commercial outcome at the center of the dispute. The system can find ICANN in violation of its own rules. It can establish precedent. It can produce decisions celebrated as accountability victories.
But what happens to the applicant afterward?
That is the missing last mile of accountability.
For the 2026 applicant, the lesson is not to accept anyone’s description of the accountability architecture at face value. Read the Bylaws. Read the Applicant Guidebook. Read the Terms and Conditions. Study what ICANN itself argues when successful claimants request substantive relief. And study what happened to the applicants who came before you.
The question applicants rarely knew to ask in 2012 should be asked before a dispute arises in 2026:
If I prove ICANN got it wrong, what exactly can I win?
A system should not be judged merely by whether it allows an injured party to challenge a decision. It should be judged by what happens after that challenge succeeds.
Because accountability without remedy is not accountability.
It is documentation.
Sponsored byDNIB.com
Sponsored byRadix
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byVerisign
Sponsored byCSC
Sponsored byIPv4.Global