IGP The last third: Why the IANA transition for names is hard
It is asserted that ICANN was “purpose-built” to operate the IANA functions. This is only partly true. ICANN’s original design, in which the IANA functions were a central aspect, was abandoned very quickly between 1999 and 2002. ICANN‘s first bylaws tried to create three Supporting Organizations, one for domains (DNSO), one for addresses (ASO) and one for protocols (PSO). The intention was that these SOs would be the interface between ICANN’s Board and the relevant policy development communities.
But that model didn’t work. The communities that already had policy development organizations that predated ICANN’s creation (IP addressing and Protocol parameters) never folded their operations into ICANN as envisaged. Indeed, the idea that policies related to Internet protocols would be developed in ICANN was dead on arrival. IETF opted almost completely out of the ICANN regime, and the PSO disbanded. The RIRs distanced themselves from ICANN, didn’t sign an MoU with it until 2004, and made the ASO into a vestigial entity used only for global policies.
But for domain names, no pre-existing, independent policy making institutions existed. So domain name policy stayed inside ICANN. And as it turned out, domain name policy making and contracting ballooned into a gigantic set of entities and processes, now generating and consuming over 100 million dollars each year. The ccTLDs refused to sign contracts with ICANN and the old DNSO split into two SO’s the GNSO and the ccNSO. The GAC became larger and more powerful. ALAC was created.
As this happened, the IANA functions became a tiny and not very central part of what ICANN did. Whatever the original “purpose” behind how ICANN was “built,” it would be more accurate to say that ICANN’s evolutionary trajectory selected for policy development for generic top level domain names over all other things. Yet the IANA functions for names, numbers and protocols is still nestled within this massive policy entity
This historical context partially explains the difficulty the names community is now facing in developing its IANA stewardship transition proposal. The numbers and protocol communities proposals use a contracting model for the IANA functions. They establish a clean and simple accountability relationship to the IANA functions operator (currently ICANN) by preserving the ability to take the registries elsewhere if service is not satisfactory. Given there are no policy development entities for names that are external to ICANN, who can do this for names? It would be nice to develop a symmetrical relationship across names, numbers and protocols. But how?
The original plan of the CWG-Stewardship tried to solve this problem by creating a new external contracting entity. This small “Contract Co.” would take its direction from a Multi-stakeholder Review Team (MRT) and Customer Standing Committee (CSC) drawn from naming community stakeholders, including ICANN-based entities. The Contract Co model would enable a switch to a new provider if ICANN failed to perform the naming-related IANA functions properly. This model seems a bit odd, a kind of bolted-on solution, but the intent is good and it is better than an internal solution, which gives ICANN a permanent, unaccountable monopoly on the IANA functions and blurs the distinction between policy and implementation.
As noted in Monday’s session on the transition, a much cleaner solution would be to structurally separate ICANN’s policy development entities from its IANA functions operator. Both would have their own board. The board of the policy making entity (let’s call it ICANN) would then contract with the separate entity (let’s call it New IANA) to perform the IANA functions for names, just like the protocols and addressing entities do. This symmetrical relationship would enable ICANN to contract with “New IANA” to operate the various registries. This arrangement would realize the principle of separability and guarantee accountability of the operator to the policy development entities. The new IANA could also provide some mechanism for oversight over all three of the operational communities.
This new model for the IANA transition can break the deadlock in the CWG. It avoids the creation of a new entity but establishes the structural separation and a contracting model, both of which are needed for accountability and good service.
