--On Monday, 08 March, 2004 13:26 -0500 Keith Moore <moore@xxxxxxxxxx> wrote:
It's all well and good to try to retire Proposed Standard documents that don't get implemented. But I think it's even more important to make it easier for documents that do meet the criteria to advance to Draft Standard. In my experience the hardest part of getting a document advanced is to collect the implementation report.
Interesting. I would have described the hardest part as lying in the documentation process itself, in particular...
* When a document has been very controversial in getting to Proposed, at least partially because of very loud and continuing objections about specific points from those who disagreed with them, it is often hard for authors, editors, [former?] WG Chairs, etc., to get up the energy to deal with what is likely to be a renewed version of the unpleasantness. * When one or more IESG members have engaged in extensive, time-consuming, and unpleasant nit-picking or bickering about provisions of the original, Proposed, document, authors/ editors/ WG Chairs may have the reasonable expectation that they would do an even "better" (more extensive) job on a draft coming up for Draft.
and
* Documents that are, themselves, perfectly ready to advance get stalled indefinitely because they make normative references to documents or protocols that, for one reason or another, less ready.
The discussion below does not address the third point; I don't know quite what to do about it.
Note that none of these issues is intrinsically related to the protocol quality or deployment of the specification. What the first two share with the "implementation report" issue is that the documentation issues are independent of the underlying reality.
Hence this modest proposal:
- For each standards-track document, create a web page that is used to keep track of bug reports, errata, implementation reports, and test reports. ...
My not-very-modest proposal (many details would need filling in, but, as an idea...):
(1) We decouple "change maturity levels" from "write and publish an RFC" (this means that the listing of maturity levels must be current and authoritative). This also meshes nicely with another proposal that was floated a few years ago, but never really written up (see below) (2) When a document comes up for review for Proposed->Draft, we look for implementations, etc., perhaps following Keith's proposal outline. If the implementations are there, we issue a Last Call for identification of serious technical/definitional flaws in the document as published, where "serious" is defined as "problematic enough to interfere with independent interoperable implementations". If none are found, we advance the maturity level of the document, in place -- no new RFC publication required and hence little or no opportunity to reopen old wounds that lack demonstrated interoperability impact. If the document is about to time out in grade, we issue a Last Call, wait a reasonable period for protests and volunteers, and then downgrade it in place. The notion of having to write an RFC, following all of today's complex rules, and get formal consensus in order to declare a Protocol obsolete that isn't implemented and won't operate in today's environment is one of the more astonishing triumphs of bureaucracy over rationality. Similar rules would apply to Draft->Full (or whatever formula newtrk comes up with). (3) If a document is judged defective (which is difficult from judging a protocol defective), we try to find someone to fix it. If a plan (and volunteer(s)) cannot be readily found, we publish a description of the defect(s), presumably as an RFC, but, if that is unworkable, in some other way. Minimize the fuss -- if our customers don't think an updated document is worth the trouble --enough trouble to invest people, dollars for professional editing, or whatever else is required-- then we should stop losing sleep over it.
Principle: If we are going to spend as much time and energy as we do getting something to Proposed, then moving it to Draft or Full should usually require only identification of implementations, deployment, and desirability, not extensive and time-consuming document rewriting
john
--------------
Footnote -- that other proposal: Some time ago, I noticed that the relationship between the STD definitions and the underlying RFCs had gotten a little too complicated for anyone to usefully understand. By being reserved to full standards, the STDs also did not help with hints about things advancing along the standards track (e.g., a Proposed document that has fairly wide consensus and that is intended to ultimately replace a full standard is a very funny state today). That produced some informal discussion of an idea of actually turning STDs into documents, rather than references in an index. A typical STD document, which could be issued for a Proposed Standard, under that proposal, would consist of
* A title and abstract, which might differ from the underlying documents if there were several of them. * Any discussion of what made up the standard and why that was felt to be necessary. If there is any useful content in, e.g., the IESG's Protocol Action notice, it could be included there as well. * Any short statements about applicability, maturity levels, recommendations (remember mandatory/ recommended/ optional ?) that didn't justify publication elsewhere. Note that this might be a place to correct significant errata and descriptions of deficiencies in the definition. * A change history, so that one could easily tell which RFCs were part of what standards at what times.
And, unlike RFCs, an STD document would change as standards evolved.
I don't know if it was a good idea, but it would mesh nicely with some of the other ideas that have been floating around. I can write it up if there is serious interest, but have no plan to do so at present.
john