On Jul 4, 2019, at 00:33, heather flanagan <hlflanagan@xxxxxxxxx> wrote: > > One of the things that attracts me to this idea of marking specific I-Ds as stable is the possibility that the material in the I-D will be more throughly tested BEFORE it gets to the RFC Editor for publication. I see it as, potentially, a way to improve the quality of what’s published in the RFC Series. Most of the confusion here is about the term “stable”, because that means different things to different people. Clearly, it’s not “stable” if it can be toppled next week. What we occasionally do is label some draft versions as “implementation drafts” (certainly not my idea). That designation means “it is worth implementing this now; this is no longer quicksand”. It may simply be motivated by the need to get interop experience, so it does not mean “stable” in a more serious way; I’d rather have a different label for “we are not going to break this any more unless we really have to” label (e.g., the CDDL I-D was in that state since 2015 before it became RFC 8610; it did gain additional features during this time). So I think providing a way for a WG to slap a useful label on a WG I-D is a good thing; standardizing on a small set of such labels is useful, but not a prerequisite. The whole discussion is a bit of an expression of the too-high-threshold we now have for publishing things as an IETF document; there really should be a “proposed standard” level. (Ceterum censeo: Our whole nomenclature of publications, where only some Internet standards are “Internet Standards” while the more important group is “Proposed Standards”, and valid documents are “obsoleted” by documents that are just revised editions of them, etc., is incomprehensible to casual observers and can be used and is being used against the IETF –– we really need to work on that terminology.) Grüße, Carsten
