Document Series

C. M. Heard heard at pobox.com
Wed Jun 4 13:45:08 CEST 2003


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

Agreed that this is a problem.  There seem to be several related
reasons for this.

>>>>> On Wed, 4 Jun 2003, Brian E Carpenter wrote:
BC Keith Moore wrote:
BC >[Joel M. Halpern wrote:]
BC > > My understanding is that the higher bar to PS arose as a
BC > > consequence of things being widely deployed at PS and things
BC > > not advancing to Draft rather than the deployment and
BC > > non-advancement being a consequence of the high bar.
BC >
BC > that's my understanding also.

In other words the high bar imposed on PS is due to the fact that
vendors, operators, and IETF folk fail to treat PS as the standards
process intended.  There are probably many reasons for that.  Here
are a couple that I can think of:

- Most SDOs don't seem to have anything resembling the three-tier
process.  Typically an approved standard is considered ready for
deployment.  It seems that PS has been treated on a par with other
SDO's approved standards.  Yes, there are well-known problems with
deploying standards not backed by implementation experience, but
that seems to be what's happening.

- In some cases the three-tier process is simply ill-suited to the
task.  MIB documents are one particularly problematic case, especially
those whose purpose is to manage technology developed by other SDOs.
The Ethernet MIB modules (currently RFCs 2665 and 2668) have been
recycling at PS for quite a while now, because of new objects being
added to manage new types of Ethernet media.  The one document that
did reach full standard (RFC 1643) is obsolete and the WG has asked
the IESG to formally retire it by moving it to Historic.  (Part of
the problem here is that it's not always possible or reasonable to
split new MIB features off into separate documents that can be
advanced separately.  But let's not get sidetracked on the details.)

There is probably little that the IETF can do to prevent vendors
from deploying stuff that is at PS, short of calling it something
other than a standard.  The IEEE has something called a trial-use
document (http://standards.ieee.org/guides/opman/index.html) that
seems to roughly correspond to the IETF's notion of a PS.  I don't
know how successful that idea has been or how often it is applied,
but it does have a maximum lifetime of two years after which it
must either be affirmed as a full standard, revised, or withdrawn.

BC> > > This is important in the sense that if the lack of
BC> > > advancement came first, then simply lowering the bar will
BC> > > not help us get better standards, and in fact could result
BC> > > in our ending up with lower quality documents permanently.
BC> >
BC> > I'm in strong agreement with this.  What we need to do is find
BC> > a way for standards to at least the level that is currently
BC> > required for PS more quickly, not to lower the bar for PS.
BC> 
BC> Fully agree.

If actual deployment is going to be expected at PS, then it is
hard to argue for lowering the bar of "no known defects".

BC> > We might even need to raise the bar slightly.
BC> 
BC> Do you mean that we are frequently releasing PS documents that
BC> contain significant defects? We certainly can't expect PS
BC> documents to be perfect.

No, not without implementation experience.

BH> I think that if we implemented the standard process as written
BH> (and as intended) that many of these problems would go away.
BH> Perfection would only have to be achieved at Standard (and close
BH> to perfection at Draft standard).

It's not clear to me whether it is really possible for the IETF to
make PS into what RFC 2026 says it's supposed to be.

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

That would help, and it would address a problem that we often fail
to maintain our specs.  However, it would not address something
like the Ethernet MIBs ... the technology moves fast enough that
the spec is likely to recycle at PS forever (even though large
portions of it are stable).

>>>>> On Wed, 4 Jun 2003, Ralph Droms wrote:
RD> Here's how I see the standards track: The required correctness
RD> for PS is high enough that a PS spec is "good enough" for vendor
RD> implementation and deployment.  The reward for moving to DS and
RD> full standard is not worth the investment of effort.
RD> 
RD> The tension I see is the need for a specification that is
RD> sufficiently baked and stable to be used for prototyping,
RD> interoperability testing and proof-of-correctness for the spec
RD> doc, but that does *not* result in deployment.  It's the
RD> premature deployment that (a) casts goofs in the spec in stone
RD> and (b) eliminates any motivation to move the specification
RD> through the standards track.

It seems to me that Experimental documents would fill that bill.

BC> I question the value of having 3 grades at all. Since we
BC> hardly use the top two grades, why have them?

>>>>> On Wed, 4 Jun 2003, Keith Moore wrote:
KM> of course not.  what I mean is that if we realize that PS in
KM> effect is taken as "ready for deployment" (which seems to be how
KM> the industry interprets it), then maybe we really do need to
KM> expect some level of implementation and interop testing before
KM> we approve something as PS.

This suggests to me a two-step process

- specs start out in life as Experimental, recycling there
are necessary until

- there are no known problems and at least two interoperable
implementations, at which point they would be eligible for
elevation to Standard (and could stay there on subsequent
revisions, if the changes were not "too drastic")

but this is intruding on solution space, isn't it?

//cmh



More information about the Problem-statement mailing list