The IETF, the Internet Engineering Task Force, is the open, volunteer-driven standards organization that develops and maintains the core technical protocols of the Internet, including IP, TCP, DNS, HTTP, TLS and email standards. In Internet governance it occupies the technical layer: it does not regulate networks or allocate addresses, but it writes the specifications that every interoperable implementation follows, published as RFC documents.
Founded in 1986, the IETF has no formal membership and no voting. Anyone can join its mailing lists or attend its meetings, and decisions are made by rough consensus among participants. Its guiding principle is often summarized as preferring rough consensus and running code over formal votes, meaning that proposals gain standing when they work in real implementations.
How the IETF is organized
Technical work happens in working groups, each with a written charter, named chairs and a defined set of deliverables. Working groups are grouped into areas such as Applications and Real-Time, Internet, Operations and Management, Routing, Security, Transport and the General area. Each area has one or two Area Directors, who together form the Internet Engineering Steering Group (IESG), the body that approves documents for publication as standards.
| Body | Role | Relationship to the IETF |
|---|---|---|
| Working groups | Draft and refine specifications | Core of IETF technical work |
| IESG | Final technical review and approval | Leadership of the IETF areas |
| IAB | Architectural oversight and appeals | Advises and charters related bodies |
| IRTF | Longer-term research groups | Parallel research organization |
| RFC Editor | Edits and publishes RFCs | Serves all RFC streams |
| IETF Administration LLC | Finances, contracts and meetings | Legal home under the Internet Society |
The IETF meets in person three times a year, with full remote participation, but most work happens continuously on public mailing lists and in shared repositories. Leadership positions are filled by a nominating committee of randomly selected volunteers, which limits the influence of any single company.
From Internet-Draft to RFC
Every proposal starts as an Internet-Draft, a working document that expires after six months unless updated. When a working group adopts a draft and reaches consensus, it passes working group last call, then review by the responsible Area Director, an IETF-wide last call and evaluation by the full IESG. Approved documents go to the RFC Editor and receive a permanent number.
| Stage | What happens | Typical duration |
|---|---|---|
| Individual draft | Author proposes an idea | Weeks to months |
| Working group adoption | Group takes ownership of the text | One decision point |
| Working group last call | Final review inside the group | Two to four weeks |
| IETF last call | Review by the whole community | Two to four weeks |
| IESG evaluation | Area Directors raise or clear objections | Weeks to months |
| RFC publication | Editing and permanent numbering | Weeks to months |
The whole process commonly takes one to several years for significant protocols. An RFC is never changed after publication; corrections appear as errata, and revisions are published as new RFCs that obsolete or update older ones, as RFC 9110 did for the HTTP semantics.
Standards track and document status
Not every RFC is a standard. Each document carries a status that signals its weight, and confusing these statuses is a frequent mistake when quoting RFCs as requirements. The standards track now has two maturity levels, Proposed Standard and Internet Standard, after RFC 6410 removed the former Draft Standard level.
| Status | Meaning | Example use |
|---|---|---|
| Proposed Standard | Stable, reviewed specification | Most deployed protocols |
| Internet Standard | Mature, widely implemented standard | Core protocols with an STD number |
| Best Current Practice | Operational or process guidance | Requirement keywords such as MUST |
| Informational | Published for information, no endorsement | Descriptions of vendor protocols |
| Experimental | Under evaluation, not recommended for general use | New congestion control ideas |
| Historic | Obsolete or no longer recommended | Retired protocol versions |
The IETF among Internet governance bodies
The IETF is often confused with other organizations in Internet governance. Its scope is protocol specification, while ICANN coordinates names and numbers policy, IANA maintains the registries that IETF documents create, and the W3C standardizes web technologies such as HTML and CSS. The boundaries are clear but cooperative: an IETF RFC can instruct IANA to create a new registry of codes.
| Organization | Main scope | Decision model |
|---|---|---|
| IETF | Internet protocols | Rough consensus of individuals |
| IANA | Protocol parameter, number and root zone registries | Follows IETF and ICANN policies |
| ICANN | Domain name and address policy | Multistakeholder board and community |
| W3C | Web platform standards | Member organizations and consensus |
| ITU-T | Telecommunication standards | National governments and members |
Participants in the IETF act as individuals, not as representatives of their employers, and its standards are freely available to read and implement. Contributors must disclose known patents under the IETF intellectual property rules, but the IETF does not require royalty-free licensing.
Common misunderstandings
- The IETF does not enforce its standards. Adoption is voluntary; protocols succeed only when vendors and operators implement them.
- Not every RFC is a requirement. Informational and Experimental RFCs carry no endorsement as standards.
- Rough consensus is not majority voting. Chairs judge whether objections have been addressed, not how many people agree.
- April 1 RFCs are humorous and should never be cited as technical specifications.
The simple explanation
The IETF is the group of engineers who write the rulebooks that let computers on the Internet talk to each other. Just as all drivers follow the same traffic rules, all devices follow the same communication rules so that a phone in one country can load a website hosted in another.
Anyone can take part. People discuss ideas openly, test them in real software and agree when there is broad support. The finished rulebooks are free to read, which is a major reason why the Internet works the same everywhere.
How it is used in practice
A network equipment vendor wants its firewalls to inspect a newer version of a transport protocol. Instead of reverse engineering traffic, its engineers read the relevant Proposed Standard RFCs, check the errata, and follow the working group’s mailing list to see which extensions are close to publication.
One engineer notices an ambiguity in a draft that would make middleboxes misread certain packets. She posts an analysis to the list, joins an interim online meeting and proposes clarifying text. After discussion, the editors adopt the change, and it survives working group and IETF last call. When the RFC is published, the vendor’s implementation already matches it, and customers gain interoperable products because the vendor contributed directly to the open standard.