Dear RSWG,
Following the recent RPC report, it is evident that our current
monolithic process has reached a breaking point. I propose a fundamental
modernization of the STD and BCP series through unified temporal
versioning, while introducing a modular architecture exclusively for the
STD series. My core principle is: "A Standard is a Standard." Its
administrative maturity should be a metadata attribute, not a cause for
namespace fragmentation.
ABSTRACT
The primary objective of this proposal is to execute a major RFC
Namespace Cleanup. By migrating rigorous standards to a modular STD/BCP
framework and physically consolidating existing STD "collections"
(Sammelmappen), the RFC series can return to its original purpose: a
platform for documenting experiments, informational content, and
foundational discussions. We should not wait until we hit RFC 100,000 to
fix the architecture.
1. PERSISTENT IDENTIFIERS (ISO-Style) AND NAMESPACE CLEANUP
To ensure referential integrity, both series will adopt a stable,
persistent ID. Whether a document is a Proposed or Internet Standard, it
resides in the STD series from day one.
- BCP Series: BCP <no>:<year> (e.g., BCP 195:2026).
- STD Series: STD <no>[-part]:<year> (e.g., STD 1:2026).
Each revision MUST be accompanied by a unified diff (diff -u) for
maximum transparency.
2. MODULAR STD ARCITECTURE (Separation of Concerns)
The STD series shall adopt a multi-part structure to decouple stable
logic from volatile components:
- Part 1 (Core Specification): MUST contain the Core Specification and
only the Core Specification. It MUST NOT contain any
documentation of separable parts (SoC).
- Parts 2–8: MAY contain standard extensions, provided they have
reached 'Proposed Standard' level prior to the
Standard-Freeze.
- Part 9: Contains verified Test Vectors for Parts 1–8,
organized into dedicated chapters for each prior part to
ensure binary interoperability.
Surgical Withdrawal:
If a weakness in a specific module is identified and cannot be corrected
by a revision, this module MUST be marked as withdrawn.
Withdrawal Process:
If the responsible Working Group reaches a Rough Consensus regarding a
module withdrawal, the chair is requested to submit a withdrawal-request
to the IESG. Such requests MAY be approved by the Area Director (AD).
However, if the Working Group reaches a consensus on withdrawing an
entire Standard, the explicit approval of the Area Director (AD) is
REQUIRED. Upon IESG approval, the RPC MUST mark the module or the entire
standard as withdrawn.
2.1. IDENTIFIER LIFECYCLE AND SUFFIX HANDLING
To maintain permanent referential integrity, any document undergoing
revision (utilizing suffixes like BCP 195bis or STD 10-1bis during the
draft stage) MUST return to its stable identifier upon final
publication. The suffix is removed, and the new content is distinguished
solely by its temporal versioning (e.g., BCP 195:2026). This ensures
that all global references to the standard remain valid and resolve to
the latest "Single Source of Truth.
3. PROCESS WAIVER (Proven by Reality)
Maturity advancement (Header-Update) is driven by the absence of
technical Errata under sustained global deployment. The responsible
Working Group Chairs or Area Directors shall audit the Errata-Registry
as the primary empirical evidence. This "Proven by Reality" metric
replaces redundant bureaucratic "Implementation Reports," enabling a
swift transition to Internet Standard status.
4. SECURITY BY REFERENCE
Application standards shall mandate the "latest revision of the relevant
Security BCP," ensuring security updates propagate instantly without
re-spinning the entire stack.
5. PRESERVING TRADITION AND IDENTITY
This proposal is not an abandonment of IETF history, but its
restoration. By migrating rigorous, modular standards to the persistent
STD/BCP framework, we liberate the RFC series from bureaucratic
maintenance. This allows the RFC namespace to return to what it was
always meant to be: a vibrant record of experiments, informational
insights, and the fundamental discussion base of the Internet. We
preserve the tradition of the "Request for Comments" by giving it back
its original voice.
Appendix A: Practical Example (TLS 1.3 Baseline)
STD (TLS 1.3)
Part 1: Core Specification (Algorithm-agnostic Handshake/State
Machine)
Parts 2–5: Mandatory Crypto Modules (Key Exchange, Signatures, etc.)
Parts 6–8: Optional Extension Modules (ECH, SNI, etc.)
Part 9: Strict Compliance Profile (SCP) (Test Vectors and
Environments for Parts 1 to 5, chapter-separated)
Part 10: Extended Compliance Profile (ECP) (Test Vectors and
Environments for Parts 6 to , chapter-separated)
Parts 11-18 modules mot defined yet
Part 19 Test Vektor and Environments for modules 11-18
Best regards,
Timo Gerke
(Collaborator, 2026bis)
--
Timo Gerke
Lohkoppelweg 40
22529 Hamburg
Germany
Fon: +49-40-24433033
Fax: +49-40-22628453
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]
