The Internet Architecture Board (IAB) released an important document this month. It deserves more attention than it is getting because its message bears directly on the IANA transition. The document, “Principles for the Operation of the Internet Assigned Numbers Authority (IANA) Registries,” has entered the IETF record as RFC 7500.
RFC 7500 has some important things to contribute to the transition discussion – but it is also notable for what it doesn’t say.
What does it say? The document reminds us that what we call “IANA” is fundamentally a collection of registries; nothing more, nothing less.
Internet registries are critical to the operation of the Internet, because they provide a definitive record of the value and meaning of identifiers that protocols use when communicating with each other. Almost every Internet protocol makes use of registries in some form. At the time of writing, the IANA maintains more than two thousand protocol parameter registries.
It then goes on to provide a set of governance principles that are essential for the “successful functioning of the IANA registries” and provide a “foundation for trust in those registries.” The principles are relatively simple:
- Ensure Uniqueness: The same protocol identifier must not be used for more than one purpose.
- Stable: Protocol identifier assignment must be lasting.
- Predictable: The process for making assignments must not include unexpected steps
- Public: The protocol identifiers must be made available in well-known locations in a manner that makes them freely available to everyone.
- Open: The process that sets the policy for protocol identifier assignment and registration must be open to all interested parties.
- Transparent: The protocol registries and their associated policies should be developed in a transparent manner.
- Accountable: Registry policy development and registry operations need to be accountable to the affected community.
The IAB doesn’t call these governance principles, but that is what most of them are, especially the last three (open, transparent, accountable).
In its discussion of openness and transparency, the IAB endorses clear separation between the registry operator and the policy maker:
When a registry is established, a policy is set for the addition of new entries and the updating of existing entries. …[T]he registry operator not being involved in establishing registry policy avoids the risks associated with (perceptions of) favoritism and unfairness.
The document then goes on to describe what it considers to be appropriate accountability arrangements for registry operators. Among other things, it says that “The process that sets the policy for IANA registries and the operation of the registries must be accountable to the parties that rely on the protocol identifiers. Oversight is needed to ensure these are properly serving the affected community.”
Examples are then provided. RFC 7500 provides a brief, paragraph-length description of the accountability arrangements for protocol parameters, and then for Internet numbers, showing how they reflect the relevant accountability principles.
Then the descriptions end.
What’s missing? Obviously, names (DNS). The domain name system root – one of the most consequential and well-known of the IANA registries – is conspicuous by its absence in RFC 7500. Why? Because the IAB seems to have had a hard time fitting the current arrangements for ICANN and the domain name system into its recommended principles.
It’s clear that for protocols, the oversight authority is the IETF’s IAB; for numbers, it is the RIRs. The IETF maintains a Memorandum of Understanding and an SLA with ICANN, which runs the protocols registry, and those contractual relations keep the performance of the protocol-related IANA functions accountable. The RIRs will have a similar contractual relationship and SLA with IANA to run the numbers-related registry, which will also keep its registry operator accountable.
But who is the oversight authority for the names root registry? It can’t be ICANN, because ICANN is the same entity that operates the DNS root registry, and ICANN cannot properly oversee itself. In ICANN, there is no clear distinction between the policy maker and the entity that enters those changes in the public registry. Furthermore, ICANN’s accountability relationships to the directly affected community (domain name registrants, registrars and registries) are deeply muddled. ICANN’s board and board selection process involves not just the names community, but the numbers and protocols communities as well, and ICANN’s board is both the entity that makes policy decisions for names and the authority for recognizing the Address Supporting Organization.
It’s likely that when drafting RFC 7500, the IAB started trying to wrap its mind around how ICANN and the names registry fit into their normative model, and just couldn’t make the fit. The fact is, the names registry doesn’t conform to the IAB principles. And while it didn’t come out and say so directly, its silence on the topic speaks volumes. Tacitly, the IAB has made it clear that the lodging of IANA functions inside a massive organization devoted to policy making for domain names is a major design flaw in current Internet governance arrangements.
The IANA stewardship transition offers us a chance to fix that design flaw. We need to legally separate the IANA functions operator from ICANN the policy making entity; we need to have a severable, contractual relationship between ICANN and the names-related IANA functions. It now appears that the CWG is headed in that direction, but it’s important to understand the basic principles behind why that should be done.