WebBuilding

Organizations

IETF

Summary

The Internet Engineering Task Force (IETF) is the open, volunteer standards body that writes many of the internet's core technical protocols, including HTTP, TLS, DNS and QUIC, and publishes them as numbered RFCs. It held its first meeting, with 21 people, in San Diego on January 16 and 17, 1986. It has no membership, works by "rough consensus and running code," and since August 27, 2018 has had its legal home in the IETF Administration LLC, a subsidiary of the Internet Society.

Web Building Encyclopedia · Organizations · Last reviewed October 22, 2026 · 11 min read

What the IETF is

The Internet Engineering Task Force (IETF) is the group that writes many of the core technical rules the internet runs on. It calls itself the premier standards development organization for the Internet and dates its founding to 1986.1 Its mission statement, RFC 3935 of October 2004, states its goal simply: “to make the Internet work better.”2

The IETF has no membership. Anyone can take part by joining a working group’s mailing list, registering for a meeting or writing a proposal, and every participant counts as a volunteer, including people whose employers pay them to attend.1 More than 7,000 people take an active part in a given year.1

Most of the work happens in working groups, each with its own mailing list.1 As of October 22, 2026, the IETF Datatracker, its public tracking site, lists 135 active working groups spread across seven areas.3

The IETF also meets in person three times a year, for a week each time. Onsite attendance averages 1,000 to 1,500 people, with 600 or more joining remotely.1 The next meeting, IETF 127, is set for November 14 to 20, 2026, in San Francisco, and the published schedule assigns later meetings to Asia in March, Europe in July and North America in November.4

Its finished documents are called RFCs, a name that originally stood for Requests for Comments, and they are free to read. The only fee is for meeting registration, and the IETF offers ways for people who cannot pay to attend anyway.1 For the web, much of the IETF’s work is the plumbing: its own 30th-anniversary post names HTTP and TLS, which carry web traffic, among the protocols that became IETF standards.5

Origins: 21 people in San Diego

The IETF grew out of the advisory boards around the US government’s early internet research. In 1979 Vint Cerf, then a program manager at DARPA (the Defense Advanced Research Projects Agency), set up the Internet Configuration Control Board to advise him on technical questions, with David Clark of MIT as its chair.6

In September 1984 that board was replaced by the IAB, then called the Internet Advisory Board. Its members were the chairs of ten new task forces plus Jon Postel, the RFC editor.6 According to the IAB’s own history, the IETF formed in 1986 when the Gateway Algorithms and Data Structures (GADS) task force split in two, and Mike Corrigan became its first chair.6

The first meeting, now numbered IETF 1, took place on January 16 and 17, 1986, in San Diego, California. Twenty-one people attended.5 By the IETF’s 30th anniversary in 2016, regular meetings drew more than 1,000 people, about 50 times as many.5

The structure took shape over the next six years:

  • 1989. At the 14th IETF meeting at Stanford in July, the IAB’s task forces were folded into two groups, the IETF and the Internet Research Task Force (IRTF). That summer the Internet Engineering Steering Group (IESG) was established, with members appointed by the IAB.6
  • 1992. The Internet Society (ISOC) was formed in January, and the IAB proposed working under its umbrella. The same year the IAB was renamed the Internet Architecture Board, and the IESG and IETF took on a larger, independent role in approving standards.6
  • 1995. The IETF’s Poised95 working group concluded that ISOC was the best organization to handle the IETF’s legal, administrative and financial tasks, an arrangement written down in RFC 2031.7

The RFC series and its editors

The RFC series is older than the IETF.9 RFC 1, titled “Host Software,” was written by Steve Crocker at UCLA and is dated April 7, 1969, almost 17 years before the first IETF meeting. It discusses the software that host computers on the ARPA Network would need.85

The editors who have kept the series running are a short list:

  • Steve Crocker organized the early notes until he took leave from UCLA in June 1971 to work at ARPA.9
  • Jon Postel took over as the series’ editor in 1971 and kept the role until his death in October 1998.9
  • Joyce K. Reynolds, a fellow researcher at the University of Southern California’s Information Sciences Institute (ISI), and Bob Braden, a networking researcher at ISI, carried the work on after Postel. Braden retired from the RFC Editor in January 2010.9
  • Sandy Ginoza joined ISI shortly after Postel died. Production began moving from ISI to Association Management Solutions (AMS) in October 2009, and in 2010 AMS won the contracts to produce and publish RFCs, with Ginoza on the team.9
  • Olaf Kolkman served as acting RFC Series Editor, a role created in 2009 by RFC 5620, and handed it to Heather Flanagan in 2012.9

In June 2022, RFC 9280 set out version 3 of the RFC Editor Model. An open RFC Series Working Group proposes policies, an RFC Series Approval Board approves them, and the RFC Production Center, overseen by the IETF Administration LLC, edits and publishes the documents.11 Alexis Rossi, Director of Media and Access at the Internet Archive, was announced on September 1, 2022, as RFC Series Consulting Editor, an advisory role created under the new model.12 RFC 9920, published on February 11, 2026, replaced RFC 9280 with a revised version 3 that draws on the lessons of the years in between.13

Not every RFC comes from the IETF. The RFC Editor publishes documents from several streams: the IETF, the IAB, the IRTF and independent submissions,10 plus an Editorial Stream for RFC Series policy that RFC 9920 specifies.13 Because the IETF became the source of most documents, many people see the series as the IETF’s own.9

RFC 8700, written for the series’ 50th anniversary in December 2019, said more than 8,500 RFCs had been published.9 The numbers have since passed 10,000: as of October 22, 2026, the RFC Editor’s home page lists RFC 10065 among its newest documents.14

Rough consensus and running code

The IETF’s best-known motto comes from a plenary talk David Clark gave at IETF 24 in July 1992: “We reject: kings, presidents and voting. We believe in: rough consensus and running code.”15

Rough consensus does not mean everyone agrees. A working group chair can declare it once the chair judges that each technical objection has been truly considered by the group and either answered or found not serious enough to stop the work.15 RFC 7282, written by Pete Resnick in June 2014, says what counts is whether an open issue remains, not how many people are on each side.15

At meetings, chairs sometimes ask people to hum instead of raising hands, to get a sense of the room without a formal count. RFC 7282 says plainly that hums should not be used as votes.15

Running code means real software and real deployment. RFC 3935 lists “rough consensus and running code” among the IETF’s core principles, next to an open process, technical competence and a volunteer core.2

Working groups, BoFs and Internet-Drafts

The rules for working groups are in RFC 2418, published in September 1998 as BCP 25.16 Each group has a charter, worked out between its chairs and an Area Director and approved by the IESG, that sets out its goals and dated milestones.16 Every group must have a mailing list with a public archive, and decisions taken in a meeting room have to be confirmed on the list.16

New work often starts at a BoF, short for “birds of a feather,” a session held to test interest in a topic. An Area Director must approve each BoF, and it is usually held only once.16 Working groups normally close when their tasks are done.16

Proposals are written as Internet-Drafts, working documents with no formal status. Under RFC 2026, a draft that sits unchanged for more than six months without a recommendation to publish is removed from the drafts directory.17

Who runs it: the IESG, IAB, ISOC and the IETF LLC

Four bodies share the job of running the IETF, each with a different role.

The IESG is responsible for the technical management of IETF activities and the standards process, and gives final approval to standards.18 It is made up of the Area Directors, who are picked by a Nominating Committee (NomCom) and serve two-year terms.18 As of October 22, 2026, the Datatracker lists 13 Area Directors, among them the IETF Chair, Roman Danyliw, plus two liaison members.19

The seven areas cover applications and real-time, general, internet, operations and management, routing, security, and web and internet transport.3 The newest, Web and Internet Transport (WIT), began work at IETF 119 in Brisbane in March 2024. It took over from the Transport Area and absorbed the web and real-time part of the Applications and Real-Time Area, and its groups include those for HTTP and QUIC.20

The IAB oversees the architecture of internet protocols, hears appeals about how the standards process was applied, and confirms or rejects candidates for the IESG.21 It also approves the organizations that serve as RFC Editor and as IANA (the Internet Assigned Numbers Authority) for the IETF. Its charter, RFC 2850 of May 2000, gives it 13 full members: the IETF Chair plus 12 others.21

