The Internet Engineering Task Force (IETF) develops open standards for Internet protocols through a collaborative process documented in Requests for Comments (RFCs). Standards are crucial for interoperability; without them, networks from different vendors could not communicate. The standards process involves iterative refinement through working groups and community feedback.
Now that you understand how networks function at a basic level — how data moves between devices, how protocols layer on top of each other — the natural question is: who decides what those protocols actually look like? The answer is the Internet Engineering Task Force (IETF), a global, open community of engineers, researchers, and vendors who collaboratively design the standards that make the Internet work. Unlike a traditional standards body with formal membership and voting, the IETF operates on a principle often summarized as "rough consensus and running code." Anyone can participate, and proposals succeed by demonstrating that they work in practice, not just on paper.
The IETF's primary output is the Request for Comments (RFC) document series. Despite the humble name — originally these really were requests for feedback — RFCs have become the authoritative specifications for Internet protocols. TCP, IP, HTTP, DNS, TLS, and virtually every protocol you have encountered in networking is defined in one or more RFCs. Each RFC has a number (e.g., RFC 793 for TCP, RFC 2616 for HTTP/1.1) and, once published, is never modified — corrections and updates come as new RFCs that obsolete or extend earlier ones. This creates a traceable history of how each protocol evolved.
The standards process itself is deliberately incremental. A new idea typically starts as an Internet-Draft, a working document that expires after six months if not renewed. Working groups — focused teams organized around specific topics like routing, security, or transport — debate, revise, and test these drafts. If a draft gains rough consensus (not unanimity, but general agreement that it is the best available approach), it advances through stages: Proposed Standard, Draft Standard, and finally Internet Standard. In practice, most widely deployed protocols sit at the Proposed Standard level — the bar for full standardization is high, and the community has learned that real-world deployment matters more than formal status.
Why does this matter to you as someone learning networking? Because standards are the reason your laptop can talk to a server running completely different software, built by a different company, in a different country. Interoperability — the ability of independent implementations to communicate correctly — is the whole point. When you read a protocol specification, you are reading a contract: if both sides follow this document, communication will succeed. Understanding that these contracts exist, how they are created, and where to find them (the RFC archive at rfc-editor.org) gives you the ability to go beyond textbook descriptions and read the actual source of truth for any Internet protocol.