I think the two problems EKR describes are different and separable.
The first problem, somehow providing an umbrella that actually makes it is easy to figure out what all the pieces of protocol X (SMTP, HTTP, BGP,...) are is a useful result. It is however one that we have failed on multiple times, for multiple reasons (some good, some in my opinion bad, but multiple efforts and multiple failures.)
On the other hand, being able to easily update RFCs, with the kind of distinction EKR describes below, far more easily than we currently can seems like a good idea. As Jay suggests, some of the errata handlign moves the ball a little on this front. I think we can do more, and be careful to make sure we keep the requirements for consensus clear.
While I can imagine interaction between those two, it is not all obvious that such interaction is necessary. Admittedly this is in part because I think there are good reasons to sometimes keep document separate but related, so the umbrella need is not always addressed by revising the base document. Guessin which of the two will turn otu to be easier is beyond my crystal ball. I am however confident that tying them together will be harder.
Yours, Joel On 7/8/2026 5:40 PM, Eric Rescorla wrote:
On Wed, Jul 8, 2026 at 1:46 PM John R Levine <[email protected]> wrote: >> I largely agree, and think this is worth a LOT of time exploring. > > But as John Klensin may well remind us, this is a very long-standing > problem that the IETF side of the house has failed to tackle for the > last 25 years or so. It will take something amounting to a revolution > to make significant changes. Oh, I know, starting with the question about whether immutable RFCs is a sacred principle, or just a leftover from the era when they were mimeographed. I wonder if there is an opportunity to sidestep this question at least temporarily by focusing on principles and then later trying to map them onto the RFC series. My starting point here would be something like: - We want a single reference that somehow points to the collective set of information that you need to implement a protocol. The target of the reference needs to evolve as the protocol evolves. - The important (main?) pieces of the protocol should be specified in a single coherent document. This may include things that are formally extensions but really are needed. For example, in TLS you might want to pull in SNI, because it's needed almost all the time. This may change over time; for instance a new algorithm might be added as an optional extension but then become dominant and so be moved into the main document. I'm not quite sure where exactly to draw the line here, hence the handwaving above. - It should be easy to update documents for comparatively minor changes. In a previous message, I provided a taxonomy of updating, so I don't want to go into it again here, but perhaps it would be easiest to think in terms of timelines and effort levels. For example, fixing an obvious typo should be very easy and shouldn't take more than a day or two. Non-semantic clarifications might take a little longer, semantic changes would need something more like the IETF Consensus process, etc. [0] I'm not trying to hide the ball: I think the right way to handle this is with dot revisions of RFCs (e.g., RFC XXXXX.VV), but you could also handle this with some construct that sat on top (SPEC 1234, which points to an RFC or a set of RFCs). But as I said above, perhaps we can defer that debate and see if we can agree on some principles at the level of the above--though most likely not exactly these--and then use that to work through the mechanics. What do people think? -Ekr [0] As I've mentioned previously, if we make it technically easy to make updates, then this lowers the risk of an inappropriate update sneaking through, as we can reverse it.
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
