Summary

  • A Verified erratum is a reviewed and accurate correction record linked to an RFC. The RFC Editor says errata are not incorporated into the TXT, PDF or XML publication formats.
  • The IESG limits errata to errors present when the document was approved. New thinking, significant protocol changes and changes to intended consensus must return to the relevant standards process.

The correction that stays beside the document

An implementer encounters a contradiction in an RFC. One paragraph permits a value; a later algorithm appears to reject it. The errata page contains a report with original text, corrected text and a status of Verified. The practical temptation is to treat the corrected text as though it had always occupied the RFC.

That shortcut loses an important fact. The published document records what passed review, approval and production at a particular time. The erratum records a later judgment about a defect in that record. Both matter. The first supplies provenance for the standard; the second warns implementers that a literal reading may mislead them.

The RFC Editor’s current guidance makes the separation explicit. Reported errata are attached to the document’s information surface. A Verified report has been reviewed and is considered accurate. Yet the correction is not inserted into the normal TXT, PDF or XML editions. Readers must consult the linked correction layer.

That is not administrative stubbornness. It is a control against rewriting collective decisions without leaving a visible seam.

Four statuses perform four different acts

“There is an erratum” is too coarse a statement for engineering or procurement. The status determines what has actually happened.

Reported means a claim has entered the queue. It has not yet received the responsible verifier’s judgment. The report can be right, wrong, incomplete or an attempt to reopen a disagreement.

Verified means the report is valid under the applicable criteria and should be visible to implementers and operators. It is the strongest errata status, but its jurisdiction remains correction. It does not give the reviewer a general power to redesign the protocol.

Rejected means the report is invalid, redundant or too substantial for this correction channel. The IESG specifically places significant changes that belong in a replacing or updating RFC on this side of the boundary.

Held for Document Update means the point is not a necessary correction to the present RFC, though a future revision may consider it. A hold is institutional memory, not operative wording. Treating it as already approved would allow an unresolved suggestion to acquire force merely by appearing in the same database as verified defects.

These states form a compact decision ledger: assertion, accepted correction, declined correction and deferred consideration. Collapsing them into one “latest text” field destroys the reasoning encoded in the classification.

Verification authority follows the publication stream

RFCs come through different streams. The IETF, IAB, IRTF, Independent Submission and Editorial streams have different approving bodies and purposes. The RFC Editor’s verification guidance therefore assigns the reviewing party according to the stream that produced the RFC.

For IETF-stream technical errata, the report reaches authors, working-group chairs and Area Directors. Area Directors remain responsible for processing, although they may delegate review. Editorial reports receive initial handling by the RFC Editor, with an Area Director involved when needed.

This division keeps production expertise and technical authority from being confused. A production body can recognize punctuation and rendering problems. It should not acquire protocol-policy power simply because it operates the correction database. Conversely, a technical reviewer should not use a small correction form to bypass the community that established the original behavior.

The verifier’s name, date, rationale and stream are therefore part of the evidence. “Verified” without knowing verified by whom, under which stream and against what intent is an incomplete governance claim.

Original intent is the ceiling

The active 2021 IESG statement supplies the decisive test: errata address errors that existed when the RFC was published. New capabilities, later discoveries that change the preferred design, or disagreement with the approved result do not qualify merely because they can be expressed as replacement sentences.

The IESG allows a clear technical resolution aligned with original intent to be Verified. If the resolution is unclear or needs more discussion, it belongs on hold. A change that would alter protocol operation away from the approved consensus should generally be Rejected. A change to a process—such as a different IANA registration procedure—must not enter through errata when it would change the intended consensus.

This is a constitutional limit disguised as editorial hygiene. The narrow form asks for “original” and “corrected” text, but textual smallness does not prove policy smallness. One word can reverse a requirement. A code point range can redistribute extension power. A default can move operational risk from senders to receivers.

The reviewer must therefore reconstruct intent from more than the proposed wording. Working-group discussion, Last Call, ballot positions, interoperability expectations and the surrounding algorithm can all matter. Where that evidence does not establish a clear correction, the errata channel should preserve the doubt instead of manufacturing certainty.

Reissuing a file is not secretly changing its meaning

The publication model became more nuanced in 2025 and 2026. RFC 9720 permits the definitive RFCXML version and rendered publication versions to be reissued for narrowly controlled reasons. RFC 9920, which obsoleted RFC 9280 in February 2026, preserves stability as a historical property while recognizing reissuance.

The permission is not a licence to fold every verified erratum into the semantic text. RFC 9720 says changes to the definitive version must preserve the semantics expressed in the original RFC. It identifies schema evolution, XML errors and production-tool changes as reasons for reissue. Prior versions must remain archived, and reissuance must have a public record and reason.

The distinction is between repairing the vessel and changing the decision it carries. A renderer can stop cutting off a diagram. An XML migration can preserve a character correctly. The presentation can become consistent across the series. A new rule for protocol behavior still needs the authority that can make such a rule.

This two-track architecture—controlled reissue for faithful publication, linked errata for reviewed correction—protects both usability and historical accountability. Combining them would make it hard to tell whether two implementers read different meanings or merely different renderings.

Implementers need a two-record method

A serious implementation cannot cite only an RFC number. It should record the RFC’s status, whether later RFCs update or obsolete it, the publication version used, and the relevant errata as of a stated date.

Verified errata deserve direct engineering treatment. Tests should show whether the implementation follows the correction, and release notes should explain compatibility consequences when deployed peers may still follow the uncorrected text. A security-sensitive correction may require immediate mitigation even while the archival document remains untouched.

Held reports deserve a different response. They can inform future design reviews and flag ambiguous areas, but they should not be converted automatically into conformance failures. Rejected reports can also be useful: they show that a proposed reading was considered and denied, or that the requested change requires a broader process.

This method avoids two symmetrical errors. Ignoring errata treats the archive as infallible. Replacing the RFC with an invisible merged edition treats the correction administrator as a legislature. Good configuration management keeps the base decision and the correction judgment independently identifiable.

A thin common ledger for post-publication truth

Heng Lu’s governance model favours a minimal common record, local decisions made by competent actors and future change through voluntary adoption rather than a central claim to every kind of authority. The errata system fits that architecture when its predicates remain narrow.

The common layer needs only enough structure to identify the RFC, section, original passage, proposed correction, report type, status, verifier, reason and dates. Implementers can then decide how the correction affects their software, operators can decide how urgently to mitigate, and a working group can decide whether a new RFC is required.

The shared record should not declare that every Verified item has been universally deployed. It should not convert Held items into obligations. It should not infer that silence from an inactive working group proves agreement. Those are separate claims requiring separate evidence.

This restraint makes the correction system stronger. Its authority comes from accurately saying what was reported and how the responsible process classified it—not from pretending that a note beside an archival document has erased the document’s history.

Sources