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

[Keith Moore <moore at cs.utk.edu>]

> 	(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).

John,

I cannot support the notion that the only technical flaws that should 
prevent a document from advancing from Proposed to Draft are those that 
"interfere with independent interoperable implementations".

A protocol may interoperate quite well with itself, and yet have a 
peripheral effect on a large number of other protocols. A protocol that 
does not share channel capacity fairly with TCP can have a disruptive 
effect on TCP-based protocols.  A protocol that defines a new kind of 
(IPv4 or IPv6) address space that behaves differently from existing 
address space can break applications even if that protocol does not 
directly interact with those applications.  A protocol which doesn't 
provide adequate authentication can cause its hosts to be compromised 
which in turn affects the operation and security of other services.

That, and it's too easy for technical flaws to be missed at Proposed 
Standard that show up after some implementation and/or deployment 
experience is gained - and these aren't at all limited to flaws that 
interfere with interoperation.

I do agree that we should not reopen noncontroversial documents that 
aren't found to have significant flaws.  I have occasionally suggested 
that rather than re-edit documents advancing in grade, we start out by 
making lists of things that need to be changed.  If that list ends up 
being less than N pages or X% of the length of the original 
specification, publish the list with a preface that says "RFC XXXX, 
with the following clarifications, changes, and corrections, is 
approved for Draft Standard".

OTOH, some documents that were controversial at Proposed probably do 
deserve special scrutiny at Draft.  That doesn't mean that we should 
automatically reopen them, but it might be that given the subsequent 
experience with the document it no longer meets the criteria for 
Proposed (e.g. "no known technical omissions").

> 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

What if we applied the same "principle" to software?  What if once a 
program were written there were an expectation that it should never be 
substantially changed, never be re-evaluated in light of changed 
conditions or new understanding?

Keith