ietf
[Top] [All Lists]

Re: what is the problem bis

2010-10-27 20:58:05

On Oct 27, 2010, at 8:58 AM, Yoav Nir wrote:

This comes back to the question or why have maturity levels at all. Ideally, 
an implementer should prefer to implement a mature standard over a 
less-mature one. In practice, adopting the more advanced standard may give 
you an obsolete protocol, rather than a more stable one. IOW the 
standardization level of a document does not give a potential implementer any 
signal as to whether or not this standard is in any sense of the word "good".

Mostly agree.  The distinction between an older, well-tested, widely-deployed 
version of a protocol vs. a newer less-tested, less-widely-deployed version 
with more features is a useful distinction to make.  but the difference between 
(RFC X, full) and (RFC Y, proposed) where Y >> X only conveys the barest hint 
of that, and even less in the way of guidance.  I'm thinking specifically of 
email standards here, where in practice you need to be able to accept RFC 822 
messages (because even new mail readers have to be able to deal with old 
messages) but you should generate messages that conform to 5322 and MIME.

And if it doesn't signal anything to the "customers" of the documents, what's 
the point of having these levels at all?

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.

It strikes me that we could establish such a set of labels on an experimental 
basis, using some sort of community review process for existing RFCs, without 
making any immediate changes to our proposed/draft/full system of labeling of 
standards.  IESG could assign the initial labels for new RFCs - the document 
reviewers are almost doing that anyway.  The existing errata process could be 
extended to allow (moderated) user comments on these labels, and the labels 
could be subject to periodic review based on those comments.

If that labeling system turned out to be adequate or could be fixed with some 
tweaking, we could maybe drop back to two document classes:  Informational, and 
Standards-Track.  Standards-track would encompass any  former proposed, draft, 
or full standard which was still in use and for which periodic reviews were 
still being done.   Former Experimental documents would be reclassified as 
Informational with appropriate descriptive labels.  Former Historic documents 
would be reclassified as Informational with Applicability set to Historic.   
Standards-track documents would expected to have periodic review of these 
labels; Informational documents could have some of those labels set to 
"Undetermined".

Keith

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>