Clarity emerging on IANA transition

There were three big issues at the London ICANN meeting. The most important was the globalization of IANA; the second was the release of the Expert Working Group (EWG) report on Whois, privacy and future directory services. The least important, but equally contentious was the French revolt over geographical indicator protection in the .WINE/.VIN domain. This article focuses on the critical IANA transition issue; the others will be addressed later.

ICANN’s London meeting took some small but important steps forward in the IANA transition process. This happened despite some early expressions of mutual mistrust by key parties. Some of that mistrust was based on a misunderstanding, one that is beginning to be cleared up. More specifically, there was real progress in arriving at a common understanding of the relationship between the IANA transition process and ICANN’s broader “Enhancing Accountability” process. Despite this progress, a new area of ambiguity and contention was identified: the role of the ICANN board in approving or intervening in the work of the IANA transition coordinating committee. More about that at the end.

It is now clear there are two distinct kinds of accountability problems in play, and many people are conflating them. One is the accountability of ICANN’s policy making process for domain names. It concerns matters such as: How can we ensure that the policy decisions made by ICANN’s board are accountable to the broader community of Internet users and suppliers? What kind of appeals mechanisms or redress should there be when ICANN’s policy making deviates from the correct path?

The other accountability issue relates specifically to IANA and the end of U.S. government oversight. It involves question such as: How can we ensure that ICANN’s policy development is kept separate and distinct from IANA’s operational implementation of changes in the DNS root zone? In other words, how can we be sure that whoever is in control of the root does not abuse that authority by implementing changes that are not first developed and authorized by the community? Also, how can we be sure that the IANA functions are performed securely, efficiently and accurately, that the ‘customers’ of IANA have some redress if the services are not performed properly? The end of the NTIA contract would mean that there is no longer any party with the authority to enforce these concerns; something has to replace it.

Call these Accountability type A (policy process) and type B (IANA implementation). Up to now, the term “accountability” has conflated both of those meanings.

That confusion partly explains why ICANN’s CEO and staff were so worried about keeping the accountability process separate from the IANA transition, and why they resisted efforts to make accountability improvements a “prerequisite” for the IANA transition. Their fear, in a nutshell, was that complex debates over the massive reorganizations required to make ICANN’s policy making processes and organs fully accountable would set the bar for the transition so high that it might never happen. But that conflation also explains why other parts of the community, ourselves included, insisted that accountability was indeed a prerequisite for the IANA transition, and why we were extremely suspicious of ICANN management’s attempt to keep accountability and IANA on separate tracks. One cannot give ICANN unchecked control of the DNS root, a critical resource for the global Internet, without some form of accountability that fills the gap left by the end of the NTIA contract. And the sad truth is that withholding control of the IANA from ICANN until it reforms is the best – possibly the only – leverage we have to effect reforms.

Our initial paper on how to globalize IANA recognized the distinction between type A and type B accountability, and now people are beginning to appreciate it. We pointed out in March that structural separation of ICANN as policy maker from IANA as implementer would prevent concentration of unchecked power in ICANN’s hands and help keep IANA accountable – without having to solve all of ICANN’s other accountability problems at once. Once the two were separated, the ICANN community could take a longer-term, less rushed approach to reforming ICANN’s policy making processes. Issues such as the role of members in electing the board, ICANN’s legal status, new appeals mechanisms and the like could take years to develop and implement. It is unwise to tie the IANA transition to those changes.

At a meeting with the Noncommercial Users Constituency in London, NTIA director Lawrence Strickling and State Department Ambassador Danny Sepulveda confirmed our sense that structural separation of IANA from ICANN is not ‘out of scope.’ While the IANA transition and accountability are separate, with the accountability track dealing with higher level governance questions, they have no problem with an IANA transition plan that tries to align DNS governance with the governance of protocol paramters and numbers, where policy making and IANA implementation are conducted by separate organizations. The IANA transition Coordinating Committee, Strickling said, “can do what it wants” in that regard. Strickling himself expressed support for separation of policy and implementation.

