Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Thomas Narten <[e-mail]>]

I am surely going to regret posting, because I have largely tuned out
of this discussion due to the endless repetition, etc. I am not
supportive of the current document, because I don't think it solves
anything. To me, it smack a bit of "change for changes sake".

One of the key problems that isn't being addressed is that mixing
"advancement" of a spec with "revising" a spec are fundmentally at
odds with each other. 

Advancing a spec is done for marketing, political, process and other
reasons. E.g., to give a spec more legitimacy. Or to more clear
replace an older one. Nothing wrong with that.

But the real reason that the IETF *should* be revising specs is to fix
bugs and improve protocol quality.

By definition, you cannot revise a spec (in a real, meaningful way)
and advance at the same time. The spirit (if not letter) of
advancement says you advance a spec, when there are implementations
*based on the spec being advanced*. That means you can't revise a spec
and at the same time have implementations derived from the revised
spec.  (You can have implementations based on mailing list
discussions, but that is NOT the same thing.)

The IETF is about making the Internet work better. That means revising
specs (from a technical perpective) when they need to be revised.

If we want to fix what's broken, we should focus on getting documents
revised (without simultaneously advancing them).
But once you do that, one quickly finds out that there are real and
sometimes  complicated
reasons why revising documents is hard.

In many cases, widely deployed protocols really need to have a revised
spec developed (and the authors will readily admit that). But that
just doesn't happen, not because of process, but because of other much
more fundamental problems. E.g., Not enough energy from the relevant
experts. key people who know a spec have moved on to other newer
technologies or other higher priority things. Fixing specs can also be
painful because some vendors won't or can't change their deployed
implementations, so don't really want an updated spec that invalidates
their implementation. etc., etc. It can be very hard for a WG to walk
the line between "we need to fix this" and "can we tweak the spec
without invalidating various deployed implementations".

IMO, these sorts of issues are the real reasons documents don't
advance more. It's not just about process.

Thomas