Summary

  • The current IETF repository normally expires an Internet-Draft 185 days after posting unless a formal process state prevents it. Expiry describes the active copy's lifecycle; it does not name a body that rejected the proposal.
  • The active Repository and the Archive are different records. A revision can leave the Repository because it was updated, replaced, published as an RFC or expired, while its versions remain preserved in the Archive.
  • Official histories demonstrate the distinction. draft-iab-protocol-maintenance-05 expired, returned as later revisions and became RFC 9413. draft-ietf-netvc-testing expired repeatedly, but its consequential closure was a separate IESG Dead state with an explicit reason.
  • A diligence system needs a draft-state receipt: exact revision, dates, archive and replacement chain, group and stream state, adoption and Last Call evidence, explicit disposition, implementation reliance and the actor responsible for the conclusion.

The register that converted a clock into a verdict

Imagine a procurement team evaluating a protocol extension. Its analyst opens the IETF Datatracker, sees that the latest Internet-Draft is expired and records IETF rejected. A product manager removes the feature from a roadmap. A security assessor repeats the label in a report. Six months later, a revised draft appears, and the same organisation now records IETF approved work resumed.

Both entries are invented conclusions. The first turns an automatic date into an institutional judgment. The second turns a new file into endorsement. The system has observed two real facts—expiry and revision—but attributed two decisions that the evidence does not establish.

That is not a minor vocabulary problem. Rejected needs an actor, authority, object and reason. Did a working group decline adoption? Did a chair find no rough consensus? Did an Area Director refuse sponsorship? Did the IESG mark a publication request dead? Did an author simply stop editing? Was the text replaced by another draft name? Or did an otherwise active piece of work cross a repository clock while people continued discussing it?

The word Expired answers none of those questions by itself. It tells the reader that a lifecycle condition occurred. A governance record must recover the separate event that explains what, if anything, the relevant institution decided.

Repository, Archive and the 185-day event

The current IETF Author Resources guidance distinguishes the Internet-Draft Repository from the Internet-Draft Archive. The Repository contains active versions. A version ceases to be active when a newer revision updates it, another draft replaces it, it is published as an RFC, or it expires. The Archive retains all versions and their additional renderings except in exceptional removal circumstances.

Under the current operating rule, a draft normally expires 185 days after it enters the Repository. Some formal processing states stop the clock from producing expiry, including IESG processing for publication in the IETF stream and review by the Independent Series Editor for the Independent Submission Stream. The state exception matters: even the timer is connected to the process record rather than functioning as a universal six-month guillotine.

Archive retention does not make an Internet-Draft an archival publication. The same current guidance warns that drafts remain work in progress and should not be cited as anything else. Preservation answers “what text existed?” It does not answer “what did the IETF approve?”

The difference becomes clearer when read against RFC 2026. In 1996, BCP 9 described the Internet-Drafts directory as a way to expose evolving text for informal review. An unchanged draft that passed six months without an IESG recommendation for publication was removed; a newer version restarted the timeout. RFC 2026 also stated that Internet-Drafts have no formal status and can change or disappear.

The infrastructure has evolved. Current guidance now names a 185-day interval and a durable Archive even when a revision leaves the active Repository. The governance boundary has not reversed. A draft is still not an RFC, and a repository timeout is still not a substitute for an attributable process decision.

Four states that one label cannot carry

A reliable record separates at least four layers.

The first is document identity. draft-example-foo-04 is not a generic idea called “Foo”. It is one revision, with one posting date, one content hash and one set of references. Revision 05 may repair a security condition, narrow the scope or replace the protocol mechanism. A diligence note that omits the suffix cannot prove which text it assessed.

The second is repository lifecycle. Active, updated, replaced, published and expired describe why a particular revision is or is not the active copy. Those labels help readers find current work. They do not alone express consensus or technical merit.

The third is process state. An individual submission, a candidate for working-group adoption, an adopted working-group document, a document in working-group Last Call and a publication request under IESG evaluation occupy different institutional positions. RFC 2418 describes the Internet-Drafts area as a resource for in-process documents. Its later sections treat a working-group Last Call, rough consensus for advancement and submission to the IESG as separate acts.

The fourth is disposition. A named actor can record that work was adopted, replaced, withdrawn, declined, approved, published or closed, sometimes with reasons and an appeal path. This is where a reviewer may find a genuine adverse conclusion. It must not be manufactured from the lifecycle layer.

These layers can move independently. A working-group document can expire while the group still intends to revise it. An active individual draft can have no sponsor. A document can be technically implemented while its publication request is dead. An expired revision can be superseded by a newer revision under the same draft name. One coloured badge cannot carry this state space honestly.

The draft that expired and became RFC 9413

The official history of Maintaining Robust Protocols supplies a clean counterexample to “expired means rejected.” Revision 05 was posted on 12 July 2021 and marked expired by the system on 13 January 2022. Revision 06 appeared on 10 May 2022. Revisions 07 through 12 followed. The IAB moved the document through Community Review and IAB Review, recorded consensus and approval, and sent it to the RFC Editor in February 2023.

The final work was published as RFC 9413 in June 2023. The early expiry remains a true historical event. Describing it as an IAB or IETF rejection would nonetheless be false. Nothing about the timer prevented later revision, review and publication.

This example does not prove that expired drafts usually return. It proves the narrower and necessary proposition: expiry is not logically equivalent to rejection. If a data model cannot represent this history without overwriting Rejected with Approved, its event vocabulary is too small.

