Summary

  • RFC Final Review, formerly called AUTH48, begins after a publication stream has approved an Internet-Draft. Authors review the complete edited content and formats, resolve questions and approve publication; the check is real, but it is not a new IETF vote.
  • The RFC Production Center controls the production copy after it enters the queue. Editorial corrections can move through that custody, while additions, deletions and technical changes that appear beyond editorial require approval from the originating stream.
  • The 2025–2026 kramdown-rfc and GitHub pilot makes the boundary unusually visible. As of 27 August 2026, RFC-to-be 10025 had a live Final Review page and public review repository, while its RFC information URL still returned no published record.
  • A reliable final-review receipt preserves the approved draft revision, stream decision, RPC edit set, issue classifications, author and stream approvals, final output hashes and publication announcement. Implementation and deployment remain a separate evidentiary layer.

The pull request that looked like a second vote

The most dangerous status mistakes often begin with a true screenshot. A technical-risk team opens a public repository for an RFC-to-be. It sees an RPC-edits branch, open issues, a review request and names that have not yet supplied final approval. One analyst records “draft still under editorial review.” Another records “authors have vetoed the standard.” A third calls the pull request a second consensus round.

Only the first description is supportable without more evidence.

Final Review is a custody interval between two different institutional acts. Before it, a publication stream approves an Internet-Draft for publication. After it, the RFC Production Center publishes a defined set of output files and announces the RFC. In the middle, editors, authors and stream contacts work on the fidelity and readiness of the production copy.

The middle matters. A missing line in an algorithm, a malformed ABNF fragment, a wrong IANA instruction, a reference error or a rendering defect can survive for years once the RFC becomes the archival point of reference. But importance does not erase jurisdiction. The final check does not hand the document to a new legislature composed of authors, editors and GitHub entities.

That is the governance value of the current experiment. The repository does not merely expose more activity. It lets a later reader distinguish the source that was approved, the edits proposed by the RPC, the questions raised, the people asked to respond and the approvals needed when a change is more than editorial. Transparency becomes useful when it preserves boundaries rather than turning every visible entity into an authority.

Approval happens before the queue

The current RFC publication guidance starts with a fact that is easy to lose in a status dashboard: the publication process begins when one of the RFC streams approves an Internet-Draft. The IETF, IAB, IRTF, Independent and Editorial streams each have their own approving path. The document reaches the RFC Production Center only after the relevant path has produced a publication decision.

That prior act is not decorative. It defines which content was approved, which stream owns it and who can authorize a substantive departure. Once the document enters the publication queue, the RPC takes change control over the production copy. An author who wants to change it does not simply replace the approved file. The change travels through the RPC and, when it is technical or otherwise beyond editing, back to the originating stream.

RFC 9920, the current RFC Editor Model, makes the division explicit. Stream approving bodies are responsible for the content of their streams. The RFC Editor function is responsible for production and distribution. The RPC edits documents, preserves records of edits and dialogue, identifies changes that might have technical impact, seeks clarification, establishes publication readiness and publishes the final artifacts.

This is not a contest between “real engineers” and “mere editors.” Both controls are necessary and neither should impersonate the other. The stream cannot preserve a reliable series merely by saying that it approved the idea. The RPC cannot acquire authority to redesign the protocol merely because it controls the production copy. Authors cannot silently reacquire sole ownership of a document that has passed through a collective stream decision.

A defensible register therefore needs two fields before it ever reaches the author checklist: approved source and approving stream. Without them, every later edit appears to float free of an accountable baseline.

What authors actually approve

Final Review is not ceremonial. The same current guidance asks authors to resolve the RPC's questions, review changes submitted by coauthors, inspect the full content, check the copyright notice and semantic markup, and examine the HTML, PDF and text outputs. The process can require several exchanges and alternative wordings. It finishes when all listed authors give final approval.

The current kramdown-rfc instructions divide that responsibility into two approvals for the pilot path. Authors first indicate that the markdown content is stable enough to convert to RFCXML. They later approve the content and all final formats. The second approval matters because a correct source can still produce a defective representation: code, artwork, references, line wrapping and semantic markup have to survive conversion.

Author approval is therefore best understood as an integrity attestation. It says that the final production artifacts faithfully express the work the author is responsible for and are ready to become the durable publication. It does not say that one author's preference now outranks the working group, IESG or other stream authority that approved the document.

The unavailable-author rule proves that the distinction is intentional. Current guidance offers three routes when an author can no longer act: move the person to Acknowledgements, move the person to Contributors, or have a stream manager approve in that author's place. The choice preserves credit while preventing the production stage from creating an accidental permanent veto in one unreachable inbox.

None of this makes an absent approval trivial. A missing author may be the only person who can identify a subtle editorial distortion. The record should show who is unavailable, which route was selected, who authorized it and why. The mistake is to turn that unanswered question into an undefined power rather than using the stated escalation path.

The line a GitHub merge cannot cross

The RPC launched its kramdown-rfc pilot on 1 September 2025. Its stated goals included reviewing documents in a format increasingly used by authors and producing cleaner diffs focused on content changes. The initial plan accepted at least five requests per month and allowed the process to be refined before wider use.

