Ensuring Continuity of the IANA Registries

The current system has been working for more than three decades, and the IETF transition plan is actually a continuation of existing practices that evolved over the years; it does not involve any untested practices.

The audience for the IANA protocol parameter services are the developers for software that runs on the Internet. ICANN makes the actual allocations and maintain a public database of all allocations. There are thousands of requests for protocol parameters each year. The IETF sets the policies for the IANA protocol parameter registries, and the allocations are handled according to the policy for that registry– professionally and promptly. Should any problems develop, they are addressed first by the staff and volunteers working on the topic, then by the Internet Engineering Steering Group (IESG). If all else fails, the Internet Architecture Board (IAB) in its oversight role will decide what needs to be done. This structure provides defenses against many organizational failures.

But how do we deal with possible future events that might affect that stability? For the sake of argument, let’s assume that ICANN for some reason failed to operate the services properly, or that the organization would be brought under the control of some rogue actors that do not respect the multistakeholder way of working.

Note: ICANN provides excellent IANA services, and we find the above scenario very far fatched. Nevertheless, being prepared for all situations is good.

As with any problem, the IETF would attempt to resolve issues with IANA staff, including escalation of the issues to management and beyond, before selecting a different party to provide IANA protocol parameter registration services. As the IETF transition plan says:

"Obviously such action would only be undertaken after serious consideration."

We would do this first at the level of our normal operations. If that does not help, the “serious consideration” involves going through the steps of talking with the ICANN board, and the global community of Internet technology developers, researchers, and vendors.

But ultimately, given this worst-case scenario, the IETF maintains the authority to select the provider for IANA protocol parameter services. This is how the agreement from 2000 is set up. This ultimate accountability tool ensures that no matter how bad things become, the IETF can still get the IANA protocol parameter services for the global Internet community.

Bad things happening for the bookkeeping function should not be the only concern. Another question is whether the policy processes could come under pressure, and fail. In the case of the IETF, we have almost thirty years of history that shows we can deal with the problems that arise. During those thirty years we have also developed mechanisms to come to conclusions in an open and transparent manner, deal with the selection of leadership, and handle various contingencies. For instance, we have a well-defined and tested appeals process described in Section 6.5 of RFC 2026.

The IETF also has a leadership selection process that defends against any attempt of individual organizations to exert undue influence and ensures that rogue members can be recalled through community action. These processes are described in RFC 3777.

Together, these things provide a sound basis for continuity of protocol parameter services, even in the face of dangers from failed organizations, rogue actors, and other events outside the control of the multistakeholder community.