The role of the coordinating committee for the IANA transition (CC-IANA) is now becoming the next interesting issue. Fortunately, the committee is no longer viewed as a steering committee that makes the plan for the IANA transition, but more as a coordinator of the three distinct communities with a stake in the transition – names (ICANN), numbers (RIRs) and protocol parameters (IETF). The GAC, true to its status as the voice of dinosaurs in the Internet ecosystem, wants to be given 5 seats on the CC-IANA. Apparently it is viewing the CC-IANA as a voting body, and believes that governments cannot be “represented” by other governments. But the purpose of the GAC seats on the CC-IANA is not to vote or to “represent” all diverse views, but to serve as a liaison to the governments. The CC-IANA is already overly-large, and tossing an additional 3 people on to it simply to assuage unintelligent political calculations should not happen. GAC’s demand should be rebuffed; or, at the very least, the CC-IANA should meet in its current form and deliberate on whether to add additional seats for governments.

A very constructive session, moderated by technical community stalwarts Patrik Faltstrom and Jari Arkko, introduced the ICANN London meeting to the issues and problems that need to be addressed by the CC-IANA. Still, the idea that “the community decides” what happens is not an entirely satisfactory or workable understanding of the situation; the CC-IANA must take community input and assemble it into a package, a proposal, and decide when the proposal meets the demonstrated concerns of the three different communities. It then needs to transmit the proposal to the NTIA for approval. Unfortunately, there seems to be no clear understanding of that process at the moment.

The public comments on the IANA transition should have conveyed a clear message to ICANN that its board must not be in a position to vet, modify or approve the outcome of the CC-IANA process. ICANN’s board is an interested party in the outcome of the IANA transition. Its organizational self-interest leads it to prefer some kind of proposals over others. The idea that the ICANN board would be able to change or veto proposals that are broadly acceptable to the community as a whole contradicts the NTIA’s mandate that ICANN is to convene, not control, the process.

ICANN’s board does not seem to fully understand this. This is clear from the transcript of a meeting between the board and the NCSG, in which I asked board chair Steve Crocker about the role of the board.

MM: How do you understand the role of the board in reviewing, approving or ratifying the results of this coordinating committee?

SC: the coordinating committee doesn’t have results, the community has results. The last version of this I read says we get the report from the group and we post it, and things proceed from there. The board will certainly have, inescapably, some obligations if there are structural changes or there are things that require board interaction. But generally we want this to be as broad and as open a process as possible.

MM: I guess I am more interested in the specific way in which the board or the cc transmits the final proposal to the NTIA and what is the role of the board. In other words, the CC, on behalf of the community, has a proposal that everyone accepts. What do they do with it? Do they give it to you, or do they give it directly to NTIA?

SC: My recollection is, what the document that I read says, it gets posted for discussion, and then things go, uh, — I am not sure what the next step is. It’ll be a pretty public process so I think the details of how it gets transmitted and so forth are less meaningful than you’re suggesting, but maybe I am not understanding the import of your question exactly.

MM: Let’s suppose it’s posted, the proposal is posted, you get some positive comments you get some negative comments. Do you [the board] then decide, well, we’re going to eliminate those things there were negative comments about and then send it to NTIA, or does NTIA just look at the comments and say, this is an acceptable proposal or not?

SC: You know, I think this really puts focus on the wrong things. The key issue is, is there a competent proposal, one that can actually work and deals with whatever the issues are. So to put it in categorical terms do we take anything that comes out of this process and we send it or we don’t, whatever, kinda is at the wrong level of discussion, the challenge is a sensible and workable system….to try to give a categorical answer to how we will treat things, it depends on what comes out.

MM: Who decides whether it is workable or not workable?

SC: Well, among other things, the people who have to work it. You’ve got a process, a set of customers for the IANA functions, you have the IANA team that processes transactions, you have the outputs of that…..all of that has to continue to work, otherwise we do enormous damage, and I am not sure what else is thought to be necessary

MM: So it sounds like the board qua board really has no role in vetting or approving the final proposal.

SC: Gee, I just really am not going to say that.

Clearly, Crocker is still a bit unclear about how he thinks the board should relate to the output of the CC-IANA. But now that the issue has been raised, it should be resolved soon.