On Mon, May 18, 2026 at 7:21 AM Eliot Lear <[email protected]> wrote: > > On 18.05.2026 14:42, Eric Rescorla wrote: > > As I said, i don't think this is addressing the primary problems with > mapping specifications onto RFCs, which are much more about > the ability to progressively revise than imposing some sort of > meta-structure. > > I'd like to see us focus on that ability to progressively revise > specifications. Is that something we might want to grab a room to discuss > in Vienna? I'm thinking about the following: > I won't be in Vienna, but might be able to call in.
> - What are the process limits? > - What are the tooling limits? > - Are the requirements of all levels of the stack the same? > - Related, what are the necessary interoperability requirements? > > I think there are actually a number of related issues: - Non-semantic changes (editorial issues, errata, etc.)? - Semantic changes that aren't really new versions (e.g., RFC 8446-bis, which is largely a clarification of 8446, but does in fact contain new normative text)? - New versions My put for non-semantic changes is: https://datatracker.ietf.org/doc/draft-rescorla-rfc-jit/. I suspect we'd need different processes for the other two. -Ekr > > > What I would like NOT to do would be to create the IETF version of the > NPM/Pypi dependency mess. > > Even if we keep the process the same, can we improve other aspects, like > how readers view errata or evolutions of works like TLS. We've got another > one coming: TEAPv2. We don't need to rewrite *all* of TEAP, but rather > do some incremental changes. > > Thoughts? > > Eliot >
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
