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.

9 thoughts on “The last third: Why the IANA transition for names is hard

  1. Did you really mean to write: “The new IANA could also provide some mechanism for oversight over all three of the operational communities.”? Otherwise, it makes good sense!

    1. If anything, NEWIANA could simply verify that the relevant policy development authority followed its policy development process.

  2. Interesting article (as usual…) One small comment –
    “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.”
    would imply that folding into ICANN was actually part of the blueprint, and it was not. The bylaws called plainly for independent organizations which would simply act as supporting organizations within ICANN for purposes of policy development. The RIRs use this model today for the development of the global policies (i.e. the ones IANA follows) and this is precisely per ICANN’s original blueprint.

    John Curran
    President and CEO
    ARIN

    1. I note for purposes of accuracy – 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.
      This is actually incorrect as well, as the RIR were part of ICANN’s formation (signing an MoU with ICANN in October 1999) and as well as being the first party to pledge financial support to ICANN for its fledgling operations.

      FYI,
      John Curran
      President and CEO
      ARIN

      1. Thanks for the info, the 1999 MoU is here. The important point is the substantially revised 2004 MoU provided a detailed Process Description concerning global policy formation, thus clarifying the relationship between the RIRs and ICANN. It emphasized that the RIRs developed global policies, and added that ultimately the parties would go to mediation if necessary.

    2. I think the important point is how the relationship evolved over time, clarifying the prominence of RIRs w/r/t global policy making and diminishing the ASO and overall ICANN role. The opposite happened within the names community.

      1. The RIR/ICANN relationship recognizes and preserves ICANN’s important mission of promoting operational stability of the Internet via the global coordination of Internet identifiers. This model does not require that the respective communities develop policy within ICANN; in fact, ICANN’s initial bylaws specifically recognized that policy would be developed by primarily by independent supporting organizations. You suggest that ICANN’s role was somehow diminished with respect to protocol parameters and IP address policy, but this is not the case – ICANN’s role was never to include policy development in these areas but only to act as a coordination and oversight body.

        If an financially and organizationally independent DNSO had come into being in 1999, ICANN’s role would have remained focused on oversight and coordination, globally and across the Internet identifier communities, rather than evolving into the vertically integrated DNS colossus that exists today, and tour article does aptly characterize the challenges that result from trying to establishing accountability within a single organization rather than between organizations.

        John Curran
        President and CEO
        ARIN

        1. Fair enough on how we got here. We have a meeting of minds, regarding “the vertically integrated DNS colossus that exists today.” The problem is we can’t turn back the clock. IMO, given that ~95% of ICANN’s budget and community time goes to supporting names policy making activities, it makes little sense to create the equivalent to a “financially and organizationally independent DNSO” today. It is _far_ simpler to hive off the IANA department and budget into something financially and organizationally independent (i.e., vertically separate IANA from ICANN in economics speak) which serves and is directly accountable to the organizations responsible for policy (a new proposal for something like this was made recently to the CWG on IANA transition). This would let ICANN (and the CWG on accountability) focus on its strength, i.e. names policy making. It would be a much clearer path to accomplishing the transition, providing long term stability and social benefit.

Comments are closed.