In Defense of Process: Identifying the Problem Before Seeking Solutions

 

You don’t necessarily need to walk before you can run, but you should probably look where you are before you do either.

The U.S. Government’s announcement that it would transition out of its unique legacy role in ICANN set off a powder keg at ICANN, as stakeholders from every corner of the community rushed to offer their recommendations on how to fill the impending contractual vacuum with something, new, better, and appropriately reflective of the multi-stakeholder model.

These are worthwhile efforts, but before we dig more deeply into the meaty challenge of identifying solutions, it may make sense for all of us to take a big step back and come to some sort of consensus about the problem we’re trying to solve.

Listening to the outpouring of comments on the transition, it’s pretty clear that we don’t yet even have clear agreement about what it is we are transitioning. Are we simply focusing on the mechanical aspects of the IANA functions, or are we also considering the non-explicit “backstop” role that the U.S. Government has traditionally played in the ICANN process?

There may be more questions to answer, but minimally, a chartering group to define the challenge should be able to answer:

  • What roles (explicit and implicit) does NTIA fill under the current arrangement?
  • How else are those roles handled in the current ecosystem?
  • What roles do accountability functions need to perform?
  • Who needs to be involved in defining the transition (including non-traditional ICANN participants)?
  • What existing roles could be improved/strengthened through a transition process?
  • What is included in the transition?
  • What existing contracts/mechanisms in the ICANN space could be enhanced or expanded to fill new gaps?
  • What scenarios should a transitioned framework minimally be designed to meet?

How we answer those questions will have a major effect on how we answer all the questions that follow. By not even asking them, we dramatically reduce our likelihood of arriving at an effective resolution.

At the outset of this meeting there was talk of “starting the process to define the process,” which may sound comically bureaucratic, but actually may not be procedural enough.

Before we define the process to define the process we need to define the scope of the challenge that the process will be required to meet.