Internet-Draft AUTH48 Process Reform June 2026
Gerke Expires 19 December 2026 [Page]
Workgroup:
Individual Submission
Internet-Draft:
draft-gerke-auth48-process-reform-01
Updates:
2026bis, 7841 (if approved)
Published:
Intended Status:
Best Current Practice
Expires:
Author:
T. Gerke
Independent

Process Reform to prevent misuse of the AUTH48 State

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

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 19 December 2026.

▲

Table of Contents

1. 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.

1.1. Quality Assurance finished boilerplate

To prevent authoring Co-Area Directors and Co-Chairs from approving documents in whose development they are involved, they MUST NOT get access to set the boilerplate.

The "QA finished boilerplate" MUST only be issued upon the successful, sequential completion of a two-stage pre-freeze protocol verified by the Chair:

  1. Stage 1 ("Technically finished"): Enforces an immediate, immutable lock on all core specifications, preventing unauthorized late-stage technical modifications.
  2. Stage 2 ("Editorial changes completed"): Establishes a volatile window restricted solely to formatting and clarity improvements to assist the RFC Production Center (RPC).

Once the Chair has formally validated both stages, the system MUST automatically append the final consensus boilerplate to Paragraph 4 of 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.'

1.2. Conflict of Intrest

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:

  • 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.

2. The Three-Pillar-Model

2.1. The Dual-timer System

  • 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 MUST NOT be executed 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 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 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, no objections: 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 2026bis.
  • 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. 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.

    The process validation MUST be done by the IESG. No RFC publication SHALL be permitted until the statement is 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 RFC 2026bis, using the operational and consensus principles established in historical precedents such as RFC 8788.

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

Appendix A. Changes

Changes since Initial upload

Author's Address

Timo Gerke
Independent
Hamburg
Germany