As we have detailed elsewhere, in developing an IANA transition proposal the names community working group (CWG) settled into two camps, the internalists and the externalists. A brief recap:
The “externalists” proposed a model which largely reflected the current arrangement between NTIA and ICANN. It proposed replacing the NTIA with a shell Contract Co. that received instructions from a multi-stakeholder Periodic Review Team to enter into a contract with the IANA functions operator, presumed initially to be ICANN. In some ways, this arrangement mirrors those proposed by the numbering and protocols communities. Each community would have a contract with the IANA functions operator. If the operator failed to perform, the respective registries could ultimately be taken elsewhere.
The mere possibility of ICANN losing control of the IANA functions caused NTIA, ICANN, and its sympathizers to push an alternative. The “internalists” proposed to house the IANA functions within ICANN permanently, relying on reforms being developed by the CCWG on accountability to provide checks on the ICANN board and to detail a “nuclear option” to remove the IANA functions if needed.
A new model
Recently, a third model emerged, one that seeks to reconcile the positions of the two camps. The integrated post transition IANA model was proposed by Avri Doria, Matthew Shears and myself. The proposal sought to create parity between all of the policy making communities (ICANN for names, the RIRs for numbers, and IETF for protocol parameters) with regard to the IANA functions operator. It did so by proposing a Post-Transition IANA (PTI) that would be comprised of ICANN’s existing IANA department, overseen by a small community board representing the the three policy authorities (ICANN, the RIRs and the IETF) equally. The community board selection mechanism(s) would be left to the respective authorities to develop. This would ensure that each community had a clear understanding of the power delegated to their community board representatives. The formation of direct Customer Standing Committees to develop and monitor SLAs would also be left to the respective authorities. Our model offered three variants with differing levels of separation from ICANN, ranging from an IANA subsidiary wholly-owned by ICANN, to an IANA shared services arrangement, to a free standing, independent IANA.
Why should the IANA functions be separated?
While countless hours have been spent debating the IANA transition, there has yet to be any rigorous academic analysis of the proposed solutions. A natural starting point is network economics. The idea of separating vertically integrated firms or markets in telecommunications in order to achieve social benefits is not new. There is a long history of doing so, from separating terminal equipment from network access or separating local from long distance service to facilitate competition in the voice telecom market in the 1980s, to the creation of a registry/registrar split in the domain name market in the late 1990s.
The primary reason for separation is to prevent a vertically integrated incumbent from engaging in non-price discrimination. The economic question at hand is:
If ICANN is vertically integrated with the IANA functions for names, numbers, and protocols, can it discriminate against policy authorities or registries?
In the near term, there is low risk of discrimination against the RIRs or IETF for a couple reasons. Foremost, the RIRs and IETF already have a contractual relationship with ICANN to provide the IANA functions. If they are subject to discriminatory actions by ICANN’s IANA, they can move their registries if needed. Furthermore, the names, numbers and protocol registries being maintained are largely distinct. Nonetheless, the policy interests of ICANN, IETF, and RIRs might not always perfectly align. For example, regarding reserved names, where no clear policy development process exists. Another example might be alternative policy authorities or systems.
Take for instance, the proposal for p2p naming systems in the IETF. In some cases, the systems using these names are entirely distinct from the DNS. In others, they might have some interaction with the DNS. Its authors request that the IANA reserve the following entries in the Special-Use Domain Names registry [RFC6761]:
If this Internet-Draft were to be approved as an RFC, we assume the IANA would comply (it is under contract to do so). But what if a new naming system wants to introduce 100s of new entries that potentially could also be new gTLDs in the DNS? What if these systems are perceived as a threat to various interest groups active within ICANN? How might a vertically integrated ICANN subject to these influences react? Would it embrace this potential complementary or substitute system, and support their registries?
The problem is no one knows for sure. Moreover, we simply don’t know what future innovations may occur that could impact the IANA functions.
Because of this it makes sense to have strong separation of the IANA functions prior to transition. But what exactly is strong separation in this context? Separation is viewed as a continuum. As Crandall, Eisenach & Litan (2010) describe:
The terms “accounting,” “operational,” “functional,” and “structural” typically are used to describe different types of separation mandates. At the extremes-accounting separation and structural separation-the terms are relatively unambiguous. Under accounting separation, the vertically integrated firm is required to follow specified accounting conventions for allocating the costs and revenues of upstream and downstream services into separate baskets, thus allowing regulators to set wholesale prices for the upstream service; however, the firm continues to operate as a vertically integrated whole, thereby preventing the loss of vertical efficiencies. Under full structural separation, on the other hand, the upstream and downstream portions of the firm are literally divided into separate companies with different ownership, management, etc. Under structural separation, all vertical efficiencies that depend upon joint ownership and control are eliminated.
Between the two extremes, there is a wide variety of options, typically categorized as “operational” or “functional” separation. In general, operational separation refers to the creation of a separate division within the firm whose mission is to service wholesale customers, while the firm’s retail operations are essentially unaffected-i.e., they continue to operate as an integrated part of the firm. Under functional separation, on the other hand, the firm’s retail operations are to one degree or another set apart legally, organizationally, and/or physically-from its upstream network operations. The greater the separation, the greater the independence between the network and retail operations and, at least in theory, the less incentive the network operator has to discriminate in favor of its affiliated retail arm. By the same token, of course, increased separation reduces the ability to capture vertical economies.
Examining the new model more closely
This description provides a useful scheme for viewing proposed models. Figure 1 places the various integrated PTI models identified above according to their strength of separation.
|← weaker ———————————————– stronger →|
Even though ICANN has operated the IANA functions for almost two decades, it still does not even maintain the weakest form of separation (i.e., accounting). What does it actually cost to operate the IANA functions? Having this information is critical to understanding the extent of vertical economies that exist and the feasibility of any separability solutions available. The CWG has been united in calling for this information, it is past time for ICANN to produce it. With this information we can explore related questions. What is the most equitable way of allocating costs? Can the IANA functions be supported by donations, or does it need a more robust funding mechanism?
A separate subsidiary IANA, wholly-owned by ICANN, is a model most consistent with the existing RIR and IETF proposals. More specifically, it would allow their transition proposals to proceed unmodified – ICANN could remain the MoU(s) counterparty. However, we have heard many times the need to get the transition right. The ICANN board would ultimately control the subsidiary, leaving the IANA vulnerable to that pressure. The work of the CCWG on ICANN accountability at best would have only a slight impact on this, because it is really focused on making ICANN’s policy making process accountable and is incapable of focusing specifically on IANA relationships. Moreover, it is possible that those reforms fail to adequately delineate between ICANN policy making and IANA implementation activities, particularly with regard to names. In any operational separation, the devil will be in the details. Paraphrasing Crandall, et al.: Who is to report to whom? Who is permitted to talk with whom, and about what topics? What systems can be shared, and which ones must be duplicated? And, perhaps most important, who is compensated for what; that is, to what extent are the operators of IANA and ICANN incentivized to maximize the performance of their own organizations versus the performance of ICANN as a whole?
The strongest form of separation, and least subject to influence by the policy authorities, would be a free standing IANA operator. However, this could be viewed as an existential threat to the I* organizations, or as politically untenable. A more palatable solution would be an IANA shared services arrangement, with a legally and operationally distinct IANA comprised of the current IANA department from ICANN, and overseen by all three policy authorities (ICANN, RIRs, IETF) through a Community Board. Each policy authority could maintain a contract (MoU) with the PTI, covering SLAs developed and monitored by direct Customer Standing Committees. Ultimately, the policy authorities could take the registries they govern elsewhere if needed, but they would have a strong incentive to keep them together in the Post-Transition IANA. Any concerns over creating a new entity, for example those expressed by Asst Sect Strickling in his exchange with Sen. Thune during recent testimony, would be negated by 1) utilizing the existing IANA department and processes which have shown to be secure, stable and resilient, and 2) having a Community Board which is directly accountable to the policy authorities (i.e., ICANN, RIRs, IETF). Strickling’s argument that it is destabilizing to allow the policy communities to directly govern a structurally separated IANA turns into nonsense under the shared services arrangement. All three policy communities are unlikely to make any precipitous moves to move the IANA functions to another operator. And if they all agree to move, who is NTIA to suggest that they should not?
The shared services arrangement approach achieves several social benefits. First, it maintains portability of registries for the numbers, protocols and names communities if needed. Second, in rare cases where names, numbers and protocol community policies may intersect or conflict, it provides a distinct organization and set of processes to deal with them. Finally, by creating parity between the policy authorities and IANA functions operator, it removes the ability of any of the extant policy authorities to engage in discrimination absent collusion, thereby supporting continued innovation in global identifiers and communications systems.
To date, no economic rationale for allowing ICANN to internalize operation of the IANA functions has been provided. If the IANA functions are to remain vertically integrated with ICANN, then the names community should demand the externalist solution. The DNS root registry, along with other number and protocol registries, should remain portable. The risk with this approach is that ICANN could exercise discriminatory practices toward extant policy authorities or competing identifier systems or registries. A better solution would be to settle on a model that provides strong vertical separation of the IANA functions operator from ICANN, as proposed in the IANA shared services arrangement.