Re: IESG voting procedures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]