--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