Rough consensus and running code
The IETF (Internet Engineering Task Force) has no formal membership, no national delegations, and no voting body in the way ISO or a national government does. Anyone can join a mailing list, attend a meeting, or submit a draft. Decisions are made by what its own culture calls "rough consensus and running code" — a phrase attributed to early IETF leader David Clark: a standard should reflect general agreement among people who actually showed up to do the work, ideally backed by a working implementation that proves it's practical, not just theoretically sound.
This is a genuinely different model from NIST's government-agency process or ISO's national-body voting, covered elsewhere on this page — and it's a large part of why internet protocols evolved as fast and as openly as they did.
From Internet-Draft to RFC
A specification starts life as an Internet-Draft — a working document, expires automatically after 6 months without an update, and explicitly not yet a standard (citing one as though it were is a common and real mistake in security reviews). A working group refines it through rounds of public review and implementation experience, and once the IESG (Internet Engineering Steering Group) approves it, it's published as an RFC (Request for Comments) — a name that's stayed for historical reasons even though a published RFC is a finished, numbered, permanent document, not an open request for feedback.
RFC numbers are never reused and never renumbered. A newer specification that replaces an older one is published as a brand new RFC that explicitly states it obsoletes the old one — the old number still exists and still describes what it always described, it's just no longer the current standard. RFC 8017 (PKCS#1 v2.2, 2016) obsoleting RFC 3447 (PKCS#1 v2.1, 2003), which itself obsoleted RFC 2437, is a clean real example: three RFC numbers, one continuously evolving specification.
From idea to standard
- 1
Internet-Draft
A working document, expires after 6 months without an update — explicitly not a standard yet.
- 2
Working group review
Public mailing-list discussion, implementation experience, revised drafts.
- 3
IESG approval
The Internet Engineering Steering Group signs off on publication.
- 4
RFC published
A permanently numbered document. Superseding specs obsolete it by number; the old RFC text never changes.
The working groups behind the protocols in this catalog
Every protocol module on this site sits under a specific IETF working group's output.
Working groups → RFCs → Learn modules
TLS 1.3 and its predecessors — covered in the TLS in Practice module.
The X.509 PKIX certificate profile and related PKI specs — covered in Digital Certificates & X.509.
OAuth 2.0; the related JOSE working group produces RFC 7519 (JWT) and the surrounding JSON Object Signing and Encryption specs — covered in JWT & API Auth.
Defines the SSH transport protocol — covered in the SSH module.
Practice
An Internet-Draft was last updated 9 months ago and was never published as an RFC. Is it still a valid reference to cite in a security design document?
Go deeperWhat "RFC" doesn't automatically mean⌄
Not every RFC is a mandatory standard, and treating the label as uniform is another common mistake. The IETF publishes RFCs on a spectrum: Standards Track (the familiar Proposed Standard / Internet Standard progression), Informational (documenting something without prescribing it), Experimental, and BCP (Best Current Practice, operational guidance rather than a protocol spec). RFC 2119 — itself a BCP — is the one that defines what MUST, SHOULD, and MAY actually mean inside every other RFC that uses those capitalized words; it's worth knowing this RFC exists specifically because so much of every other spec's precision depends on it.