Regardless of the stream the hope is that the technical work should be completed prior to entering the RFC editor queue.
In my time as ISE I’ve pulled one document back from the queue when it was clear there were substantial unresolved technical issues.
That said, the RPC often catches ambiguities or even technical issues through their questions. Sometimes implementations lead to issues that weren’t spotted earlier. ADs and chairs need to make a call about whether a change would break consensus, security, or interoperability of implementations.
Eliot 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 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]
|