The better record would preserve both. On 13 January 2022, revision 05 left active status through automatic expiry. On 10 May, revision 06 became available. Later entries identify the review bodies and decisions. RFC 9413 supplies the archival publication outcome. Each fact retains its own actor and timestamp.

The draft whose real closure had a named reason

The history of Video Codec Testing and Quality Measurement shows the other side. Several revisions expired and were followed by new versions. Revision 05 expired in September 2017; revision 06 arrived the next month. Revision 06 expired in May 2018; revision 07 appeared in July and entered working-group Last Call. Revision 07 itself expired in January 2019 while the working-group state recorded consensus waiting for write-up. Revision 08 then entered the publication process and IETF Last Call.

The consequential adverse record arrived later. On 25 March 2020, the IESG state changed to Dead. The Area Director's accompanying note said repeated attempts to obtain responses to evaluation comments had led to the conclusion that the NETVC working group lacked sufficient momentum to complete the document. A later automatic expiry occurred in August.

Here a diligence analyst can cite a real closure. It has a date, a responsible process surface and a reason. The reason concerns momentum and unresolved evaluation comments; it is not a technical theorem that the testing methods were worthless. The record can also note that the shepherd write-up said the methods were already used by AV1 implementers. Implementation reliance, publication disposition and repository expiry were three different facts.

Calling only the final expiry “rejection” discards the best evidence. It hides the IESG state change and substitutes an unexplained calendar label for an attributable conclusion. Calling the earlier expiries rejection would be worse, because work demonstrably continued after them.

Revival does not mean approval

The argument is symmetrical. If expiry does not prove rejection, a new revision does not prove acceptance. Anyone can submit an eligible Internet-Draft. A revision can address comments, restore visibility, restart discussion or simply preserve an author's option to continue. Formal standing still depends on the relevant process record.

The same caution applies to working-group naming. A draft with draft-ietf-... normally reflects working-group adoption, but the exact group state and history remain the authoritative evidence; the filename does not prove current rough consensus on every sentence or IESG approval. A Last Call solicits a defined review. It is not the final publication event.

Nor does running code silently confer institutional status. Implementation is highly relevant to technical judgment and adoption risk. It can reveal interoperability, operational value and hidden costs. Heng Lu's Running-Code Primacy is a useful discipline against paper authority. But an implementation is evidence about deployed reality, not a forged consensus record. The right response is to record both the code and the process without letting either impersonate the other.

External adopters also retain responsibility. A purchaser may deliberately freeze a product requirement to an Internet-Draft revision because it needs an emerging capability before RFC publication. That can be rational. The contract, not the draft's repository badge, creates the purchaser's obligation. It should identify the exact revision, change-control rule, compatibility tests and exit path.

A proposal to end expiry is evidence, not policy

The individual draft Removing Expiration Notices from Internet-Drafts argued that automatic expiry no longer served a useful purpose once drafts remained archived. It noted that expired drafts continue to be cited and that systems may merely display them differently. The proposal is valuable evidence that experienced participants disagree about the mechanism's present utility.

It is also an Internet-Draft whose latest revision expired. That irony should not be converted into either ridicule or authority. The document was not adopted as the current rule. Its arguments can be evaluated; its existence cannot be cited as IETF consensus to abolish expiration.

This is exactly the discipline the larger article requires. A draft can contain strong reasoning without having formal standing. A process label can be accurate without settling the merits. Governance quality comes from keeping those propositions separate until an authorized actor connects them.

The draft-state receipt

A standards inventory should preserve enough evidence for another reviewer to reconstruct the conclusion without guessing what one badge meant on one day.

Field What it establishes
Exact name and revision The specific text assessed rather than a floating proposal name
Content fingerprint Whether the reviewed bytes match the preserved revision
Posted and expiry dates The clock event and the version of the rule applied
Repository state Whether that revision remains active and why it left active status
Archive location Where the historical text and renderings remain available
Revision chain Earlier and later versions without treating them as identical
Replacement relations Whether another draft name succeeded or displaced the work
Stream, sponsor and working group Which institution, if any, owns the next process step
Adoption state Whether a working group accepted the item as its work and on what record
Consensus and Last Call Which review was performed, over which revision and with what unresolved objections
IESG or stream disposition The actual decision, actor, date, status and reasons
Publication outcome RFC number, stream and category if archival publication occurred
Implementation reliance Code, tests, deployments or external references that remain relevant despite document state
External adoption instrument The contract or policy that selected the draft and the revision-change rule
Owner and next review Who corrects the inventory when the draft, process or deployment changes

The receipt prevents two opposite errors. Authority inflation occurs when Active, adopted or Last Call becomes IETF approved. Authority fabrication occurs when Expired becomes IETF rejected. One requires evidence of a positive act; the other requires evidence of an adverse act. Neither can be supplied by a timer alone.

Sources

Conclusion

Expired is a useful warning. It tells the reader that the active revision crossed a freshness boundary and that reliance on it needs renewed diligence. It does not reveal why work stopped, whether anyone judged the technical design, or whether the relevant body reached a decision at all.

The disciplined rule is simple: treat expiration as a clock receipt and disposition as an authority receipt. Preserve both. If a proposal was declined, name the actor, process, version, date and reasons. If it returned, record the new revision without inventing approval. If implementers or purchasers still rely on it, record that reliance under their own authority. A calendar can age a document. It cannot cast a vote.