On Aug 13, 2011, at 4:43 PM, John Leslie wrote: > ned+ietf@xxxxxxxxxxxxxxxxx <ned+ietf@xxxxxxxxxxxxxxxxx> wrote: >> >> I really have to wonder if the entire yes/no-obj/discuss voting model >> is appropriate for document advancement. For initial approval at >> proposed, sure, having the ability to "discuss" the document makes >> all sorts of sense. But for subsequent steps that virtue is a lot >> obvious, to me at least. > > This, IMHO, is the right question: Does yes/no-obj/discuss resolve > the right issues when advancing from PS to DS? IMO, IESG members ought to be able to vote "no" if, after first voting "discuss" and not having the issue resolved within a well-defined amount of time, they still believe that the document should not progress. That goes for any standards level. (That's not to say that a single "no" vote should suffice to block progress of a document.) "Discuss" is not the problem. "Discuss" is actually a really good idea. The problem is the lack of a "no" vote, which causes people to interpret "discuss" as if it were "no". If an IESG member sees something about a document that is suspect, it's entirely appropriate for him or her to raise questions about it. That's their job. And if the explanation is satisfactory, or the problem is fixed, it's then appropriate for the vote to be changed to "no objection" or "yes". But if the problem isn't fixed, and the problem is substantial, the IESG member ought to be able to - IMO, has an obligation to - vote "no". Anything else is dishonest and irresponsible. The history of engineering is full of serious accidents that have been caused by technical reviews being ignored due to political pressure. Anybody can make a mistake, including IESG members. It's okay to make an occasional bad review. It's not okay to lie about that review. Now there's a quite valid question about what kinds of objections IESG should be able to raise at PS vs DS or whatever. And it's arguable that the criteria for PS and DS (or IS) should be different. In particular, a revision of a document for DS is not an invitation to change the protocol, or even to fix deficiencies in the original design of the protocol. I don't even think that advancement to DS should be considered an invitation to rewrite the document. That's not to say that standards-track RFCs should never be revised, but that revising them should be done very conservatively (so as to make as few changes as possible to the text and especially organization of the document) and that this should be treated separately from advancement in grade. Keith _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf