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. Since there was a designated expert
involved, and the requestors were likely all known to the DE, it was an in
family event. Had someone else come along and asked for values, I doubt they
would have been allocated.
> 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 [
signature.asc
Description: PGP signature
_______________________________________________ rfc-interest mailing list -- rfc-interest@rfc-editor.org To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
