--On Monday, 08 March, 2004 13:26 -0500 Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> 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