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

    1984

    • Jari ArkkoIETF Chair

    25 Sep 2015

    One of the things that can make surveillance too easy is when the technology we use has weaknesses.

    strong lock

    Not what you think! This blog post is not about the novel by George Orwell. Although the topic is related, as all-encompassing surveillance is a big question both in the novel and in today’s Internet communications. One of the things that can make surveillance too easy is when the technology we use has weaknesses.

    The IETF recently approved RFC 1984 to the status of “Best Current Pratice”, or a document that has the strength of a recommendation for the broader Internet community. This document discusses the need for strong, cryptographic protection of communications, and makes a case that limiting access to these tools will weaken everybody’s security in the Internet. The RFC was relevant in 1996 when it was first published and still is today; the principles described in RFC 1984 have held up well in the nearly two decades. 

    For both symbolic reasons and to better ensure that IETF specifications reflect the spirit of RFC 1984, the IETF participants wanted to recognize the substantive content of RFC 1984 as a BCP.

    The Security Area of the IETF had rough consensus to change the status of RFC 1984 to BCP in-place. The possibility of revising the text of RFC 1984 was discussed, but rejected because a) the current text is still fine, b) any changes we’d likely make now wouldn’t improve it significantly, c) affirming the continuity of the IETF’s position is valuable and even d) keeping the RFC number is worthwhile. Thus, though this update is exceptional, this in-place status change is overall considered reasonable and beneficial.

    Picture credits Wikimedia and Jari Arkko


    Share this page