On Aug 13, 2011, at 4:43 PM, John Leslie wrote:
ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com
<ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf