OPEN ISSUE: Standards Track

[Margaret Wasserman]

At 10:49 PM 5/15/2003 +0200, Harald Tveit Alvestrand wrote:
>mumble....
>
>there's another issue here, but I don't know if it is possible to untangle 
>it......
>
>*what sort of bugs, if detected, would make a protocol unsuitable for 
>Proposed Standard?*

There are at least two ways to look at the concept of a staged release
process:

         (1) You define the criteria for acceptance at each phase.
                 These criteria are easier to meet at lower phases
                 (i.e. you can have more bugs of certain types, you
                 need implementations for a certain phase, etc.).

         (2) You expend different levels of effort to determine the
                 quality at each phase (i.e. you subject the
                 document to successively wider review and comment
                 at each phase).

We already do (1) to some extent (requiring implementations for DS),
but we don't do (2) at all...  It might be possible, for example for
area management to publish a document to the first phase in the
standards process, without full IESG review. This would also help
with the scaling problems at the top.

I also think that there are two other problems facing us:

         (1) There is no real differentiation in our market between
                 Proposed Standards and Draft Standards.  Our
                 "customers" don't know what documents are at what
                 level, and they don't care.  In fact, most of them
                 can't remember which comes first, PS or DS...  And
                 once something has an RFC number (even experimental
                 or info), it is treated like a standard.  So,
                 there is really no reason to do the work necessary
                 to move to DS, and certainly not to FS.

         (2) The term "Proposed Standard" currently indicates to
                 our market that the document is a standard.  If
                 we create a lower-level category, we should give
                 it a different name, and put something _in the
                 document_ that indicates its provisional status.
                 (No one actually looks at the RFC index to
                 determine the status of a document before
                 specifying it in an RFQ or RFP).

>It's fairly obvious that we invented the 3-step process so that we could 
>fix bugs. And that implies that we think there are bugs that will only be 
>flushed out after people try it out in practice.
>
>But - does that mean that we should let known bugs pass into Proposed?
>Or will this be forever a judgment call?

I think it will forever be a judgement call, just as it is in software
and hardware development.

Like all judgement calls, there is a certain amount of effort spent in
gathering the information to make the call, and then the call is made
based on available information.  The best way to create a tiered process
is not to remove the judgement call...  Instead, you could move it to
lower levels of the organization (if we had any) and/or lessen the time and
resources spent gathering information before the judgement call is made.

>A related issue is whether or not the restrictions on going to Draft from 
>Proposed are really appropriate; currently, we say that *only* deletion of 
>features is appropriate, and that any change or extension, no matter how 
>worthwhile the purpose or how sure we are that it makes no problems, 
>requires another round through Proposed. Is this really best for the Internet?

I think that this process is damaging, because it tends to lead to all
of the implementation-related experience being reflected in the PS
version.  This, in turn, offers even less incentive to the group to
produce a DS version.

At this point, there are _many_ WG and non-WG I-Ds in the IETF that
have already been widely implemented and fairly widely deployed.  If
it weren't for the requirement that documents be published at PS for
six months and recycled if there are any changes other than deletions,
many of these documents could go straight to DS...

Sometimes, I feel like a hypocrite about this topic.  On the one
hand, I'm fighting to keep the "integrity" of the standards-track
document set, according to our current rules.  And, on the other
hand, I think that our current rules are more than a bit draconian.

For example, I think that it should be possible for several different
proposals that solve the same problem to be published in an enduring
form by the IETF, and for a subsequent process to determine which
one(s) will advance on the standards-track.  This would solve some
of the problems that we have in the v6ops WG, for example.  But, we
have no tools to do this in a way that makes the status of these
documents visible to our "customers".

As soon as a protocol has an RFC number, our "customers" treat it
as a standard.

Meanwhile, we have individual submission track where people can get
RFC numbers without jumping through any of the IETF hoops (unless
they happen to overlap with a WG).  What is wrong with this picture?

Margaret