Earlier this week, I posted from Singapore on the challenges we face in designing the transition of IANA functions from the US government to the global multistakeholder community. Now, let’s consider how a programmer would design new mechanisms to accomplish this transition.

For starters, a programmer would need something more than high-level principles. Coding requires use cases for routine interaction and especially for cases where users don’t follow the expected routine and where the real world intervenes with inconvenient problems.

For non-programmers, here’s an analogy: It’s a good principle to practice safe driving in winter weather. It’s a use case to prepare for and respond to a specific situation, such as having your car begin spinning sideways on a snow-covered highway.

Knowing the array of possible use cases helps us anticipate worst-case scenarios and design appropriate responses, regardless of whether those scenarios ever actually occur.

Today, ICANN is an effective organization that generally performs its core functions, so it can be uncomfortable to imagine a scenario where a future ICANN fails dramatically or is confronted with a serious threat. But that’s what we must do to design and develop mechanisms that will ensure ICANN’s accountability and stability into the foreseeable future.

And that’s where use cases come in. Let’s consider worst-case scenarios and develop mechanisms that would resolve those scenarios in a way that’s at least as effective as the admittedly crude mechanism we have today—where the US government ensures a stable root if the IANA contractor can’t, and where the threat of losing the IANA contract keeps ICANN accountable to its global stakeholders and the public interest.

At ICANN’s Singapore meeting this week, I suggested a few use cases that the community should address in designing for transition of IANA functions and ICANN accountability:

• What happens if ICANN cancels the Affirmation of Commitments, which it can do with just 120 days notice? Or if ICANN fails to implement recommendations of an Affirmation review?
• What happens if ICANN deliberately escapes legal presence in a nation where users, registrants, and contract parties need to seek legal remedies?
• What happens if ICANN becomes financially insolvent?
• What happens if ICANN approves a specific change to the root that could threaten its stability and security?
• What happens if governments advise ICANN to remove TLDs from the root in order to suppress dissent and free expression?

This last use case is unfortunately more plausible than fanciful, if you go by comments made by Chinese and Iranian governments at yesterday’s meeting between the GAC and the ICANN Board. Both expressed deep skepticism about the multistakeholder process and dissatisfaction with the power of governments. Our use cases should help us test whether the mechanism we develop can respond to protect the multistakeholder model from those who would usurp it.

You can reasonably argue that today’s IANA contract includes nothing to respond to any of the use cases listed here. But we all know that the influence of the IANA contract award extended far beyond its functional limitations. Remember 2012, when the US government canceled the IANA bid process because ICANN’s bid did not meet the higher performance standards? If you look, you’ll clearly see the leverage of the IANA contract decision in enforcing the only external accountability that ICANN has: the Affirmation of Commitments.

If the Affirmation is to remain part of the new ICANN accountability framework, as most of us expect it will, it’s essential that the leverage formerly conveyed by the IANA contract be replaced with a new mechanism.

Let’s establish the right use cases as part of the process to design new accountability mechanisms, and we’ll end up with something that will answer to the threats and challenges we’re likely to face in the real world.