Summary

  • The 29 September -09 revision of draft-gerke-publication-process-reform proposes updating RFC 6359 as well as RFC 7841 if approved. It remains an individual Internet-Draft at IESG state I-D Exists; neither RFC has been changed by the draft.
  • The two-stage freeze was already proposed in revision 08. The new development is the explicit connection between proposed state-integrity and write controls and RFC 6359's Datatracker tracking model, which reflects work whose authoritative status resides in separate systems.

The changed Updates line on the cover is consequential because the two cited RFCs do different jobs. RFC 7841 describes the RFC streams and the headers and boilerplate that identify their status. RFC 6359 describes visibility into IANA and RFC Editor processing after document approval. Adding the latter moves the proposal's asserted reach from publication markings into the machinery that reports later lifecycle states.

New section 1.2 makes that reach explicit. The author connects RFC 6359's Datatracker tracking pipeline to proposed automated state-integrity checks and restrictions on who may write after particular milestones. The revised abstract also speaks of programmatic milestones across existing and future core processing streams. Those are design claims in a draft. They are not evidence of a deployed access-control change or a decision by the owners of those streams.

The version comparison limits the claim of novelty. Revision 08 already contained the sequence of technical and editorial freezes, the proposed removal of IESG write privileges after IESG OK, and the staged limits on RPC editing. Revision 09 did not invent those steps. It enlarged the normative target and moved draft-ietf-procon-2026bis-11 from an informative to a normative reference. The referenced procon document is itself in working-group last call, with IESG state I-D Exists; its new place in a bibliography is not an approval or a publication guarantee.

RFC 6359 offers an important contrast. It set out to present a unified view of post-approval progress and reduce manual status handoffs. It also says that it does not define the processes used by the participating functions. IANA's own tracking system is authoritative for its post-approval status; the RFC Editor's system is always authoritative for RFC Editor status. Datatracker reflects those states. A mirror of independent queues and a gate that can stop edits across them are distinct governance roles.

That distinction does not make future validation in Datatracker inherently illegitimate. It asks who would authorise a gate for each stream, which body would classify a late change as technical or editorial, and where an exception or mistaken lock could be reviewed. The draft's intended Best Current Practice label and conditional Updates field answer none of those questions by themselves. No IETF consensus, IESG approval, RFC issuance or operational deployment follows from their presence.

Sources