Prerequisites

Related

Workshop · 1,166 words · 5 min read

RFC 1, Annotated: The Document That Invented Internet Governance

Steve Crocker wrote RFC 1 in a bathroom at night because he didn't want to sound bossy. The tentative document he produced became the model for every internet standard that followed.

Table of Contents
  1. TL;DR
  2. The Situation in April 1969
  3. The Bathroom, the Bathtub, the Title
  4. What RFC 1 Actually Said
  5. What RFC 1 Set in Motion
  6. The Governance Accident
  7. The Document That Isn’t an Order

#TL;DR

In April 1969, a 24-year-old UCLA grad student named Steve Crocker wrote a three-page note describing some ideas the ARPANET host-software group had been discussing. He titled it “Request for Comments” — not Specification, not Standard — because he was terrified that a “specification” from a grad student would offend senior researchers. The tentative title stuck. Fifty-seven years and nearly 10,000 documents later, every significant protocol on the internet — TCP, IP, SMTP, HTTP, DNS, TLS, QUIC — has been defined through the same process a nervous grad student invented to avoid sounding authoritative.

#The Situation in April 1969

The four-node ARPANET was still eight months from going live. BBN was building the IMPs. The wires were being installed. But nobody had decided how the host computers — UCLA’s SIGMA 7, SRI’s SDS 940, UCSB’s IBM 360/75, Utah’s PDP-10 — would actually talk to each other over the new network.

ARPA had not designated a committee. There was no working group. There was a loose collection of graduate students from the four sites who had been meeting informally, brainstorming possible protocols. They called themselves the Network Working Group (NWG).

Someone needed to write down what they’d been talking about. Crocker volunteered, then immediately started worrying.

#The Bathroom, the Bathtub, the Title

Crocker has told the story many times since. He was staying at a friend’s house. His roommates were asleep. He wanted to work without disturbing anyone, so he took a notepad and went into the bathroom and wrote at night by whatever light didn’t bother anyone else.

The anxiety was structural. Crocker was 24. He had no standing to issue specifications to a field full of senior researchers from half a dozen institutions. If he wrote “Specification of Host Software” or “ARPANET Protocol Standard,” people at Harvard and MIT would reasonably ask who he thought he was.

So he softened it. Every paragraph hedged. The title made the whole thing explicitly provisional:

Request for Comments April 7, 1969 Host Software Stephen D. Crocker UCLA

The framing was a social engineering move. You can’t object to someone asking for comments. And once the comments arrive, everyone who contributed is implicitly a participant. A specification imposes. A Request for Comments invites. Fifty years of internet governance has leaned on that distinction.

#What RFC 1 Actually Said

Read today, RFC 1 is a strange document. It’s not the design of a protocol — it’s the design of a conversation about a protocol. It proposed some things that didn’t survive, sketched some ideas that are still with us, and left most of the real questions open on purpose.

Roughly, the document argued:

  • Host-to-host communication should be layered. There’s the IMP subnet underneath, provided by BBN, and there’s the host software above it. The two should be cleanly separated.
  • Each host should run a program called the Network Control Program that manages connections with other hosts.
  • Connections should be full-duplex, identified by a pair of named sockets. Higher-level uses — remote login, file transfer — would run as users of that connection primitive.
  • There should be a distinction between primary connections (short, control-oriented) and auxiliary connections (longer, data-heavy). This split survived briefly in early NCP and was later dropped.
  • Flow control is important but unspecified here. Someone should write the next RFC on that.

The important part isn’t the technical content — much of it was wrong, and was replaced within a year by subsequent RFCs and eventually by TCP/IP. The important part is the format: a dated, numbered, signed document that proposes, explains, and invites response.

#What RFC 1 Set in Motion

The Network Working Group kept writing. By the end of 1969, they’d produced about 20 RFCs. By 1971, the number was in the hundreds. Each one built on or replaced an earlier one. The rules of the genre hardened organically:

  • Numbered sequentially, never reused. RFC 3 obsoletes RFC 2; RFC 2 stays in the archive. Nothing is ever deleted. This is how the internet’s spec corpus became a stratified record of its own evolution — you can still read RFC 821 (original SMTP, 1982) next to RFC 5321 (its replacement, 2008).
  • Anyone can write one. RFCs are edited, not gatekept by institution. Pat Lyall at a telco, a grad student at Berkeley, and a Cisco engineer all got the same review process.
  • Plain text, no markup. Until very recently, RFCs were 72-column ASCII, to be readable on any terminal. That constraint is gone now, but the culture of “one file, no dependencies, readable forever” remains.
  • “We reject kings, presidents, and voting. We believe in rough consensus and running code.” That line — from Dave Clark at an IETF meeting in 1992 — became the IETF’s de facto constitution. A standard is finalized when enough implementers agree and at least two interoperable implementations exist.

#The Governance Accident

RFC 1 accidentally solved a problem standards bodies had been failing at for a century. International telecom standards, maintained by what’s now the ITU, were the opposite of Crocker’s model: governments sent delegates, documents were written in French and English in parallel, ratification took years, and the resulting specifications cost money to read. Vendors implemented what they wanted and called it compliant.

The RFC process was the inverse:

  • Free to read, free to cite, free to implement.
  • Bottom-up, driven by whoever cared enough to show up.
  • Incremental — an RFC proposing a small change could become a standard in months.
  • Implementation-first — if the code didn’t run, the RFC didn’t ship.

When ISO later tried to standardize its own seven-layer networking stack (the OSI model) through the traditional top-down process, it lost comprehensively to TCP/IP, which had been iterating through RFCs for a decade by the time OSI shipped. The OSI model now exists mainly as a teaching tool. The RFC model runs the internet.

#The Document That Isn’t an Order

The trick of RFC 1 — the reason Crocker’s phrasing still governs — is that it refused to claim authority it didn’t have. “Request for Comments” is a genre built for contributors who will later turn out to be wrong. It survives being wrong gracefully. A specification can be violated. A request for comments can only be superseded.

That turned out to be the right design for a standards process that would need to keep evolving across fifty years, six generations of hardware, and scale increases of nine orders of magnitude. You can’t know the right answer in advance when you’re designing something that will end up running on everything from a 900-pound Honeywell to a smart thermostat. You can know how to keep the conversation going.

The ARPANET post treats RFC 1 as a charming anecdote about a nervous grad student. It’s also the first entry in the most successful standards corpus in the history of engineering — and the only governance document on this list that was written, deliberately, to not sound like one.