On Tue Sep 19 22:31:40 2006, Dave Crocker wrote:
I would argue that "Proposed Standard" as the end-of-the-line
in our standardization process is just wrong. I certainly can see
an argument for merging "Proposed" and "Draft" - but there are lots
of indications that even the simplified one-step process of moving
from Draft to full Standard would not get done much of the time.
The reality of the current IETF is that we view publishing a
Proposed specification as an indication of success. That is, we
think it is an ending, rather than a beginning.
A minor problem with this is that we have no sense of what IETF
actually gets deployed and used, and what doesn't. This leaves us
exposed to developing very unrealistic feeling about our current
impact on the Internet.
(The status of Historic is not relevant to this question, since it
is applied only erratically and long after a specification has
demonstrated that it is not useful...any more.)
What we need is a more immediate basis for assessing current
utility of recent IETF work.
That's why I keep suggesting that we set a time-limit for
deployment and use of Proposed specifications. Those failing to
garner the necessary community support automatically go to
Historic. Those that succeed go to Full.
Well, I think there's a lot of confusion between the statement "We,
as engineers trying to maintain our scientific integrity as a whole,
consider this specification a good thing and recommend it", and "We,
as disinterested engineers trying to be practical and document what
gets used, note this specification is widely used". At the moment,
we've tied the two statements into one - we cannot advance something
down the standards track that's well deployed, but has arguble flaws
(say, like HTTP/1.1, although you can subsitute your own contentious
example here), because it implicitly implies we think it's flawless,
which I think is a practical problem.
I'm not saying the two are utterly disconnected - it's good and fair
that we require a substantial degree of implementation and deployment
experience for us to consider a specification "good" - but neither
are they one and the same thing, and I think they pull in different
directions.
I suspect there's a third metric about a specification, too, which is
concerned with how stable its foundation is - how "good" we think the
dependencies are in aggregate, as they affect this specification. So,
we might acknowledge that ACAP has a dependency on CRAM-MD5, but we
acknowledge that CRAM-MD5, whilst not particularly good, is very well
deployed, and moreover has little practical impact on how good ACAP
is. (And says nothing at all about how well deployed ACAP is, of
course, which is an entirely different matter)
At the moment, we require that we recommend a specification only as
much as it is deployed, and never more than its dependencies. We
never admit to deployment of protocols we do not approve, nor do we
openly approve of protocols that are not deployed. Once deployed and
approved, then we're fine - only if deployment drops off, we don't
admit to that either.
Imposing a simple time limit does not reflect either the technical
goodness - which is not to say that new techniques make older ones
look foolish sometimes - nor does it aid in deployment.
Given a standpoint that much of the problem with Standards Track
advancement is in the multiple implications of advancement (and in
the inability to move backwards along the Standards Track), I
strongly suspect that reducing it to a one-step would intensify the
differences between deployment and recommendation, and therefore make
the problem worse, and not better.
Dave. (Currently feeling in danger of being branded another loon by
posting twice on ietf-politics within the same week)
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf