On Fri, Jul 05, 2019 at 08:57:23PM +0000, john heasley wrote:
> Please re-read Snjider's email, to which you replied, without this
> tangental notion of a "stable draft mark".
>
> I feel that you and others have mis-read it. Maybe I have, but I feel that
> this stable draft idea is *not* what he is promoting; that was someone
> else's idea and the two are being, but should not be, confused.
I don't think Snjider's problem statement is terribly difficult to
solve, and we have an answer already, which is an Informational RFC.
Note his problem goals/requirements statement:
* Protocol specifications or extensions are a non-goal
* Provide more context around RFCs, such as use case documents,
implementation reports, security-related recommendation, etc.
* With a short identifier
We have a large number of use case documents as Informational RFC's
already. For example, RFC 7744, RFC 8151, RFC 6394, etc. We also
have requirements documents that define the problem --- for example,
RFC 2820. We have security-related recommendations as well, such as
RFC 1750, "Randomness Requirements for Security" (although that's now
a BCP, not just an Informational RFC).
I suspect people have been jumping off to something which is harder,
and perhaps for them, more interesting, which is signalling that a
particular I-D version is one that is worthy of being implemented, and
perhaps, deployed in a world where new implementations can be reliably
rolled out to a large percentage of the installed base in 2-3 months.
One answer is of course the experimental RFC, but the problem is that
a lot of people see RFC and immediately assume, it's a stable,
IETF-blessed standard documentation, regardless of the "Experimental"
tag on the top of every single page of said document.
But for Snjider's use case, where the document in question isn't a
specification in any way, but instead is a use case or requirement
document, implementation hints, etc., we don't have to worry about it
being it mistaken for a protocol specification.
Regards,
- Ted
