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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf