Skip to main content
  • IETF 118 post-meeting survey

    IETF 118 Prague was held 4-10 November 2023 and the results of the post-meeting survey are now available on a web-based interactive dashboard.

    • Jay DaleyIETF Executive Director
    30 Nov 2023
  • Net zero update for 2023

    An update on the IETF’s carbon footprint over the past year and efforts going forward to increase the sustainability of how the IETF operates.

    • Greg WoodIETF LLC Director of Communications and Operations
    • Stephanie McCammonDirector of Meetings and Sponsorships, IETF Secretariat
    29 Nov 2023
  • IETF 118 Highlights

    The IETF 118 meeting was held in Prague in early November. In general, the meeting was productive and full of lively discussions fueled by 1067 onsite participants, and 1806 participants altogether.

    • Christopher A. WoodIAB Member
    28 Nov 2023
  • Cisco to host IETF 121 Dublin meeting

    I am pleased to announce that Cisco will be the Host for IETF 121 Dublin, 2-8 November 2024.

    • Jay DaleyIETF Executive Director
    6 Nov 2023
  • Suggested IETF 118 Sessions for Getting Familiar with New Topics

    These IETF 118 meeting sessions included discussions and proposals that are accessible to a broad range of Internet technologists whether they are new to the IETF or long-time participants.

      4 Nov 2023

    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