On Tue, Dec 10, 2024 at 12:47 PM Eliot Lear <l...@lear.ch> wrote: > And this is where we run into problems, because the moment you change that > boiler plate, you will devalue the RFC series and create support and > interoperability problems as people end up implementing different versions > of a specification. And to be clear, IANA is the LEAST of our problems. > The IETF needs a way to have not-ready-for-prime-time DRAFT work without > fear ofcreating a mess. > I think this assumes facts not in evidence.
Of course, we don't have the controlled experiment of removing the boilerplate, but what we *do* have is the experience of WGs/communities who have done Internet scale deployment based on I-Ds (HTTP/2, TLS, QUIC, WebRTC) and then successfully transitioned the community over to the eventual RFC. At least some of those communities are also the ones who permit code point registration based on I-Ds (TLS, QUIC) and have not in fact experienced the issues you raise about confusion about what to implement. Obviously, opinions may vary, but in my experience, is to take a more flexible approach to the coordination problem, namely, having robust mechanisms for distinguishing which version someone is implementing and handling that situation appropriately (e.g., in the case of draft versions of TLS 1.3, negotiating TLS 1.2). This allows for some version diversity prior to RFC publication but also allows the community to converge on the new published version once it exists (which, as I said, we have done successfully in the cases above). You're of course free to believe that this was somehow facilitated by the disclaimer on the top of the I-Ds, but that's not my belief, nor, I suspect, of many others who have been heavily involved in the aforementioned transitions. I do appreciate that there are (principally non-interactive) protocol settings where this type of mechanism does not work as well, and it's possible that your argument above has some force, but I'd like to see some evidence of that beyond your assertion of it. -Ekr
_______________________________________________ rfc-interest mailing list -- rfc-interest@rfc-editor.org To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
