Document Series

[Bob Hinden]

Dave,

>Here is my own thought on useful stages:
>
>1.  Technical discussion and convergence -- form community consensus
>2.  Technical refinement -- lock down the details
>3.  Proof of concept and debugging
>4.  Stability -- community operational acceptance
>
>The first is pure mayhem, and that's good. People explore, suggest,
>debate. Eventually, they should start to form group preferences and
>focus on getting the details worked into a specification that provides
>detail which readers can understand and see as coherent and sufficient
>for achieving a specific set of useful functions. Then they test the
>thing, to see whether interoperable implementations can be developed.
>Then they actually use the thing, eventually achieving some sort of
>critical mass of deployment.
>
>Now, the clever reader will observe that we already have exactly these
>stages. (Personal I-D, WG ID -> PS, Draft, Full.) Yet the latter 2 are
>virtually unused.

As you correctly point out the IETF (and as implemented by the IESG) is not 
using the standards process we have defined.  It has been changed where the 
initial barrier has been raised very high at Proposed Standard and hardy 
anything gets to Draft standard, let alone (Full) Standard.

I think that many of the problems folks are complaining about stem from 
this.  It causes the IESG to worry about letting a document get to PS that 
is not perfect.  This results in many detailed reviews and documents being 
blocked for what might seem minor reasons.  This in turn creates a work 
load on the IESG that is close to impossible.  The resulting delays cause 
frustration between authors, chairs, working groups, AD, etc.  I think that 
a lot of this stems from trying to make PS the biggest hurdle.

I think that if we implemented the standard process as written (and as 
intended) that many of these problems would go away.  Perfection would only 
have to be achieved at Standard (and close to perfection at Draft 
standard).  This would mean that problems with specifications could be 
found by people implementation the protocols and running into problems, and 
then bringing the issues back into the working groups.  Interoperability 
problems would be found.  This would spread the load of improving the 
quality of the specifications to a much larger community of people than 
just the IESG members.   Running code and interoperability would be the 
real test for quality.

Enforcing the time outs would create incentives to move the specifications 
through the standards process.  I also suspect that some (perhaps many) 
specifications never really get implemented, so as long as we enforced the 
time outs as specified, that these would just go away.

There is a lot of parallels with the multi-step IETF standards process as 
with building products.  First versions of products always have 
problem.  Most successful product companies learn that trying to make the 
first product perfect is counter productive because it creates long delays 
and the real test is getting the product to the costumers.  Then the 
company really learns how well the product works and meets the market need 
(i.e., requirements).  It through creating new versions of the products 
that problems are fixed and quality is improved.  Companies that delay the 
first release until the product is perfect usually go out of business.  I 
wonder if that is what is happening with the IETF.

Bob