Skip to main content
  • IETF Administration LLC 2026 Budget

    A draft budget was shared previously for community consultation and the IETF Administration LLC now has finalised its budget for 2026.

    28 Jan 2026
  • Agentic AI communications: Identifying the standards we need

    When it comes to standards work around agentic AI, we’re at an exciting threshold. As more tools emerge, we’re seeing the amazing things it can accomplish. Now, we’re trying to figure out what parts of it need to be standardized.

    22 Jan 2026
  • IETF@40

    Forty years ago today, 21 people gathered in San Diego, California for the first meeting of what became the Internet Engineering Task Force.

    16 Jan 2026
  • Launch of the IETF Community Survey 2025

    The IETF Community survey is our major annual survey of the whole of the IETF community and is used to inform the actions of IETF leadership throughout the year. The 2025 IETF Community Survey is live and we want to hear from you!

    23 Dec 2025
  • IETF Administration LLC 2026 Draft Budget

    The IETF Administration LLC has prepared its draft budget for 2026 and now seeks community feedback.

    19 Dec 2025

Filter by topic and date

Filter by topic and date

1984

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