Re: Work effort? (Re: Proposed Standard and Perfection)

[John C Klensin <john-ietf at jck.com>]

--On Monday, 08 March, 2004 13:26 -0500 Keith Moore 
<moore at cs.utk.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