The Internet Society is the organization the IAB advises: the charter makes the IAB both a committee of the IETF and an advisory body of ISOC, giving advice to its Board of Trustees and officers.21

The IETF Administration LLC was established on August 27, 2018, as a subsidiary of ISOC. It gives the IETF, IAB and IRTF a corporate legal home and handles the budget, contracts, fundraising, bank accounts and insurance, with the stated aim that ISOC and the LLC operate at arm’s length.7 RFC 8711, published in February 2020 as BCP 101, describes it as a disregarded limited liability company of ISOC and says ISOC provides significant financial support. The same document abolished the old IETF Administrative Oversight Committee.22

The LLC’s board has at least five directors: the IETF Chair or a delegate selected by the IESG, one appointed by ISOC’s Board of Trustees and three selected by the NomCom, with room for up to two more appointed by the board.22 The LLC is managed day to day by the IETF Executive Director, Jay Daley as of October 2026.23

How a standard moves forward

The rulebook is RFC 2026, “The Internet Standards Process, Revision 3,” written by Scott Bradner and published in October 1996 as BCP 9 (Best Current Practice 9).17 It set three levels of maturity on what it calls the standards track:17

  1. Proposed Standard, the entry level, reached by a decision of the IESG. A document had to stay here for at least six months.
  2. Draft Standard, which required at least two independent, interoperable implementations from different code bases and at least four months at that level.
  3. Internet Standard, which required significant implementation and operational experience, and brought an STD number in addition to the RFC number.

RFC 2026 also defined labels for documents off the standards track: Informational, Experimental and Historic, plus BCP for community practices and operating guidelines.17 Disputes in a working group go first to its chair, then to the Area Director, the IESG and finally the IAB. Questions about whether the procedures themselves are fair can go to the ISOC Board of Trustees, whose decision is final.17

In October 2011, RFC 6410 cut the track to two levels, Proposed Standard and Internet Standard. Draft Standard was merged into Internet Standard, in part because the name was easily confused with Internet-Draft.24 To reach Internet Standard, a document now needs at least two independent interoperating implementations, wide deployment and an IETF-wide Last Call, a final review period of at least four weeks.24

BCP 9 is now a bundle of eight RFCs, from RFC 2026 through RFC 9282, including RFC 8789, which says IETF stream documents require IETF rough consensus.25 In practice many protocols in daily use stay at Proposed Standard: QUIC (RFC 9000) and the current TLS 1.3 text (RFC 9846) are both Proposed Standards, while HTTP Semantics (RFC 9110) is a full Internet Standard, STD 97.283126

RFCs behind the web

A website depends on IETF work at almost every step, from looking up its address to encrypting the page. These are some of the RFCs involved.

SubjectRFCPublishedNotes
DNSRFC 1035November 1987By Paul Mockapetris; Internet Standard STD 1332
CookiesRFC 2109February 1997By David Kristol and Lou Montulli, from the HTTP working group; now Historic33
TLS 1.0RFC 2246January 1999From the TLS working group; now Historic29
CookiesRFC 6265April 2011By Adam Barth; replaced RFC 296534
TLS 1.3RFC 8446August 2018By Eric Rescorla; now obsoleted by RFC 984630
QUICRFC 9000May 2021From the QUIC working group28
HTTP semanticsRFC 9110June 2022From the httpbis working group; STD 9726
HTTP/3RFC 9114June 2022HTTP over QUIC, from the QUIC working group27
TLS 1.3, revisedRFC 9846July 2026Also obsoletes the TLS 1.2 text, RFC 524631

TLS, the encryption layer behind HTTPS, shows how the IETF revises a protocol. Each new version or clarification gets a new number, and the old RFC is marked as obsoleted: RFC 9846, by Eric Rescorla, obsoletes RFC 8446 and several older TLS documents, including RFC 5246.31

QUIC is a transport protocol that provides flow-controlled streams with fast connection setup, and HTTP/3 is the version of HTTP that runs on it.2827 Both came from the IETF’s QUIC working group.2827

Cookies are still being revised. As of October 2026, a replacement for RFC 6265 that defines the SameSite attribute, which limits when a browser attaches a cookie to a request, is in the RFC Editor’s queue for publication as a Proposed Standard, marked as awaiting final approval.35

Timeline

  1. RFC 9846 publishes a revised TLS 1.3 and obsoletes RFC 844631
  2. RFC 9920 revises the RFC Editor Model and obsoletes RFC 928013
  3. The Web and Internet Transport (WIT) Area begins work at IETF 119 in Brisbane20
  4. Alexis Rossi is announced as RFC Series Consulting Editor12
  5. RFC 9280 sets out version 3 of the RFC Editor Model11
  6. RFC 9110 (HTTP Semantics) and RFC 9114 (HTTP/3) are published26
  7. QUIC is published as RFC 900028
  8. The IETF Administration LLC is established as a subsidiary of ISOC7
  9. RFC 6410 reduces the standards track to two maturity levels24
  10. RFC 2026 sets out the Internet standards process as BCP 917
  11. The Internet Society is formed6
  12. The IAB's task forces are reorganized into the IETF and IRTF6
  13. RFC 1035 specifies the Domain Name System32
  14. The first IETF meeting opens in San Diego with 21 attendees5
  15. Steve Crocker writes RFC 1, "Host Software"8

What it means for your website

You will never need to attend an IETF meeting to run a website, but the rules your site follows come from RFCs. A few are worth knowing by number.

  • Encryption. The current TLS 1.3 text is RFC 9846 of July 2026.31 Ask your host whether its servers support TLS 1.3 and HTTP/3, RFC 9114.27 Our glossary explains SSL certificates, the files that let a site use TLS.
  • Email from your domain. SPF (RFC 7208) and DKIM (RFC 6376) are IETF standards that prove mail sent in your domain’s name is really yours.3839 DMARC, which tells receiving servers what to do when those checks fail, was revised in May 2026 as RFC 9989, which replaces RFC 7489 and RFC 9091.40 Our guide to websites and email covers the setup.
  • Cookies. Logins, shopping carts and consent banners use cookies defined in RFC 6265. Its replacement is in the RFC Editor’s queue as of October 2026.3435
  • Crawlers. Your robots.txt file follows the Robots Exclusion Protocol, published as RFC 9309 in September 2022.36 Our page on websites and AI search covers how it applies to AI crawlers.
  • A security contact. RFC 9116 defines security.txt, a file placed at /.well-known/security.txt and served over HTTPS. It must list a Contact and an Expires date.37
  • Check the date on advice. Each RFC’s page on the RFC Editor or Datatracker site shows whether a newer RFC has replaced it. RFC 8446, for example, is now marked obsoleted by RFC 9846.30

If a standard affects your business, you can follow the work or comment on it for free by joining the working group’s mailing list.1 For how these pieces fit together, see our guide to how a website works.

See also

References

  1. Introduction to the IETF. Internet Engineering Task Force. accessed October 22, 2026.
  2. RFC 3935: A Mission Statement for the IETF (BCP 95). Harald Tveit Alvestrand, RFC Editor. 2004-10. accessed October 22, 2026.
  3. Active IETF working groups. IETF Datatracker. accessed October 22, 2026.
  4. Upcoming IETF meetings. Internet Engineering Task Force. accessed October 22, 2026.
  5. 30 years of engineering the Internet. Jari Arkko, IETF Blog. 2016-01-13. accessed October 22, 2026.
  6. IAB history. Internet Architecture Board. accessed October 22, 2026.
  7. RFC 8712: The IETF-ISOC Relationship. G. Camarillo and J. Livingood, RFC Editor. 2020-02. accessed October 22, 2026.
  8. RFC 1: Host Software. Steve Crocker, RFC Editor. 1969-04-07. accessed October 22, 2026.
  9. RFC 8700: Fifty Years of RFCs. Heather Flanagan (editor), RFC Editor. 2019-12. accessed October 22, 2026.
  10. RFC 8729: The RFC Series and RFC Editor. R. Housley and L. Daigle (editors), RFC Editor. 2020-02. accessed October 22, 2026.
  11. Information on RFC 9280: RFC Editor Model (Version 3). RFC Editor. 2022-06. accessed October 22, 2026.
  12. Alexis Rossi appointed RFC Series Consulting Editor. IETF Blog. 2022-09-01. accessed October 22, 2026.
  13. Information on RFC 9920: RFC Editor Model (Version 3). RFC Editor. 2026-02-11. accessed October 22, 2026.
  14. RFC Editor home page (recent RFCs). RFC Editor. accessed October 22, 2026.
  15. RFC 7282: On Consensus and Humming in the IETF. Pete Resnick, RFC Editor. 2014-06. accessed October 22, 2026.
  16. RFC 2418: IETF Working Group Guidelines and Procedures (BCP 25). Scott Bradner (editor), RFC Editor. 1998-09. accessed October 22, 2026.
  17. RFC 2026: The Internet Standards Process, Revision 3 (BCP 9). Scott Bradner, RFC Editor. 1996-10. accessed October 22, 2026.
  18. Internet Engineering Steering Group (IESG). Internet Engineering Task Force. accessed October 22, 2026.
  19. Internet Engineering Steering Group: about and members. IETF Datatracker. accessed October 22, 2026.
  20. Introducing the Web and Internet Transport (WIT) Area. Zaheduzzaman Sarker and Francesca Palombini, IETF Blog. 2024-10-08. accessed October 22, 2026.
  21. RFC 2850: Charter of the Internet Architecture Board (BCP 39). Internet Architecture Board, RFC Editor. 2000-05. accessed October 22, 2026.
  22. RFC 8711: Structure of the IETF Administrative Support Activity, Version 2.0 (BCP 101). B. Haberman, J. Hall and J. Livingood, RFC Editor. 2020-02. accessed October 22, 2026.
  23. IETF Administration LLC. Internet Engineering Task Force. accessed October 22, 2026.
  24. RFC 6410: Reducing the Standards Track to Two Maturity Levels. R. Housley, D. Crocker and E. Burger, RFC Editor. 2011-10. accessed October 22, 2026.
  25. Information on BCP 9. RFC Editor. accessed October 22, 2026.
  26. RFC 9110: HTTP Semantics (STD 97). IETF Datatracker. 2022-06. accessed October 22, 2026.
  27. RFC 9114: HTTP/3. IETF Datatracker. 2022-06. accessed October 22, 2026.
  28. RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport. IETF Datatracker. 2021-05. accessed October 22, 2026.
  29. RFC 2246: The TLS Protocol Version 1.0. IETF Datatracker. 1999-01. accessed October 22, 2026.
  30. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. IETF Datatracker. 2018-08. accessed October 22, 2026.
  31. RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3. IETF Datatracker. 2026-07. accessed October 22, 2026.
  32. Information on RFC 1035: Domain names, implementation and specification (STD 13). RFC Editor. 1987-11. accessed October 22, 2026.
  33. RFC 2109: HTTP State Management Mechanism. IETF Datatracker. 1997-02. accessed October 22, 2026.
  34. Information on RFC 6265: HTTP State Management Mechanism. RFC Editor. 2011-04. accessed October 22, 2026.
  35. Cookies: HTTP State Management Mechanism (draft-ietf-httpbis-rfc6265bis). IETF Datatracker. 2025-12-01. accessed October 22, 2026.
  36. Information on RFC 9309: Robots Exclusion Protocol. RFC Editor. 2022-09. accessed October 22, 2026.
  37. Information on RFC 9116: A File Format to Aid in Security Vulnerability Disclosure. RFC Editor. 2022-04. accessed October 22, 2026.
  38. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. IETF Datatracker. 2014-04. accessed October 22, 2026.
  39. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. IETF Datatracker. 2011-09. accessed October 22, 2026.
  40. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC). IETF Datatracker. 2026-05. accessed October 22, 2026.

Web Building Encyclopedia. First published October 22, 2026. Last reviewed October 22, 2026. Every fact on this page is linked to a source we opened. Spotted an error? Write to [email protected].