If you read anything today about ICANN taking over the internet, make sure it's this
Hodgepodge of flawed ideas, bad processes
Analysis The internet community has published its plan to pull the United States government out of its role at the top of the internet's hierarchy.
Unfortunately, the near-final version is a hodgepodge of ideas and compromises that fails to address a key aspect of Uncle Sam's role.
In addition, the plan substitutes a complex set of unworkable process steps in place of the US Department of Commerce's simple oversight of the internet. And it is reliant on a separate, unfinished process for improving accountability at the organization that will assume de facto control, ICANN.
Most of the problems in the plan stem from political rather than technical issues, which means its main aspects are likely to remain even after a public comment period.
In particular, the decision to award ICANN control of the IANA contract through a wholly controlled affiliate remains controversial, and there is some reason to believe that the process was distorted in order to arrive at a pre-decided outcome.
The unnecessary complex processes included in the plan are, however, likely to be simplified before the final version, as they were earlier in the process.
Most broadly, the plan [PDF] envisions creating a subsidiary of domain-name overseer and current IANA contract holder ICANN to take over all the technical functions.
That approach would give ICANN's board "the authority to approve any major architectural and operational changes in the management of the root zone." In other words, control of the internet's future structure.
In an effort to keep that additional power in check, a number of review committees are proposed. One will review the day-to-day operations and another will be able to recommend moving the entire contract away from ICANN as a final backstop.
There are significant holes in the plan, though, which stem from two broad issues:
- The IANA contract comprises three distinct functions serving three distinct groups
- The "multistakeholder model" used to develop ICANN policy frequently develops overly complex, process-driven solutions that create more problems than they solve
The IANA contract itself deals with three clear areas: names, numbers, and protocols. Names are domain names that people can navigate online; numbers are IP numbers so machines can join the network and communicate with each other; and protocols are the way in which information is shared across the network.
Each function is vital to the internet's overall functioning and they are intertwined in the sense that they all rely on one another. But at the same time, each function is also separate, with completely different rules and procedures, legal agreements, and end customers.
As a result, the group in overall charge of developing a final IANA plan – the IANA Stewardship Transition Coordination Group (ICG) – decided to ask each of the three communities to develop their own proposal. The idea is that the ICG would then combine them into one coherent plan to send on to the US government.
However, partly due to time constraints and partly due to dysfunction, the ICG has done a poor job combining the plans, simply squashing them into one box and putting it out for public comment.
And so while we have the ICANN-controlled subsidiary called the "Post Transition IANA," or PTI, for the names function, it's not clear whether the PTI will be used for the two other functions or whether they will simply interact directly with ICANN (with whom they intend to extend existing agreements). As such, the most argued-over component of the plan may be effectively moot for two of the three communities.
In addition, both the names and the numbers communities have decided they need to have a review committee that will look at how ICANN carries out its duties. But rather than find a way to combine them, the ICG has simply included both, adding unnecessary complexity to an already complex plan.
Rather than bring the functions together, the proposed plan highlights the fact that there is no real need for a single IANA contract. And that highlights the fact that a once-in-a-lifetime opportunity to look afresh at the internet's core technical functions has been completely ignored.
Confused? This is nothing compared to the process for separating IANA from ICANN
Sponsored: Becoming a Pragmatic Security Leader