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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf