Publication Process Reform to prevent misuse of AUTH48 or equivalent states Independent
Hamburg Germany ietf@timogerke.de
Individual Submission 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.
The objective of this document is to update the publication process regulations defined in and the overarching principles of . 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 when, and only when, they appear in all capitals, as shown here.
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.
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.
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 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.
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.
  • 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.
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.
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.
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.
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 , 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 .
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.
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 . 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.
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 .
The Internet Architecture Board (IAB) serves as the supreme constitutional appeal and oversight body under . 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.
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.
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 , 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.
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.
There are no requests to IANA.
The author respectfully thanks:
  • John Levine, for arciteectural review
  • Jean Mahoney, for operational requirements review
  • Rich Salz, for compatibility review with RFC 2026 successor
  • Changes since draft-gerke-auth48-process-reform-00
    • Transformed entire document to RFCXML
    • Introduced two-stage freeze system
    • minor issues
  • Changes since draft-gerke-auth48-process-reform-01
    • Added required Sections Introduction, Security and IANA considerations, References.
    • Updated two-stage system (
      1. WG Stage
      2. IESG reviews and sets boilerplate
    • Added definition of total recusal to .
    • Refined IAB States in
    • Correctied/Added inter-section references
    • Inserted new Process-related permissions and duties of IESG, IAB and RPC