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

[Douglas Otis <[e-mail]>]

On 9/9/11 6:33 PM, Thomas Narten wrote:
> 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.
Agreed. Well said.

-Doug