Thomas,
I am in full agreement that document revision and bug fixing is the more important activity for IETF. Not just in my opinion, but I think we can also see it from the numbers of bis documents versus numbers of advancing documents.
But I think some amount of bug fixing and revision is compatible with advancing a document. Clarifications. Removing cruft that no one ever implemented. Documenting security or other concerns better. I don't think it is quite as black and white as you wrote ("you cannot revise a spec in a real meaningful way"). Its just a question of how big surgery the specification needs.
That being said, I do agree with you that the reasons behind lack of work are complex and often have little to do with IETF processes. It is indeed often the case that people with real capability to do something about a specification are either not interested in too minor changes or have vested interests in not causing their implementations to become non-compliant due to bigger changes. There is little that we can do in the IETF process about this, except maybe make the overall RFC publication easier. The industry will come to the IETF when they have a common incentive for a standard or an update thereof *and* they believe they can actually get the work done.
But bringing ourselves back to the topic of process changes, I agree that Russ' draft is not solving our biggest problems. (I personally view it as a tiny effort to remove an unused feature from our process. It could have removed two levels instead of one, but would that have made it easier or harder to find consensus for the change?) But more importantly, I know that you have driven several process and administration related efforts. Do you have a suggestion on what kind of useful thing we could do to address some of the bigger issues? Or better, a draft in your desk drawer that I could take forward?
Jari
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf