ietf
[Top] [All Lists]

Re: IESG voting procedures

2011-08-15 13:28:37
Keith:

Convincing the entire IESG is a very high barrier, especially when
typically, most of the IESG just wants the issue to go away.    It might
happen for a significant architectural issue, perhaps, but not for an
area-specific technical flaw.

Here's the point: if an AD can't get at least one or two other ADs to
read the document and agree to join in the blocking, then that AD MUST
NOT be allowed to block the document.  That's even the case if the AD
thinks she's found a serious flaw.  Because if, out of 14 others in
the IESG, not ONE other is willing to read the document, understand
the issue, and agree on it.

That's also how I interpret the rules.  I just don't think that this is 
sufficient review.  I think that in practice it makes IESG more-or-less a 
rubber stamp for any issue that isn't easily fixed with small and often 
inconsequential changes to the document text.

The problem is, the ADs are very busy people, and their expertise has to 
cover a wide range of topics, so there will be few IESG members who can 
really understand a subtle issue.   Document reviews outside of one's subject 
area are very difficult and require considerable focus.   GIven that, even if 
only one AD catches a flaw in a document, there's a good chance (though not a 
certainty of course) that it's something that warrants more attention.   It's 
far more likely that no ADs will find the flaw because nobody really took the 
time to read the document thoroughly and to understand its implications of 
the document outside of the narrow subject area of the working group.

I understand (and agree with) the sentiment that, ultimately, one or two 
people shouldn't be able to block a document.  Nor do I want documents held 
up for trivialities as, unfortunately, sometimes happens.  But I've seen many 
cases where working groups failed to do an adequate level of review outside 
of their narrow areas of concern, and it appears that IESG's current rules 
and workload make it difficult for problems to get fixed after a document 
leaves the WG.   

My experience is that a technical flaw, even if it is a corner case, is acted 
upon by the WG.  There are rare cases where the WG has lost energy, but in 
general the WG wants to produce a quality output.  As a result, technical flaws 
are not the place where things get messy.  Rather, things get messy over issues 
that have a political component.

Russ

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf