The siren song of ‘simplicity’

The sirens, if you recall your Greek mythology, used their beautiful voices to lure passing sailors eager to listen to them into rough waters and rocky reefs that destroyed their ships and drowned the men.

A similar phenomenon is occurring now with the IANA transition. (The voices are not the lithe and lovely daughters of the river god Achelous, alas, but current and former ICANN board members.) The voices tell us how simple and easy the transition would be if we didn’t bother with any contracting relationship. All we have to do is leave IANA in ICANN, which is doing a fine job now. Why create any new moving parts? Why worry about separability?

Of course, simplicity is desirable. But the “solution” currently being offered in its name is an illusion.

Let’s begin with the most obvious fact: the current performance of the IANA functions is the product of a contractual relationship with the NTIA, and an MoU with the IETF. Getting rid of that recurring contracting process is a major change in the status quo. How IANA and ICANN will behave in its absence is an open question. We cannot just assume that all will be fine.

But that is only the first rock to avoid. The sirens of ICANN cannot help but recognize the need for some kind of accountability and separability. They tell us we don’t need contracting – if we don’t trust ICANN to do the IANA functions right, we can “fix” ICANN through the CCWG accountability process. Or we can have some new process within ICANN that will allow us find a new operator.

And that’s when simplicity turns into devilish complexity.

The CCWG on ICANN accountability is now talking about nearly a dozen complex bylaw changes. New procedures to allow community members to “spill the board.” New appeals processes. Possibly new membership structures. One internal solution proposed in the CWG proposes a ‘golden bylaw,’ of questionable legal feasibility, to allow some unspecified, not-yet-created committee within ICANN to move the functions to someone else. This is not simple. Not only is it complex, it relies on decisions that will be made and implemented months or even years into the future.

Moreover, all of the actual proposals for internal solutions so far involve the creation of some equivalent of a Customer Standing Committee, or a Multistakeholder Review Team, or both. In other words, they incorporate the same structures that were proposed to implement the contracting, ‘external’ solution. Where is the simplicity gain? Why do all the problems the internalists found with these structures disappear when they become part of ICANN?

In short, the advocates of an ICANN-centric ‘simplicity’ are broadcasting beautiful music, but diverting our attention from the shoals and rocks that must be avoided if an internal solution is to provide the same level of accountability and performance that a contracting solution provides.

Even if you think ICANN is ready to take that step away from NTIA, why wouldn’t the customers of the names-related IANA functions want to be able to impose a service level agreement (SLA) on ICANN’s IANA department, and be able to enforce it by exercising a right to move the contract to someone else? The IETF has retained that right. The numbers community has newly asserted that right for the numbers-related functions as part of the IANA transition. If contracting is seen as necessary and beneficial for those communities, why is it not also beneficial for names?

This debate is not about simplicity vs. complexity. It is about the most resilient and effective methods of providing good performance of the IANA functions and accountability for ICANN as a whole. The next time you hear someone tell us how simple it will be to manage the IANA functions in an accountable manner without the NTIA, ask for an organization chart and a detailed, specific description of the bylaw changes required to implement it.

We’re betting it won’t be simple.