Re: Facts, please, not handwaving [Re: Its about mandate RE: Why cant th

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(_at_)cridland(_dot_)net - 
xmpp:dwd(_at_)jabber(_dot_)org
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf