Hi all,
On 5/9/26 12:13 PM, Eric Rescorla wrote:
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.
[JM] Cluster 430 has been rolling for a while. The listing of published
RFCs for a cluster is a known issue that will be fixed with the new
queue software. Once a document is published as an RFC (which is
indicated by the "PUB" state on the cluster page), it is no longer
considered a cluster dependency. For more information about clusters,
please see https://www.rfc-editor.org/about/clusters/
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
[JM] Documents in Cluster 496 also have a dependency on rfc8446bis:
https://www.rfc-editor.org/cluster_info.php?cid=C496
Best regards,
Jean
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 <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]
<mailto:[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] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
