OPEN ISSUE: Standards Track

[Keith Moore]

On Thu, 15 May 2003 11:41:27 -0400
Margaret Wasserman <mrw at windriver.com> wrote:

> 
> The process document current says:
> 
> >There is also a more fundamental issue with the IETF's engineering
> >practices.  Although our current standards track contains three
> >levels of maturity (Proposed Standard, Draft Standard and Full
> >Standard), we do not have sufficient differentiation regarding the
> >quality and completeness of documents required at each stage.  The
> >bar is set very high for publication at Proposed Standard, and very
> >few documents advance beyond this stage. [OPEN ISSUE: Do we have
> >IETF consensus that this is a problem?]
> 
> I believe that this is a real issue, and that we need to make
> some changes to our standards-track document processes to
> address this.

I think there are multiple issues here:
1. insufficient differentiation of quality between the stages
2. we don't consider Proposed "done" (officially it's not even
   deemed ready for wide deployment), yet the industry does
   consider proposed "done" unless serious bugs are found.

> In particular, I think that we have inadvertently reached a
> point where our proposed standards are treated as standards
> by most of the industry.  I think that this was caused, in
> part, by the high level of scrutiny that we place on documents
> before we allowing them to reach this level. 

I think this is caused by multiple factors:

- Proposed is the first stable publication of a standards-track document,
  in the sense that the RFC won't expire and it won't be changed.
  (Maybe implementors just want a stable, referencable spec before 
  deployment, and they don't care so much about IETF's blessing.)

- The word "standard" appears in the document status.

- By the time a document is published as Proposed, the working group
  is typically burned out, and there's insufficient energy to revise
  the document further.  Getting a document moved to Draft Standard
  is extremely difficult not because the changes are extensive
  (usually they're fairly trivial) but because it requires a lot of
  attention to detail, and coordination between lots of people for 
  interoperability reports, for what is seen as minimal gain.
  (and Draft Standard actually sounds less mature than Proposed Standard)

If I'm reading this right, then this means we have a conflict:  On one hand
we'd like to have a lower bar for initial publication than what is currently
deemed Proposed Standard, so that we provide some incentive, some indication
of externally-recognizable progress, and can get wider review of a document
(perhaps even implementation) before we get to the level that the industry
recognizes as ready for shipping in product.  Oh the other hand if what the
industry is really waiting for is a stable, referencable spec, then publishing
RFCs with less scrutiny than is currently required for Proposed means that
quality of deployed protocols could decrease.  And if the process of moving
from the earlier stage to one which has a similar level of scrutiny to what is
currently Proposed ends up being as difficult as moving a Proposed document to
Draft, we may find that in the future we rarely get as far as (what used to be
called) Proposed.