By 2026, the public instructions called AUTH48 Final Review. The new name is more accurate. Forty-eight was not a deadline, and “author review” describes the purpose better than an inherited queue code. The GitHub surface also makes custody concrete: a branch holds RPC edits, issues preserve questions, pull requests show proposed changes, and the archive retains the conversation.

The repository for RFC-to-be 10025, the revision of the HTTP cookie specification, is a useful live specimen. Its README says the initial markdown is a copy of the Internet-Draft as it was approved for publication. RPC edits sit on a separate branch. Authors approve the content and formats. Area Directors approve changes that are beyond editorial. Working-group chairs and the document shepherd are invited into the review surface. The process can revert to email if a entity needs it.

As of 27 August 2026, the Final Review status page and repository were live, while the RFC Editor information URL for RFC 10025 returned 404. The repository showed fifteen issues and one pull request at the time of review. Those counts do not mean fifteen technical defects, fifteen objections or fifteen blocked decisions. They are only evidence that named review items existed on a visible work surface.

The status can change after this article's snapshot. That is precisely why a register should store an observation time and the authoritative URLs. In Final Review is a current state. Published as RFC 10025 will be a separate event only when the final record exists.

RFC 9991 and the keyword that needed an Area Director

An abstract rule becomes more credible when a real change crosses it.

During Final Review of the document that became RFC 9991, the authors proposed adding a BCP 14 keyword. Capitalized requirement language can affect technical meaning; it is not ordinary punctuation. In the public Final Review exchange, the RPC asked the responsible Area Director to review and approve the addition. The AD replied that it was approved.

The value of the record lies in its verbs. The authors proposed. The RPC identified a change requiring more authority and requested review. The Area Director approved. The RPC later published the RFC. None of those verbs can replace another.

If a monitoring system records only the final text, it cannot show whether a late normative change was merely copied in by an editor, agreed by authors or authorized by the stream. If it records only the AD's approval, it still cannot prove which final artifacts contained the approved wording. If it records only the RFC number, it loses the whole custody chain.

This example also protects the RPC from a false accusation. Escalation is not evidence that editors attempted to legislate. It is evidence that they recognized the limit of editorial authority and used the designated path.

Why 48 was never a deadline

The old name encouraged another category error. AUTH48 looked like a promise that final author review lasted 48 hours. It did not.

RFC 8963, an evaluation of a sample of RFCs produced in 2018, separated editing time, AUTH48 time and the interval from final agreement to publication. AUTH48 averaged more than one month in that sample, with large variation. The report described the phase in theory as final verification: authors approve the edited document or request a last correction. Coordination across authors and time zones, discussion of edits and competing priorities could extend it.

RFC 8700, the history of the RFC Series, records the long-running joke that AUTH48 could mean 48 days or 48 weeks. More importantly, it records the institutional lesson behind the present boundary: technical changes during the stage require approval from the relevant Area Director or stream manager.

The evidence does not justify calling every long review a failure. A complex document may deserve careful inspection; an unavailable author may require an alternate route; an IANA action, reference dependency, stream hold or tools problem may be the actual constraint. Duration is an indicator that asks a question, not a verdict that answers it.

The renaming to Final Review removes a misleading clock from the label. It should not invite an equally misleading political metaphor. The stage is neither a two-day timer nor a second election. It is controlled finalization.

The final-review receipt

A useful diligence record should be able to reconstruct the complete handoff without reading authority into a colored badge.

Field Evidence to preserve Why it matters
Approved source Exact Internet-Draft name, revision, bytes and hash Defines the content baseline accepted by the stream
Stream decision Stream, approving body, date and decision URL Identifies who had authority to approve publication
Queue handoff RPC receipt time and current state Separates approval from production custody
Edit set RPC branch, diff or edit-set hash Shows what changed after approval
Review items Question, actor, response and archival URL Makes uncertainty and resolution attributable
Change class Editorial, format, technical or otherwise beyond editorial Determines whether stream approval is required
Author approval Identity, scope and timestamp Proves review of the final content and outputs
Stream approval AD or other stream-manager receipt for substantive changes Prevents production custody from becoming content authority
External holds IANA, reference cluster, stream or tools state Prevents an author from being blamed for another dependency
Final artifacts HTML, PDF, TXT and XML hashes Binds approval to what readers will receive
Publication Announcement, RFC URL and publication time Proves that the RFC-to-be became an RFC
Adoption Implementation, tests and deployment evidence Keeps documentary authority separate from running reality

The receipt does not reduce editorial judgment to a machine. It makes each judgment answerable to the role that exercised it. A reviewer can then say exactly what remains open: one author has not approved the outputs; an RPC question awaits an answer; an AD must approve a technical addition; an IANA action is incomplete; or the final publication announcement has not yet occurred.

That language is less dramatic than “veto” or “second vote.” It is also far more useful to anyone deciding whether a specification can be cited, implemented, purchased or relied upon.

Sources

The RFC 10025 observations are fixed to 27 August 2026. The issue count is not treated as a defect count, and no publication date or outcome is predicted.