IGP comments to NTIA on the IANA Functions

Comments of the Internet Governance Project on the NTIA's “Request for Comments on the Internet Assigned Numbers Authority (IANA) Functions” (Docket # 110207099-1099-01)

This submission is from the Internet Governance Project (IGP), an alliance of academics doing research and policy analysis in the fields of global governance, Internet policy, and information and communication technology. http://blog.internetgovernance.org

For better or worse, the IANA contract is perceived as one of the linchpins of global internet governance. For that reason, our comments begin by assessing the role of the IANA contract in the overall Internet governance regime.

At the highest level, there are three alternative approaches to the future of the IANA function.
1. One is to continue with the status quo, which involves the U.S. government exercising unilateral control over the nature of the functions embodied in the agreement and choosing the contractor.
2. The second approach, which is desired by many governments around the world, is to multi-lateralize the contracting process. The U.S. would share its authority over the IANA function with other governments, either on a one-country, one-vote basis or through some subset or club of privileged governments.
3. The third approach is to de-nationalize the IANA function. This means fully delegating the IANA functions to nongovernmental actors in the private sector and civil society, and eventually eliminating the U.S. government's direct authority over it.

The first two options have numerous pitfalls. Unilateral U.S. control of the IANA contract disenfranchises most of the world's Internet users, and is a thorn in the side of many other governments, including friendly ones such as the European Union. The U.S. government's role leads inevitably to a demand by other governments for equal status and draws Internet coordination processes into inter-state rivalries, adding an unduly political dimension to activities that should be driven by coordination, efficiency, technical expertise and a concern for global interoperability and the interests of all users. But making the contracting process multilateral and intergovernmental makes a bad situation worse. The involvement of multiple nation-states in basic internet coordination processes would make IANA a plaything of geopolitics and drastically increase the complexity and difficulty of its tasks.

The third approach – de-nationalization – is the best. Denationalization was in fact the original objective of the process that created ICANN. It is worthwhile to reiterate the reason why. It was understood at the time that the Internet needed a truly globalized regime for governing the coordination processes and policies associated with Internet identifiers. Territorial governments insistent upon their sovereign powers were perceived as inherently incapable of delivering that kind of globalized compatibility and coordination. This problem, it was thought in 1997-98, could be avoided through reliance on private sector organizations rooted in the Internet technical community, operating on the basis of transnationally applicable contracts and agreements.

Denationalization, however, requires that the private sector institutions that inherit the governance responsibilities be responsible, accountable and stable. Thus while we agree with ICANN's comments that the IANA contract's ultimate aim should be devolution to a private actor, we do not agree with the implication that ICANN as it currently exists should be the presumptive recipient of all the IANA functions. Part of the reason is the imperfection and lack of maturity of ICANN's accountability arrangements. A more important reason, however, is that ICANN currently combines too many functions in a single organization. Currently, ICANN performs both operational and policy making functions (e.g., running the L root), and the IANA contract unnecessarily concentrates multiple functions in the hands of a single entity. We do not think it advisable to privatize all those functions in a single corporation's hands, especially given the weakness of its accountability arrangements. We see an unbundling of the IANA functions as a way to minimize any risks and dangers that might be associated with de-nationalization. The unbundling must take place first, full de-nationalization second.

We believe therefore that NTIA should use the next cycle of the IANA contract to prepare the way for unbundling the protocol parameters, IP address resources and DNS root zone coordination functions, aiming for the eventual delegation of those separated functions to appropriately accountable non-state actors, such as the IETF for protocol parameters. We recommend that this happen expeditiously, but not too hastily – e.g., over a three-year time span.

With that preamble, we now address the first two questions in the RFC:

Q1: There is no technical or economic imperative that requires combining domain name, IP address and protocol parameter coordination in a single entity. IGP supports the comments of Internet NZ and Bill Manning regarding the feasibility and desirability of separating the distinct IANA functions. Structural separation is not only technically feasible, it has good governance and accountability implications. By decentralizing the functions we undermine the possibility of capture by governmental or private interests and make it more likely that policy implementations are based on consensus and cooperation.

Q2: This is not a simple question. In general, we believe that the IANA contract should avoid rigid, formalized specifications of the roles of specific actors. A U.S. government IANA contract is supposed to be a transitional device on the road to full denationalization. An IANA contract that names specific entities such as ICANN, the RIRs, IETF and ccTLD operators, and then legally requires them to fulfill certain responsibilities with respect to each other, starts to take on the characteristics of a constitution of cyberspace, one that makes the NTIA its perpetual legislator and Supreme Court. We think that is not desirable. On the other hand, we agree with Internet NZ that a well-drafted set of IANA contracts would “clearly state, for each registry, the entity that determines policy for that registry and contain clear instructions that the operator must follow the policy set out by that entity and not create any policy of its own.” Ideally there would be separate contracts for each IANA function, and thus no contract would need to reference any entity other than the registry and the policy making entity for that registry.

Comments are closed.