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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to