11 The life of an RFC, from a draft nobody may cite to a number nobody may edit

11.1 Why a draft has to be worth nothing

3GPP protects a document by putting it under change control: after a certain moment nothing may be altered except through a form and a plenary §4.6.1.

The IETF protects a document the other way round. Before a certain moment the document is worth nothing at all, and the rules say so with unusual force.

Nobody may claim compliance with an Internet-Draft RFC 2026. That single rule kills a whole class of commercial mischief: no product can be sold as conforming to a document that is still being argued about.

11.2 The draft

A specification under development is posted to the Internet-Drafts directory for informal review and comment RFC 2026. Anybody may read it; anybody may comment.

Drafts also expire. One that sits unchanged for more than six months without being recommended for publication is simply removed from the directory RFC 2026. There is no ceremony and no appeal; the work either moves or it disappears, which is a quiet way of keeping the directory honest about what is alive.

11.3 From working group to standards action

A document does not walk itself onto the standards track. The sequence is short and each step has a condition attached RFC 2026:

• L1. The working group recommends the document to its area director. That recommendation is what starts a standards action.

• L2. The draft must already have been public in the Internet-Drafts directory for at least two weeks before the recommendation.

• L3. The IESG issues an IETF-wide Last Call by email.

• L4. Comments are accepted from anyone, for at least two weeks — or at least four, if no working group was behind the document.

• L5. If the IESG approves, the RFC Editor is instructed to publish, and the draft is taken out of the Internet-Drafts directory.

• L6. The document appears in the RFC series with a permanent number.

Step L4 is the one with no counterpart in 3GPP. There, the decision is taken by a named body in a room, and the record shows a status value against a document number §9.2. Here, an approval is announced to the entire organisation and anybody at all is invited to object before it takes effect.

11.4 What it becomes: two levels, not three

Publication onto the standards track puts a document at the bottom rung.

Above it sits one further level and no more.

That change is itself an example of the machinery working on itself. RFC 6410 did not edit RFC 2026; it was published as a document of its own that replaced the ladder, and both remain in the series RFC 6410, RFC 2026.

The top rung has a demanding definition.

Read that list against the 3GPP idea of an approved specification and one difference stands out. Nothing in the 3GPP procedure asks whether anybody has built the thing; a document is approved when the plenary approves it §4.1.1. The IETF's top level cannot be reached without multiple independent implementations that have worked together in the field.

11.5 Not every RFC is a standard

The series carries several categories, and only some of them are standards RFC 2026:

• Standards track — Proposed Standard and Internet Standard.

• Best Current Practice — how something should be done now, rather than what a protocol is. The documents describing the IETF's own process are of this kind.

• Informational — published for the record, with no claim of consensus about its technical merit.

• Experimental — work that needs trying before anybody standardises it.

• Historic — superseded or abandoned.

The document's own header block says which it is, and which stream it came from RFC 7841. Reading that block before reading the document is the single most useful habit in the whole series.

11.6 Publication is permanent

An RFC is never edited after publication RFC 2026. Not for a typing error, not for a clarification, not for a change of mind.

A new version of a standard has to go through the whole process again as if it were new, and the old document usually becomes Historic RFC 2026. Retiring a standard is the same kind of act rather than an administrative one: the IESG moves it to Historic, with the same Last Call as any other standards action RFC 2026.

That is the deepest procedural difference between the two bodies, and it is worth stating plainly. A 3GPP specification is a living document with a version number that keeps moving; its history annex records every change request that touched it §4.6.6. An RFC is a fixed artefact, and its history is told by other RFCs that obsolete or update it RFC 7841.

11.7 Who actually publishes it

The IESG approves; somebody else publishes. The RFC Editor is instructed to publish once a standards action is approved RFC 2026, and what the series is and who runs it are set out in two further documents of their own RFC 8729, RFC 9280.

Those two are named here and not quoted. They are among the 1,278 documents that sit in the archive on this machine as XML rather than as plain text ^[5], so this course can point at them and takes no sentence out of either.

The split is the same one 3GPP makes between a group that decides and a secretariat that edits and issues §3.1. What differs is the direction of permanence: the 3GPP Support Team reissues the same document over and over, at rising version numbers §4.6.5, while the RFC Editor issues each document once.

11.8 Where this leads

Rough consensus, and why the room hums is how the working group reached the recommendation in step L1, and what "consensus" means when there is nobody to count. MUST, SHOULD and MAY — three words, one short document is the vocabulary the published text is written in, and The two cultures, side by side and on the evidence sets the two publication models side by side.