More labels for RFCs (was: what is the problem bis)

[Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx>]

On Oct 27, 2010, at 9:57 PM, Keith Moore wrote:

That's why I think we need a different set of labels, e.g.

Protocol-Quality.  We need a statement about the perceived quality of the protocol described in the document.   (Is this protocol well-designed for the anticipated use cases, or does it have significant flaws (including security flaws)?)

Applicability.  We need a statement about the current applicability of the protocol described in the document.  (Is this protocol recommended for general use, not recommended except in specific corner cases, not recommended at all, or strongly discouraged?)

Document-Quality.  We need a statement about the perceived quality of the document itself and whether the protocol description seems to be sufficiently precise to permit implementations to interoperate.   (along with a pointer to errata.)

Maturity.  We need a statement about the amount of actual implementation and deployment experience that the protocol enjoys. 

Completeness.  We need a statement about how accurately the document reflects what is currently believed to be good practice for implementation/use of that protocol, or whether effective implementation requires information not included or referenced in the document.  (e.g. effective implementation of SMTP generally requires some expertise in dealing with heavy loads caused by spam, looping, and denial-of-service attacks which aren't really dealt with in any of the relevant RFCs).

Last-Review-Date.  Date of the last review of these labels for this document.

These would go alongside the existing Updates and Obsoletes labels.  An Applicability-Statement could also be included.

The problem with a labeling scheme like this is it's subjective.  "Updates" and "Obsoletes" are not subjective, and to determine whether to apply those two labels is fairly easy.  Labels of the form *-Quality would cause massive debate and need a WG-wide or larger consensus agreement process, if you mean them to be formal labels.

For some of what you describe above, people already produce RFCs to document - RFCs which deprecate a previous RFC, or enumerate issues found, or BCPs, etc.  And obviously errata are already captured by the RFC editor.

What's missing I think is some way to remind/force readers of an RFC to check for errata and updating/obsoleting RFCs, and how.  Since it's a static document when published, I think the most natural way would be to add to the boilerplate a sentence reminding the reader to check for updates, obsoletes, and errata at "http://datatracker.ietf.org/doc/rfcXXXX" where XXXX is filled in by the RFC Editor upon RFC publication.

Or if you want to be really fancy, you could have the IETF auto-create a Wiki type page for each RFC, that allows open community wiki-input about quality and implementation/deployment experience and such, with a big banner indicating the wiki content is not an official IETF position.

-hadriel

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf