On Sat, Jul 4, 2026 at 1:43 AM Eliot Lear <[email protected]> wrote: > &TL;DR; the cure will cause interoperability problems. > I largely concur with Eliot: trying to slice things this finely will lead to a less useful output rather than a more useful one.
Let's take the concrete example of algorithm definitions in TLS 1.2. When RFC 5246 was first published in 2008, it specified a given set of symmetric ciphers, including: - AES-GCM (MTI) - RC4 - 3DES In 2015, we published RFC 7465 deprecating RC4 and then in 2016 we published RFC 7905 adding ChaCha-Poly. These RFCs are both currently marked as updating RFC 5246, but as I understand this proposal, in the future we would mark RFC 7465 as "Amends" because it introduces a "mandatory" change to the protocol (it has a MUST NOT) whereas RFC 7905 would be "Extends" because it just adds a new code point, even though what they're both doing is changing the list of algorithms. This seems more confusing than helpful, because it's arguably equally important to know that you ought to implement ChaCha-Poly as that you ought not to implement RC4, but these marking sugest it is less important. More broadly, this is at best a band-aid for the underlying problem, which is that the structure of our published artifacts is a poor match for the protocols we are defining. The question that is important to implementors is: What do I have to do to implement protocol X? And instead of giving them a document that they can read, we tell them something like: Go read document X, as modified by documents, A, B, and C. With the readers being forced to then read A, B, and C and try to figure out how to apply them as patches on X. This document proposes to make this more complex, something like: Go read document X, as modified by documents, A, B, and C. You really need to read A, B offers some extensions, and you might also want to read B and C. This seems less helpful, rather than more. In many cases (as in the ChaCha-Poly) you're going to really want to read B, but this notation discourages you from doing so. This is a well-known structural problem in our documents, but the first rule of holes, as they say, is to stop digging. Instead of continuing to dig, it would be more helpful for this WG (perhaps in concert with IETF) to work to reduce the need for this structure of "main document + patch documents" (see previous discussions [0] about "dot releases" for RFCs, simpler errata, etc.) rather than trying to more finely slice the meaning of each patch. -Ekr [0] https://mailarchive.ietf.org/arch/msg/rswg/ndYqxopxJYXTgX8ivhWQT-eJ8V8/
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
