Document Series

[Bound, Jim]

My view is:

PS is for base prototype of a spec and then implementation.
DS is for pre-product implementation and if lots do it product
implementation.
S(full) is lots of entities are using it and it does not have to be the
entire Internet.

Anything more than this will result in late time to market and the
result of that is being seen today, and soon we will see protocol
proposals to other than the IETF to other SDOs if we don't fix this and
the initial death of this SDO except for maintenance of the current IP
(which is a large job and we call it in business the cash cow).  But the
new and interesting work required for the market will go elsewhere if we
don't fix this.  I think that should be stated as a problem too.  Most
of us don't want to have to deal with multiple SDOs to work on the IP
standards but we are to a minor degree already.

/jim

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms at cisco.com] 
> Sent: Wednesday, June 04, 2003 9:23 AM
> To: problem-statement at alvestrand.no
> Subject: Re: Document Series
> 
> 
> My experience with DS and full Standard is that no one is 
> interested because of the lack of perceived difference 
> between the requirements between the standards levels and the 
> lack of perceived added value in progressing a spec to DS or 
> full standard.  That is, I disagree with Brian's statement 
> about the requirements for DS and full standard being too 
> high - I think the problem is a lack of differentiation among 
> the three standards levels.
> 
> Here's how I see the standards track:
> The required correctness for PS is high enough that a PS spec 
> is "good enough" for vendor implementation and deployment.  
> The reward for moving to DS and full standard is not worth 
> the investment of effort.
> 
> The tension I see is the need for a specification that is 
> sufficiently baked and stable to be used for prototyping, 
> interoperability testing and proof-of-correctness for the 
> spec doc, but that does *not* result in deployment.  It's the 
> premature deployment that (a) casts goofs in the spec in 
> stone and (b) eliminates any motivation to move the 
> specification through the standards track.
> 
> - Ralph
> 
> At 02:58 PM 6/4/2003 +0200, Brian E Carpenter wrote:
> >Keith Moore wrote:
> >> 
> >> O> My understanding is that the higher bar to PS arose as a 
> >> O> consequence of
> >> > things being widely deployed at PS and things not advancing to 
> >> > Draft rather than the deployment and non-advancement being a 
> >> > consequence of the high bar.
> >> 
> >> that's my understanding also.
> >> 
> >> > This is important in the sense that if the lack of 
> advancement came 
> >> > first, then simply lowering the bar will not help us get better 
> >> > standards, and in fact could result in our ending up with lower 
> >> > quality documents permanently.
> >> 
> >> I'm in strong agreement with this.  What we need to do is 
> find a way 
> >> for standards to at least the level that is currently 
> required for PS 
> >> more quickly, not to lower the bar for PS.
> >
> >Fully agree.
> >
> >> We might even need to raise the bar slightly.
> >
> >Do you mean that we are frequently releasing PS documents 
> that contain 
> >significant defects? We certainly can't expect PS documents to be 
> >perfect.
> >
> >Another problem I see is that the barrier to Standard is so 
> high that 
> >nobody is interested, and the barrier to DS is high enough that very 
> >few people are interested. That being so, apart from some academic 
> >ideals, I question the value of having 3 grades at all. 
> Since we hardly 
> >use the top two grades, why have them?
> >
> >   Brian
> 
>