On 29.10.2010 18:20, Hadriel Kaplan wrote:
...
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.
...
It's only sometimes easy. It get's really hard when the "old" RFC
combines too many different things (like a new HTTP method, one
application for it, and a registry because previously there was none),
or when the new spec is actually a set of RFCs.
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.
All RFCs published since last January have that pointer in the
boilerplate, it goes to
http://www.rfc-editor.org/info/rfcNNNN
(now if we published specs in (X)HTML, people might actually click on it)
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.
That might be a good thing to have.
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf