On Wed, Dec 11, 2024 at 11:38 AM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > Eliot Lear <l...@lear.ch> wrote: > > deadwood-lear-widget-update-protocol, and as you wrote below, > appropriate > > boiler plate is applied. Something along the following lines: > > > “This document was previously an Internet-Draft, was not accepted for > > publication as an RFC, and has not been shown to meet any quality > > standard. Any specification contained herein may not be suitable for > > deployment. It will *not* be updated, no errata can be filed > against it, and > > there may be intellectual property risks associated with > implementations. It > > is not suitable as a normative reference for a standard.” > > > This has the following benefits: > > As someone who feels uncomfortable with I-Ds being cited for Specificatiion > Required, I'll buy this. > > I'm not all, btw, sure that EKR's demonstration of I-Ds being stable for > QUIC, TLS, etc. is relevant. What it sounds to me like is the WGs > essentially did an early allocation. Some of these were early allocations and in other cases (e.g., TLS version numbers) we deliberately burned a code point. > Since there was a designated expert > involved, and the requestors were likely all known to the DE, it was an in > family event. I don't recall that there were designated experts involved, though I agree it was largely an in family event. Had someone else come along and asked for values, I doubt they > would have been allocated. > There are actually several cases here: 1. Allocations from existing registries (e.g., the TLS Extension space). 2. Allocations from new spaces (e.g., TLS version numbers). For example, for TLS 1.3, we allocated a new TLS "supported_version" extension code point and then new TLS 1.3 draft version code points to go in it. We would have allowed people to get their own extension code points according to the then current rules, which, at the time, I believe precluded drafts. However, subsequently, when we did ECH, we allocated a new TLS extension out of a registry where we had already relaxed the code point allocation rules. But honestly, I think these are kind of irrelevant details. My point is rather that the community--or at least the TLS and QUIC communities--are quite capable of distinguishing drafts from standards and switching from one to the other, even when the draft is deployed at Internet scale, and it doesn't have anything to do with the boilerplate. -Ekr > > This is not to say that drafts can't still get code point > assignments, but > > that those assignments should clearly be marked as for development > purposes. > > > Who would want to use deadwood? > > > * Those who want to document their work for purposes of a code point > > assignment and don't have a better place to store it. > > > * Anyone who wants to document work that didn't make it to RFC ( have > > one such work in mind for now ). > > I'm halfway through reading RFC9049. > I think it's useful to have written this. > I don't know what the incremental expense of having published this as an > (IRTF) RFC vs having left it as deadwood is. I suspect that it would have > cheaper as deadwood, both as cost to the IETF and to the authors. > > > Would it be better than github? Github has the same sort of > versioning > > problems that I-Ds have. > > It would great if we could have an IETF gitlab, so that we could argue less > about github vs git. Document repos on *github* become attractive > nuissances, making people not familiar with the IETF process think they can > write PRs long after the document has become RFC. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > _______________________________________________ > rfc-interest mailing list -- rfc-interest@rfc-editor.org > To unsubscribe send an email to rfc-interest-le...@rfc-editor.org >
_______________________________________________ rfc-interest mailing list -- rfc-interest@rfc-editor.org To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
