Skip to main content
  • First annual IETF community survey

    The IETF is launching its first annual IETF community survey.

    • Jay DaleyIETF Executive Director
    6 May 2021
  • Deadline Extended for Applied Networking Research Workshop Paper Submissions

    The deadline for submitting papers for consideration for the ACM/IRTF Applied Networking Research Workshop 2021 (ANRW’21) has been extended to 5 May 2021.

    • Nick FeamsterANRW Program co-chair
    • Andra Elena LutuANRW Program co-chair
    20 Apr 2021
  • Proposed Process to Conduct Assessment Activity of IETF Administrative Support Activity

    After three years of operation, the IETF Administration LLC (IETF LLC) is preparing to conduct a complete assessment of the structure, processes, and operation of the IETF Administrative Support Activity (IASA 2.0) and the IETF LLC. Before beginning this work, we are soliciting community feedback on the proposed timeline and process we will use to conduct the retrospective.

    • Jason LivingoodIETF Administration LLC Board Chair
    12 Apr 2021
  • IETF Annual Report 2020

    The IETF Annual Report 2020 provides a summary of Internet Engineering Task Force (IETF), Internet Architecture Board (IAB), Internet Research Task Force (IRTF), and RFC Editor community activities from last year.

    • Jason LivingoodIETF Administration LLC Board Chair
    • Lars EggertIETF Chair
    6 Apr 2021
  • IETF 110 Hackathon: The fruit of our labor

    I use the Internet almost every day. If you are reading this, you probably do too. The Internet provides access to information and to each other in ways that are ingrained in our daily routines and on which we rely for both work and play.

    • Charles EckelIETF Hackathon Co-chair
    2 Apr 2021

Filter by topic and date

Filter by topic and date

Ensuring Continuity of the IANA Registries

  • Jari ArkkoIETF Chair
  • Russ HousleyIAB Chair

22 Feb 2015

One question that often comes up regarding the IANA Stewardship transition is how to ensure that the IANA protocol parameter registries continue to serve the worldwide Internet community.

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.


Share this page