What sort of changes are allowed during AUTH48 is ultimately up to the streams, not the RSWG. For example, the ISE doesn't even have a consensus process.
With that said, your description of the situation with C430 [0] is not accurate. Most of the documents in this cluster have already been published (hence the PUB state). It's not quite clear to me why all of these are listed in a single cluster, as it's kind of confusing. There are 4 documents in AUTH48-DONE-R* waiting for the completion of draft-ietf-tls-rfc8446bis-14 [1]. As a practical matter, in this particular case all of these documents could just reference RFC 8446 and be published immediately, just as we did with RFC 9849. -Ekr [0] https://www.rfc-editor.org/cluster_info.php?cid=C430 [1] draft-ietf-tls-keylogfile-05.txt draft-ietf-tls-tls12-frozen-08.txt draft-ietf-uta-require-tls13-12.txt draft-ietf-tls-8773bis-13.txt On Sat, May 9, 2026 at 3:29 AM Timo Gerke <[email protected]> wrote: > Helloo RFC Series Working Group, > > As suggested by Eliot Lear during the initial GENDISPATCH discussion, I > am moving this disvussion for a procedural reform of the AUTH48 process > to this group. The goal is to provide predictability, protect consensus > integrity, and eliminate unnecessary administrative overhead for Area > Directors and Chairs. > > The Axiom: > Quality assurance MUST be done in the WG stage and NOT in the > AUTH48 state. > > If a document requires substantial technical changes or a late-stage > redesign after leaving the IESG evaluation, the current process has > failed earlier. Misusing AUTH48 as a hidden extension of the Working > Group stage bypasses the rough consensus of the community and introduces > severe systemic risks, as currently demonstrated by Cluster C430. > > The Problem: "Not Working Process" in Cluster C430 > Currently, a single document undergoing a late-stage technical overhaul > can hold an entire cluster hostage. In Cluster C430, 24 documents are > eady for publication (in PUB or AUTH48-DONE state) but have been > stalled for over five months because one primary blocker > (draft-ietf-tls-rfc8446bis) is stuck. > > Interestingly, for this primary blocker, IANA has already signaled > "OK - Actions required", proving that the technical core parameters are > officially validated. There is no logical or procedural justification > for a five-month editorial delay blocking 24 completely unrelated > documents. > > The Proposal: The Four-Pillar Exit Strategy > > - The Dual-Timer-Model > -- 90-day Limit: A document must be finalized within 90 days from > entering the AUTH48 state. > -- 30-day "Final Approval" Trigger: This shorter window is > automatically triggered once an author signals "No actions required > by the RPC". > > - Normative Splitting: After the 90-day timer expires, the RPC shall > automatically split the cluster. Documents without normative > dependencies on the blocker MUST be released and published > immediately. > > - Process Integrity and Automatic Reset > Quality assurance MUST be done before the Last Call and NOT in the > AUTH48 state. To prevent late-stage redesign and safeguard the rough > consensus, the RPC MUST be authorized to make editorial changes > only. Consequently, any substantial changes or rollbacks are > impossible during the AUTH48 state and MUST automatically trigger a > return of the document to the Working Group stage and require a full > re-approval by the IESG. Any extension of the AUTH48 state MUST NOT > exceed 10 business days and requires explicit approval by the IESG. > The RPC SHOULD inform the responsible Area Director about the > required return. > > By transforming a political, person-dependent intervention into an > automated, deterministic workflow, we protect the RPC, secure the > original WG consensus, and significantly reduce the workload for all > ADs and Chairs. > > I look forward to discussing how we can integrate these algorithmic > guardrails into the RFC Series policy. > > Almost any process manager MAY NOT argue against this > > Best regards, > > Timo > -- > > If you think technology can solve your security problems, > then you don't understand the problems and you don't > understand the technology. > Bruce Schneier, amerikanischer Kryptograph > > -- > rswg mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
