Document Series

[Bound, Jim]

This is exactly what is happening in the IETF. 

/jim

> -----Original Message-----
> From: Bob Hinden [mailto:hinden at IPRG.nokia.com] 
> Sent: Tuesday, June 03, 2003 8:03 PM
> To: Dave Crocker
> Cc: problem-statement at alvestrand.no
> Subject: Re: Document Series
> 
> 
> 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
> 
>