Individual Submission T. Gerke Internet-Draft Independent Intended Status: Best Current Practice June 16, 2026 Updates: 2026bis (if approved) Expires: December 18, 2026 Process Reform to prevent misuse of the AUTH48 State draft-gerke-auth48-process-reform-00 Abstract This document proposes a modernization of the AUTH48 process to actively protect the Rough Consensus. It introduces deterministic timers and clear Datatracker states to prevent late technical changes after the Working Group Last Call. Status of This Memo Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Quality Assurance 1.1 The "QA finished boilerplate" To prevent authoring Co-Area Directors and Co-Chairs from approving documents in which development they are involved, they MUST NOT get access to set the boilerplate. A "QA finished boilerplate" SHOULD be established creating this text in the "Status of this Memo" section: "The responsible Working Group has reached a rough consensus that the quality assurance was completed. The Internet Engineering Steering Group (IESG) has validated the process." If granted, the document will automatically be frozen. The Chair MUST be granted a way to initiate a Working Group Last Call based upon a provided template. 1.2 Conflict of Interest Authoring Co-ADs and Co-Chairs MUST NOT be able to approve documents in whose development they are involved. Evaluation of consensus and final approval MUST be executed exclusively by a non-conflicted Co-Chair or Co-AD. If all assigned Chairs and ADs of the respective Working Group and Area are conflicted, approval authority MUST be escalated to the Internet Architecture Board (IAB) to appoint a neutral, independent reviewer to evaluate the consensus and grant the boilerplate. As a safeguard against accidental escalation, a joint non-conflicted Co-Chair and Co-AD MUST approve each other's action within a strict 72-hour window before the notification is dispatched. 1.3 Last Call Control A Chair or Area Director MUST NOT be able to: a) Initiate a Working Group Last Call while another Last Call is active in this Working Group. b) 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. 2. The Three-Pillar Model 2.1 The Dual-Timer-Model - 30-day Limit: A document must be finalized within 30 days from entering the AUTH48 state. - 10-day Trigger: 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. 2.2 Normative Splitting After the 30-day timer expires, the RPC shall automatically split the cluster. Documents without normative dependencies on the blocker MUST be released and published immediately. 2.3 Process Integrity and Automatic Reset Quality assurance MUST be done before Working Group Last Call and NOT in the AUTH48 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. 3. 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. 3.1. IESG Level The operational stream under the jurisdiction of the Internet Engineering Steering Group (IESG) MUST enforce the following deterministic states to manage regular document workflows and exceptional working group requests. 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 required. Following Datatracker states MUST be instated or renamed: - IESG ACK - Accepted for Review: This state MUST conclude the formal import of the docket into the IESG evaluation queue and SHALL automatically trigger the official evaluation timers. - IESG REA - Reviewer assigned: This state MUST indicate that the uncompromised reviewer entity—or, if triggered by the criteria above, the parallel internal and external reviewer entities—have taken formal charge of the ledger, initiating the confidential evaluation period. - IESG OK - Review done, no objections: This state MUST confirm that the collective body has cleared the entity without technical caveats and that all active parallel review metrics show no unresolved structural variance. - IESG OK - Review done, WG action required: This state MUST log a structured list of formal deficiencies within the Datatracker, which SHALL automatically return the docket to the community for resolution. - IESG OK - WG action verified and correct: This state MUST document the final and successful collective validation of the working group's delta-revisions against the logged deficiencies. - IESG OK - Document ready for publication: This state MUST freeze the technical payload and SHALL immediately release the document stream to the RFC Production Center (RPC) for final publishing. - IESG EPR - Exceptional Process requested by WG: This state MUST record the transparent import of a working group's formal petition for an out-of-band mechanism outside the scope of RFC 2026. - IESG OK - Process clearance granted: This state MUST activate the executive authorization for the requested procedural variance, concluding the IESG-level exceptional review. 3.2. IAB Level The judicial and architectural escalation stream under the jurisdiction of the Internet Architecture Board (IAB) MUST enforce a deterministic state machine symmetrical to the IESG Level specified in Section 3.1. The IAB workflow SHALL inherit all operational states, definitions, and dual-review mandates from Section 3.1, substituting the "IESG" prefix with "IAB", with the following mandatory extensions and structural variances: - IAB OK - Decision made and published: This state MUST freeze the final judgment of the board and SHALL immediately burn the unalterable response into the public Datatracker log, concluding pure procedural appeals. - IAB OK - Document sent to IESG for publication: This state MUST activate the executive transfer of the cleared technical or architectural payload back to the operational stream for final printing. - IAB OK - Exceptional process validated, clearance can be granted: This state MUST ratify the highest-level structural approval for a disputed out-of-band mechanism, formally notifying the IESG that executive clearance may be executed. 4. Requested IESG Actions To safeguard Quality Assurance and Exceptional Process Quality, the IESG is requested to issue two statements: a) Quality Management Requirements aa) describing assurance and process validation criteria, ab) keeping the statement up to date. The process validation MUST be done by the IESG. No RFC publication SHALL be permitted until the statement is published. b) Exceptional Process Baseline Requirements ba) defining baseline requirements for exceptional processes and their validation procedures, bb) keeping the statement up to date. The absolute baseline for these requirements is the direct comparability to RFC 2026bis, using the operational and consensus principles established in historical precedents such as RFC 8788. On complex topics the IESG MAY consider escalating to the IAB for process validation. 5. Authors' Addresses T. Gerke Independent Hamburg, Germany Email: timo.gerke@alice-dsl.net