Re: what is the problem bis
2010-10-28 06:37:45
On Oct 28, 2010, at 5:05 AM, Yoav Nir wrote:
That the labels can be updated is a good thing, but you would have to start
with something.
People are complaining about the length of time it takes to get anything
published. Adding these extra steps of "protocol quality review",
"applicability review" etc. will only make that process even longer.
Much of this is already being done as part of internal review by IESG and the
document shepherd. So no, merely assigning these labels shouldn't make the
process longer.
Actually (based on my long ago experience in IESG, which might or might not be
informative of the situation today) part of the reason the current process may
take so long might be that IESG is essentially trying to shoehorn a number of
different concerns into a binary decision of whether something should be
Proposed or not - and that decision often involves a lot of angst. (e.g. when
a WG has labored for years to produce a protocol which describes a good idea,
but describes it poorly.) Maybe the IESG could instead do its review, and
assign values to these various labels. If it doesn't think the document yet
meets the threshold criteria for standards track, it could offer the WG or
author the option to publish as Informational - but still with these labels.
That way, readers could get a sense of the relative quality of the document and
protocol and have some improved basis with which to judge whether they should
implement it and whether it would work well for them.
Or - here's an idea - what if all that were holding up a document were stale
references or normative references to non-standard documents? The review
could come back with Protocol-Quality=good, Applicability=wide,
Document-Quality=good, Completeness=incomplete (with the reason given as:
references to nonstandard material). It might still not yet be labeled as
standards-track but implementors would know that the document had generally met
with favorable reviews.
Keith
Yoav
On Oct 28, 2010, at 3:57 AM, Keith Moore wrote:
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
|
|