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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf