Skip to main content
  • QUIC working group looks to bring more security to Internet traffic

    Lucas Pardue serves as co-chair of the IETF QUIC Working Group, which focuses on a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol. The IETF blog recently asked Pardue about the QUIC standards project.

    • Grant GrossIETF Blog Reporter
    14 Jun 2021
  • Q&A with our new Director of Development

    Lee-Berkeley Shaw joins the IETF Administration LLC today as Director of Development. She will focus on designing and delivering the strategy to achieve the IETF’s goals for financial sustainability, with a focus on growing the IETF Endowment. We asked her questions about her plans for the IETF and her background.

    • Grant GrossIETF Blog Reporter
    7 Jun 2021
  • A new era in Internet transport

    The IETF’s Transport and Services (TSV) area is developing several potentially transformative technologies while it continues to maintain many of the foundational protocols of the Internet.

    • Martin DukeTransport Area Director
    • Zaheduzzaman SarkerTransport Area Director
    • Magnus Westerlund
    3 Jun 2021
  • Innovative New Technology for Sending Data Over the Internet Published as Open Standard

    Already broadly deployed and used, QUIC provides lower delay, improved security, and more robust delivery of data.

      3 Jun 2021
    • QUIC in the Internet industry

      QUIC, a new Internet transport technology that improves web application performance, security and privacy, was reviewed, redesigned and improved in the IETF, incorporating a broad range of input from across the industry.

        3 Jun 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