--On Thursday, November 12, 2015 11:25 -0500 Alia Atlas <akatlas@xxxxxxxxx> wrote: >... > Aren't the WG Chairs the ones who should be very familiar with > the drafts in their WGs and able to see problems? In Routing, > we also have the ability for > a WG chair to request that the directorate do a "QA review" on > a draft; the target for that is right at or after WG adoption > and then again at WGLC. It doesn't solve all problems, but > the more we can solve early, the better. You addressed pert of this later in your note, but WG chairs, especially of highly specialized WGs, may have a good grasp of what is going on in their WG and even the relevant Area but that is no guarantee of having any perspective on the implications of the work to possible issues in other areas or vice versa. My impression (possibly wrong) is that, among all of our areas, Routing is the last likely to be affected by work or constraints in other Areas (with the possible exception of Security); Security and ART are most likely to be affected. >... > A serious problem with finding problems late in the process is > that frequently > most of what is possible is clarifications and word-smithing. > It's hard to fix > fundamentals in something that is already implemented. Unfortunately, one implication of that statement is that, especially if the problems show in cross-area review at IETF Last Call, the IETF ends up publishing standards track specifications that contain known technical defects that are rarely even adequately acknowledged. The "we implemented this from an I-D and therefore you are required to standardize it with no significant changes" argument is one of the reasons the IETF has developed in some quarters for producing work of, at best, very uneven quality. If the IETF's aspiration is very high quality and we actually believe in it, then the IESG has to be alert for signs of fundamental problems with a spec and both able and willing to say "sorry, but that issue is fundamental and the WG needs to go back to the drawing board and fix the problem, even if it means a complete revision to the protocol and invalidating any implementations". I've seen a distinct shortage of that willingness in recent years, no matter how many hours people invest (and, by the way, people arguing strongly that the IESG should defer to the relevant WG, no matter what its issues). >... > Everyone varies in how and what they could delegate. > Certainly, that isn't my > opinion - but I'd also have to think deeply about what I could > or should delegate. I think this goes to the core of the "reduce AD workload" issue and several related ones. Some ADs will sincerely want to delegate but won't be able to figure out what best to let go of. Others will feel able to delegate only coffee-fetching or equivalent. Independent of AD preferences, the community has an at nominal preference for accountability and having an AD say "don't blame me, I delegated that to someone the Nomcom didn't seleet and neither did any other community mechanism" would probably not go over well. If the community wants to see significant changes in workload and in several of the other topics that have come up on this and related threads in recent weeks, we know of at least one way --most likely the only way-- to accomplish that. It involves changing the role of the IESG, leaving the ADs with responsibility for work-acceptance (including but not limited to WG creation and decision to accept individual submissions for processing) and WG and other process management issues, but putting responsibility for final evaluation of Last Calls and documents in the hands of another body, probably a newly-created one. That would tend to improve quality because the approval body wouldn't have any of the conflicts of responsibility associated with rejecting the work of a WG that they chartered and managed. And it would certainly reduce workload because ADs and the IESG would be responsible for reviewing documents only to the extent of determining that putting them into IETF Last Call would not be a waste of community time. Ideas along the lines of the above have been suggested several times. No IESG that was seated when the suggestions came up has been willing to let the community consider them. So, if people think that adjusting the IESG role and/or workload are important enough, I suggest that you tell it to the Nomcom and encourage them to appoint no one to an AD position who is unwilling to commit to giving ideas along those lines an open and fair evaluation in the community. john