Summary

  • RFC 7942 gives an Internet-Draft an optional Implementation Status section for named, versioned claims about maturity, coverage, licensing, testing and interoperability. It is evidence for a decision, not an IETF endorsement or a complete catalogue.
  • The section is deliberately temporary. Because its contributor-supplied contents age quickly and are not verified by the IETF, authors are asked to remove it—and the RFC 7942 reference—before the draft is published as an RFC.
  • Running code is strongest when its identity, draft revision, coverage, test conditions and date are visible. Publication does not inherit those claims, and implementation does not replace a clear specification.

A receipt designed to expire

The deletion instruction in RFC 7942 looks paradoxical only if every useful fact is expected to live forever in the final standard. The document, written by Yaron Sheffer and Adrian Farrel and published in July 2016 as Best Current Practice 205, starts from a narrower proposition. Implementation experience can improve a protocol while the protocol is still being designed. A permanent RFC, however, is a poor home for an unverified snapshot of which code existed at one moment.

That distinction separates two records that are often collapsed. A specification states the stable technical agreement. An implementation-status receipt tells reviewers what somebody says has been built against a particular revision, how much of it was built, and where the claim can be examined. The first is intended to endure. The second is useful because it is dated.

RFC 7942 did not arrive as an abstract proclamation. Its predecessor, RFC 6982, began in 2013 as an 18-month process experiment. The proposed tests were practical: did disclosure help a working group compare competing solutions; did implementation experience cause a protocol to change; did it encourage interoperability testing; did people other than the authors review the proposal through code or direct use? The later BCP obsoleted that experimental RFC. The mechanism itself therefore followed the logic it advocates: propose a bounded process, observe it, then decide whether to retain it.

What the section is meant to hold

The fields in RFC 7942 are unusually concrete for a process document. For each implementation, an Internet-Draft may identify the responsible organisation, the implementation name or web page, a general description, its maturity, which parts of the specification it covers, which draft versions it matches, its licence, experience worth sharing, a contact and the last update date. The section may also link to test cases and interoperability reports.

Taken together, those fields form a chain rather than a badge. “Production” without a date is an adjective. “Implements the protocol” without feature coverage is ambiguous. A repository without a commit or compatible draft revision is not reproducible. Two product names without an interoperability report do not prove that the products exchanged the same optional features. A last-update date without an accountable contact tells a reader when the claim aged, but not who can correct it.

The BCP anticipates this weakness. Its proposed introductory text says that listing an implementation is not IETF endorsement, that the IETF has not verified information supplied by contributors, that the section is not a catalogue of all implementations or their features, and that other implementations may exist. Working-group chairs and Area Directors are also asked to stop it becoming a marketing venue.

This restraint matters because implementation claims create incentives. A company may hope that visible code accelerates its preferred proposal. An open-source project may gain contributors. A document author may want to demonstrate momentum. None of those motives invalidates the code, but each makes provenance, version, coverage and testing more important than the count of names in a list.

Why useful evidence is removed

RFC 7942 says the information is necessarily time dependent and therefore inappropriate for a published RFC. Authors should place a note in the draft asking the RFC Editor to remove the entire section and its RFC 7942 reference before publication. The RFC errata process is not expected to maintain the deleted snapshot.

Removal is not a judgment that the implementation work was irrelevant. It is a boundary around what publication means. If a three-year-old prototype label remained inside the RFC, readers could mistake it for a current product statement. If a vendor disappeared, a licence changed or later revisions invalidated the reported coverage, the permanent standard would silently carry an obsolete market map. If one implementation had been listed and another omitted, the archived text could look like institutional preference long after the working-group decision it informed.

The BCP offers a different home when implementation status remains useful: an openly accessible external page, for example a working-group wiki. That resource can be maintained by implementers, can grow beyond the size convenient for a draft and can remain live after RFC publication. RFC 7942 says it should not require authentication, registration or access control if it is to have useful effects. The design is therefore not “delete the evidence.” It is “move changing evidence into a record that can change.”

Running code without code sovereignty

RFC 3935 describes IETF standards as the product of engineering judgment and real-world experience implementing and deploying specifications. RFC 7282 gives the familiar formulation: rough consensus should not be a vote conducted in a vacuum, and actual engineering should challenge theoretical design. Heng Lu's Running-Code Primacy makes the same ordering sharper: publication is not operational reality, and common rules should be justified by what independent systems need to interoperate.

RFC 7942 supplies a small but rigorous mechanism for that philosophy. It lets code speak before a design becomes fixed. It does not let code rule. The BCP explicitly says code should never be used instead of a clear specification. It also refuses to prescribe how much preference a working group should give a proposal that has an implementation.

This is an important limit. A running prototype can prove that one team built one interpretation. It can expose ambiguities, omissions and impossible requirements. It can generate packets for another implementation to test. But it cannot, by its mere existence, prove that the design scales, that the implementation is secure, that its owner is independent of another named implementation, or that operators have adopted it. Code is evidence from a controlled actor, not sovereignty over every other actor.

The evidence chain publication cannot compress

A defensible implementation receipt needs at least six separations.

First, preserve the exact draft identity. Code built against revision 08 is not automatically evidence about revision 12. Second, preserve the code identity: product or repository, release, commit or build, licence and accountable maintainer. Third, record feature coverage, including exclusions and optional behaviour. Fourth, keep the test evidence: cases, environment, peer versions, results and failures. Fifth, record how the working group used the evidence and which objections remained unresolved. Sixth, after publication, measure deployment and operational outcome separately.

The last separation is the one most often lost. An RFC number proves publication of a document. It does not prove that the pre-publication implementations were updated to the final text, that products shipped, that operators enabled them, that independent systems interoperated, or that the protocol produced the intended outcome. Those claims belong to release records, conformance reports, configuration readback, traffic observation and incident history.

Adrian Farrel's official IETF Datatracker profile, captured on 1 September 2026, lists a long RFC record and several current IETF roles. It establishes the public identity of one co-author and the depth of his standards work. It does not make him the verifier of every implementation statement or the sole controller of the process. RFC 7942 itself distributes the work: implementers report, authors curate, chairs and Area Directors guard against promotion, working groups weigh evidence, the RFC Editor removes transient text, and operators decide what runs.

The disappearing section is therefore not an archival oddity. It is a disciplined admission that evidence has a lifecycle. Running code should be visible while it can improve a specification. Once the specification becomes a durable public record, changing implementation status needs its own accountable, dated and correctable ledger.

Sources