Internet-Draft Publication Process Reform July 2026
Gerke (Ed.) Expires 20 January 2027 [Page]
Workgroup:
Individual Submission
Internet-Draft:
draft-gerke-publication-process-reform-00
Updates:
I-D.ietf-procon-2026bis, 7841 (if approved)
Published:
Intended Status:
Best Current Practice
Expires:
Author:
T. Gerke (Ed.)
Independent

Publication Process Reform to prevent misuse of AUTH48 or equivalent states

Abstract

This document updates the AUTH48 or equivalent process by introducing deterministic state-integrity constraints within the IETF Datatracker architecture. It establishes automated validation milestones and explicit access controls to prevent late technical modifications after the Working Group Last Call, thereby safeguarding the Rough Consensus.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 January 2027.

Table of Contents

1. Introduction

The objective of this document is to update the publication process regulations defined in [RFC7841] and the overarching principles of [RFC2026bis]. Historically, this phase has lacked state-integrity constraints, allowing late-stage technical modifications. This document establishes a deterministic framework to prevent Working Group bypassing and safeguard the consensus. By applying a two-stage freeze system within the Datatracker architecture, these vulnerabilities are resolved.

Specifically, this mechanism enforces an immediate technical lock on core specifications (Stage 1) while isolating a volatile window for strictly editorial adjustments by the RFC Production Center (Stage 2). Sequential verification of both stages by a non-conflicted Chair or AD triggers automated consensus validation and Datatracker state processing metrics.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Quality Assurance

This section defines the multi-stage validation criteria and deterministic milestones required to establish a verified quality assurance state prior to the initiation of the formal publication pipeline.

2.1. Technical QA finished boilerplate

The global Technical Quality Assurance (QA) SHALL operate as a strict two-stage validation hierarchy tied to the Datatracker state machine:

The Working Group Chair MUST NOT submit a document to the IESG for review until the technical quality assurance boilerplate has been formally granted and recorded within the Datatracker.

Stage 1 - Working Group Consensus: The non-conflicted Co-Chair MUST verify and confirm the Working Group Consensus. Upon verification, the system SHALL programmatically freeze the document. Following this technical lock, the document is released for formal submission to the IESG, pending manual acknowledgment to transition the system to the IESG ACK state.

Stage 2 - IESG process validation: This stage consists of a mandatory manual audit by the IESG to verify exclusively that the Rough Consensus regarding both the initial document adoption (if applicable) and the conclusion of the QA process was correctly determined by the Working Group leadership. Upon successful collective validation within the IESG REV state, the system SHALL automatically insert the following consensus boilerplate as the last paragraph of the "Status of This Memo" section:

"The responsible Working Group has reached rough consensus that the technical quality assurance was completed. The Internet Engineering Steering Group (IESG) successfully validated the process."

Upon entering the IESG OK - Document ready for publication state, the global QA process is complete, and the document SHALL be transferred to the RPC for final editorial processing.

2.2. Conflict of Interest

The Datatracker MUST synchronize all state changes of the technical quality assurance boilerplate directly with the responsible Working Group.

To ensure full transparency and prevent administrative bypasses, the following automation MUST be enforced:

  • Automated Mailing List Broadcast: Any transition to an approved boilerplate state or an automatic operational lock state MUST trigger an immediate, automated notification to the Working Group's official mailing list.

  • Recusal Transparency: If the exception path from Section 2.1 is triggered due to total recusal, the justification and the identity of the acting Area Advisor MUST be published openly in the WG Datatracker history.

The Working Group retains the ultimate authority to challenge any state transition through the standard consensus mechanics if the recorded state does not reflect the actual technical consensus of the room.

2.3. Last Call Control

A Chair or Area Director SHALL NOT be permitted to:

  • Initiate a Working Group Last Call while another Last Call is active in this Working Group
  • Initiate any new Last Calls within the Working Group while any document in that Working Group remains in the IAB OK - Review done, WG action required state.

3. The Three-Pillar-Model

3.1. The Dual-timer System

  • 30-day timer: A document MUST be finalized within 30 days from entering the AUTH48 or equivalent state.
  • 10-day timer: This shorter window is automatically triggered once all authors have signaled all technical work is done.
  • The document is published at the end of timer one or two (whichever occurs first).

With explicit authorization of the IESG, the 30-day timer can be extended by maximum of ten days overall.

3.2. Normative Splitting

After the 30-day timer expires, the RPC SHALL automatically split the cluster. Documents without normative references on the blocker SHALL be released and published immediately.

3.3. Process Integrity and Automatic Reset

Quality assurance MUST be done before Working Group Last Call and MUST NOT be executed in the AUTH48 or equivalent state. The RPC is authorized to make editorial changes only.

To safeguard technical competence, the IESG MUST NOT evaluate or make decisions for any document or process if both responsible Area Directors are unavailable. Priority SHOULD be given to consulting an Area-Advisor to enable the remaining IESG to make a qualified decision.

If time permits, consideration of the document or process SHOULD be deferred to the next scheduled IESG meeting or telechat.

If both Area Directors remain unavailable, no qualified decision can be reached via Advisor consultation, or deadlines do not permit deferral, approval authority MUST be escalated to the Internet Architecture Board (IAB) to appoint a neutral, independent reviewer.

4. Changes to Datatracker

To ensure absolute transparency, prevent unmanaged out-of-band disclosures, and safeguard the consensus-finding process, the IETF Datatracker MUST structurally enforce deterministic system states. These granular states strictly isolate the operational review mechanisms from the judicial escalation channels, establishing an unalterable, verifiable ledger of all procedural milestones.

4.1. IESG Level

The IESG MAY decide to initiate a parallel dual-review on complex topics consisting of two isolated entities, where at least one entity MUST be external. This decision MUST be formally documented. If all Area Directors assigned to the document are conflicted or unavailable, the model as described above is MUST be applied.

Following Datatracker states MUST be instated or renamed:

  • IESG QUE

    • Queued for acknowledgement: Set automatically by the system upon Working Group Chair submission, pending manual acknowledgment.

    • Queued for review: Set automatically after acknowledgement, pending reviewing entity assignment.

  • IESG ACK - Acknowledged: Indicates that the document was recieved has completed formal vlidation (Sanity Check). This state SHALL NOT last longer than five business days.

  • IESG REV

    • Assigned to reviewing entity: Indicates that the uncompromised reviewer entity - or, if triggered by the criteria as defined in Section 2.2, the parallel internal and external reviewer entities - has taken formal charge of the ledger, initiating the confidential evaluation period.

    • Review done, no objections: Confirms that the collective body has cleared the entity without technical caveats and that all active parallel review metrics show no unresolved structural variance.

    • Review done, WG action required: This state SHALL log a structured list of formal deficiencies within the Datatracker, which SHALL automatically return the docket to the community for resolution.

    • WG action verified, no objections: This state SHALL document the final and successful collective validation of the working group's delta-revisions against the logged deficiencies.

  • IESG OK

    • Document ready for publication:The activation of this state SHALL programmatically execute the immediate and irreversible handover of the document object to the RFC Editor Queue. Upon execution, only the RPC SHALL be allowed to make changes to the document.

    • Process clearance granted: This state SHALL activate the executive authorization for the requested procedural variance, concluding the IESG-level exceptional review.

  • IESG EPR - Exceptional Process requested by WG: This state SHALL record the transparent import of a working group's formal petition for an out-of-band mechanism outside the scope of [RFC2026bis].

On complex topics, the IESG MAY consider consulting the IAB for process validation. The IESG SHALL NOT be authorized to disclose the name of the reviewing entity even to the authors.

The process validation MUST be done by the IESG.

4.2. IAB Level

The architectural and procedural clearance stream under the jurisdiction of the Internet Architecture Board (IAB) SHALL enforce a deterministic, linear state machine. This high-level governance structure strictly isolates the contituinal final approval from the operational production mechanisms of the IESG Level specified in Section 4.1.

Unlike the operative pipeline, the IAB workflow SHALL NOT inherit volatile technical review states. Instead, the Datatracker SHALL programmatically restrict the IAB stream to architectural verification, structural consultation metrics, and unalterable final publishing clearances. The following granular states SHALL be instated:

  • IAB QUE - Queued for process validation: This state SHALL be set when the IESG sent a process validation request. The state SHALL be set automaticly after the request has been placed in the queue.

  • IAB ACK - Acknowledged: This state SHALL be set manually only by the chair or any chair-authorized member. This state SHOULD NOT last longer than 5 business days.

  • IAB CON

    • Consultation request recieved from IESG: This state SHALL be set after the IESG formally requested an IAB consultation.

    • Consultation scheduled: This state SHALL be set when IAB and IESG made am appointment for consultation.

  • IAB OK

    • Decision made and published: This state SHALL freeze the final judgment of the board and SHALL immediately and permanently commit the unalterable response into the public Datatracker log.

    • Document sent to IESG for publication: This state SHALL activate the executive transfer of the cleared technical or architectural payload back to the operational stream for final printing.

    • Exceptional process validated, clearance can be granted: This state SHALL ratify the highest-level structural approval for a disputed out-of-band mechanism, formally notifying the IESG that executive clearance may be executed.

5.1. Permissions and duties of the IESG

The Internet Engineering Steering Group (IESG) acts strictly as a procedural state-transition authority within the Datatracker ecosystem. The IESG's operational boundary is tightly confined to the states IESG QUE, IESG ACK, and IESG REV.

Upon triggering the state transition to IESG OK - Document Ready for publication, all write and update permissions for the IESG regarding the document object model and its metadata in the database matrix MUST be instantly and irreversibly revoked by the automated backend middleware. The IESG SHALL NOT exert any further administrative or informal influence over the document lifecycle, in strict compliance with the absolute non-interference directives defined in Section 4.1.

5.2. Permissions and duties of the IAB

The Internet Architecture Board (IAB) serves as the supreme constitutional appeal and oversight body under Section 8.7 of [RFC2026bis]. The IAB's jurisdiction over active document streams is strictly bounded by deterministic, non-extendable procedural timer events.

Upon the filing of a formal appeal, the IAB Secretariat MUST enforce a strict, unalterable maximum three-week (21 days) response window for the targeted functional body to deliver its official response matrix. Any technical evidence submitted to the file MUST be categorized as integral background context material and MUST be unedited and fully disclosed to the public archive immediately upon the expiration of the 21-day evaluation window, ensuring a complete and unalterable audit trail.

5.3. Permissions and duties of the RPC

The RFC Production Center (RPC) acts as the sole primary enforcer and transactional execution authority of the publishing pipeline across all five processing streams (IETF, IRTF, IAB, Independent, and Editorial) once a document enters the state IESG OK - Document ready for publication or its stream-specific equivalent]. The RPC's duty is strictly confined to editorial refinement and SHALL NOT alter the technical meaning of the text.

To eliminate manual handling vulnerabilities and out-of-band interference during the AUTH48 or equivalent phase, the RPC's execution matrix is hardcoded into two discrete, sequential processing phases within the database matrix:

  • Phase 1: RPC Editorial Review: The document enters the exclusive editorial jurisdiction of the RFC Production Center (RPC). During this state, only editorial modifications SHALL be processed.

    Any technical or structural modification attempted via API or Web-Interface during the AUTH48 or equivalent state without procedural permission is REQUIRED to be blocked.

  • Phase 2: Publication Queue: Upon completion of the editorial review and receipt of all required stream and author approvals, the document transitions automatically to this terminal processing block. The database object transitions to an immutable state, and all global write privileges MUST be instantly and completely revoked by the automated backend middleware, extinguishing editing capabilities for all human actors. The document remains frozen until the core repository execution layer via an automated system transaction assigns the sequential, permanent RFC number and executes the final commit, rendering the publication process fully indisputable.

6. IESG Requested Actions

To safeguard Quality Assurance and Exceptional Process Quality, the IESG is requested to issue two statements:

  1. Quality Management Requirements

    1. describing assurance and process validation criteria,

    2. keeping the statement up to date.

    Only already piplined documents SHALL be published.

  2. Exceptional Process Baseline Requirements

    1. defining baseline requirements for exceptional processes and their validation procedures,

    2. keeping the statement up to date.

    The absolute baseline for these requirements is the direct comparability to Section 8.7 of [RFC2026bis], using the operational and consensus principles established in historical precedents such as RFC 8788.

    On complex topics the [RFC8788] IESG MAY consider consulting the IAB for process validation.

7. Security Considerations

This document introduces purely procedural state-machine modifications affecting the synchronized workflows between the IETF Datatracker and the RPC. It does not define cryptographic or transport-layer mechanisms. The proposed states enforce the following systemic security and integrity invariants:

  1. Access Control: Restricting manual state overrides (such as IESG ACK and IAB ACK) strictly to chair-authorized members programmatically eliminates unauthorized operational log modifications.

  2. Payload Integrity: The programmatic technical lock executed upon entering the Working Group Consensus state safeguards the document against late-stage, out-of-band normative tampering.

  3. Resource Availability: The strict five-business-day turnaround limits applied to the automated input queues structurally prevent administrative deadlocks and state-exhaustion vectors.

8. IANA Considerations

There are no requests to IANA.

9. Normative References

[RFC2026bis]
Salz, R. and S. O. Bradner, "The Internet Standards Process", Work in Progress, Internet-Draft, draft-ietf-procon-2026bis-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-procon-2026bis-11>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7841]
Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, , <https://www.rfc-editor.org/info/rfc7841>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8788]
Leiba, B., "Eligibility for the 2020-2021 Nominating Committee", RFC 8788, DOI 10.17487/RFC8788, , <https://www.rfc-editor.org/info/rfc8788>.

Appendix A. Acknowledgements

The author respectfully thanks:

Appendix B. Changes

Author's Address

Timo Gerke
Independent
Hamburg
Germany