Cauldron part 2: Is the names IANA compatible with the others?

The previous blog post described the progress of the IANA transition in the IETF-led protocols space and the lack of progress in the numbers space. Feeling the pressure, the Numbers Resource Organization has since announced a more developed process for the numbers space.

The names part of the IANA transition is the outlier. A process is in place, but no one has any idea what it will produce or how the results will mesh with the proposals for protocols and numbers. Both the protocols and the numbers communities have arms-length and potentially sever-able relationships with ICANN. The names community on the other hand is a wholly owned subsidiary of ICANN, Inc., which both runs the policy process (some would say that its staff and board play a major role shaping what the policy is) and the IANA functions that implement the policies in the root zone. The NTIA IANA functions contract is the only thing that requires separation between the policy making apparatus of ICANN and the IANA implementation – and the NTIA is going away. Add to that the fact that the domain name market is where most of the money and politics of Internet governance are concentrated, and thus attracts the most attention from governments.

While the IETF and numbers people seem to be pretty happy with the services they are getting from ICANN’s IANA, most of the stakeholders in the names space are mistrustful of ICANN; they believe that its powers need to be limited and its board made more accountable to the community. The names environment is complicated further by the distinction between generic top level domain registries (gTLDs) and country code top level domains (ccTLDs). gTLDs such as .com and .org are based on elaborate contracts with ICANN. As the entity that “licenses” them to run a top level domain, ICANN can impose expensive and burdensome obligations on gTLD registries with its contracts and policies, and ICANN also extracts substantial fees from them.

Hardly any of the ccTLDs, on the other hand, have contracts with ICANN. They merely rely on it to update their data in the global root zone. The ccTLDs’ main worry is about how ICANN handles redelegation requests – i.e., requests to transfer control of the country code domain from one party to another. Currently, it is the IANA that receives and processes these requests. In redelegation requests, the line btween policy making and implementation can get a bit blurry, as the IANA must decide, in effect, whether a request to shift control of the country domain is justified. To the ccTLD registries ICANN is only a latent threat, but a serious threat nonetheless. ccTLDs want to make sure that the transition does not give ICANN any more centralized power over them; they will probably be seeking institutionalized safeguards regarding redelegations and other things affecting their autonomy.

Thus while they are different in so many other ways, both ccTLDs and gTLDs see the accountability of ICANN’s policy process as a life or death issue. They do not see ICANN as a largely innocuous home of a highly technical and usually well-run coordination service. The names community not only wants to make sure that the transition results in an accountable, efficient and secure IANA, it also wants to use the IANA transition as a point of leverage to get major reforms in the California corporation’s governance structure. As a result, the names community has not only convened a process to develop a proposal in response to the NTIA’s call for a stewarship transition (The Cross-Community Working Group on the IANA transition or CWG-IANA) it has also set up a separate process to come up with proposals for improving ICANN’s accountability and reforming its governance (the ICANN Enhanced Accountability and Governance group). It has then broken down the work of the Enhanced Accountability and Governance group into two tracks: track 1 concentrating on accountability reforms that must be made before the IANA transition, and track 2 referring to reforms that can wait until after the transition.

These different requirements make it likely that the IANA functions will split, with names separated from the protocol and numbers functions. The possibility was made clear by InternetNZ’s Jordan Carter, who stated on the Onenet list:

If we are going to have a successful transition, it’s really important for the numbers and protocols folks to understand that: a) they have superior accountability situations to the names people today; b) the names people cannot copy number/protocol accountability mechanisms because they aren’t organised outside ICANN; c) it isn’t possible for names to organise outside ICANN in the way numbers/protocol people do; d) there may need to be structural changes or new bodies to provide a workable settlement for names; e) without a workable settlement for names, there isn’t going to be a transition.

While Carter is right that a transition that satisfies the protocols community will do little or nothing to fix the problems faced by the names communities; it is also true that the reforms called for by the names community could have huge side effects on the environment in which the protocols-related IANA functions operate.

Responding to Carter from the perspective of the technical community, Daniel Karrenberg, one of the founders of the European numbers registry RIPE-NCC, said:

What incentive would there be [for the protocols and numbers people] to agree to additional mechanisms designed specifically to address names’ issues? What if these are perceived to add unnecessary complications for the working mechanisms in the protocols/numbers area? Would it surprise you if a perception arose in the protocols/numbers communities that they are being ‘held hostage’ by the names communities?

Here are a couple of (not impossible) scenarios that illustrate the problem.

Suppose that in the future ICANN/IANA take over the Root Zone Maintenance Function as well as the current IANA functions. But suppose its operations fail to live up to current reliability standards, leading to major dissatisfaction in the names community. But suppose that the IETF is perfectly happy with ICANN’s performance of the protocl registry IANA functions. The names peple want a new IANA, the IETF people don’t. Who wins?

Here is a wilder (but again, not impossible) scenario. Suppose that, in order to control domain name policies and to capture more of the ample revenues the industry generates, the GAC succeeds in taking control of ICANN from within. ICANN’s policy process becomes, for all practical purposes, an intergovernmental or multilateral one. It then leverages its control of IANA to put pressure on IETF to become part of the ITU. Obviously, IETF would seek to move its protocol registry away from ICANN at that point – but suppose ICANN resists this, refusing to yield the IANA.org domain name and the IANA trademark that it currently holds. Who is really the IANA at that point?

Trying to keep them all together in the same organization as ICANN’s policy process may be a threat to the stability of the former (protocols) and a nettlesome constraint on the solution set of the latter (names).

To conclude, the twin assumptions that 1) the IANA functions operator must be a single entity combining names, protocols and numbers, and 2) that the single entity should be inside a corporation that is responsible for policy making for domain names not only has practical problems – it poses major risks to the future autonomy of the internet.

Although it has helped to uncover these dilemmas, the ICG process of allowing each community to develop its own IANA transition proposal actually minimizes these dilemmas. If all of these communities were thrown into the same cauldron to work out their desired transition plan, the temperature would surely rise even higher and the conflicts would be even more intense.