--On Friday, May 06, 2011 18:15 +0200 Martin Rex <mrex@xxxxxxx> wrote: > The real problem tha the IETF is regularly facing are > constituencies that will fight hard against specifications > getting updated, improved or fixed, once they have been > published as RFC. Martin, That is an interesting observation/ claim. Because I don't think I've seen that happen, I'd appreciate some examples. I have seen: * Insistence that any updated version of a document address all known outstanding issues, including insistence that the revised document not move forward until specific changes for which there is no clear consensus be included. In other words, if there is community consensus for changes A and B to document X, but no consensus that change C is needed (or appropriate, or even correct) some people will try to block approval of an X-bis that incorporates only changes A and B until everyone agrees to C. That is a very difficult problem in any standards body. We have sometimes gotten around it by explicitly noting that issue C remains controversial, but rarely without some resistance. But the problem isn't resistance to updates and improvements, only controversy about whether the changes are sufficient. * Insistence by various groups, often (at least apparently) only the IESG, that any document being revised be altered to conform to multiple requirements for content or editorial style that are more recent than the original document and in spite a no evidence that that older style or organization was causing any problems. That clearly makes it more difficult to get an update with actual corrections, etc., issued than it might be. But I've not seen anything that I interpret as evidence of resistance to change or updates once an RFC is published, only procedural and editorial requirements for publication of updated documents that sometimes create barriers that seem unnecessary and inappropriate. * Certainly WGs and others tend to run out of energy once initial RFCs are published. If no one is willing to produce a new or updated draft and persuade others to review it, then revisions are not going to happen. But your comment implies active opposition to such revisions: "no energy" is not active opposition. Indeed, while I don't think it is justified in today's environment, IIR part of what caused the 2026 "advance or die" provision was the belief that, if no one cared enough about a given specification to advance it, maybe we didn't need it any more. As someone who has been responsible for several RFCs and who has worked on updates to a large subset of them, I've seen a lot of pushback asking for "more", but little or no pushback for the idea of reviewing and revising specs. While I see those issues as significant, none of them have anything to do with this particular proposal: they apply equally regardless of how many steps there are in the Standards Track, apply to documents being recycled in grade, and even apply to non-standards-track materials. So you may be seeing things that I'm not (behaviors do differ between areas and even among protocol families within an area) but, if you are seeing active pushback on making revisions, I'd be interested in hearing specifics about that, what you would propose to do about it, and why this document is either helpful or unhelpful in that regard. regards, john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf