Keith,
With the understanding that I completely agree that this
wouldn't be easy, especially in the transition, I think parts of
your discussion miss a key option or two. I was struck by an
earlier comment of Dave Crocker's to the effect that we've had
problems since all of the authority got handed to the IESG. I'm
not sure whether I completely agree with that, although, in
retrospect, I can identify at least the seeds of some of these
issues from back when Dave and I were both on the IESG (i.e.,
even before your time there).
What follows is not a recommendation that we do anything, only
an outline of a different way of thinking about the issues that
might be worth considering, if only just because it generates
more options.
What we did post-Kobe was to take the IESG, which had previously
just been a "manage the WGs and IETF procedures" group and add
standards approval, process change approval, and so on. There
was some discussion during the Problem Statement effort to the
effect that the IESG had then gone forward and invented new
responsibilities and authority for itself, thereby adding
further to the workload, but, even if that were true, the
increment was insignificant compared to the immediate post-Kobe
changes. And, for better or worse, the administrative
reorganization has now explicitly added a certain amount of
external administrative process oversight to the mix.
There was also some discussion during the Problem Statement
effort that this aggregation of responsibilities onto the IESG
created some conflict of interest problems. To the credit of
everyone who has served on the IESG in recent years, it hasn't
happened as much, or had as serious an impact, as one might have
feared, but having an IESG member as manager, shepherd, and
advocate for a WG and its products involves an inherent conflict
with the type of cold-hearted and objective review that is
desirable for quality-focused reviews.
I don't know if it is the right thing to do, or if this is the
right time, or how to make the transition, but we could rethink
the notion that a single "IESG" is the right body to manage WGs
and process, to make decisions about process and processing
rules, and do manage and conduct review of documents proposed
for standardization or other forms of publication. If we
thought it was appropriate and split some of those things up
into separate bodies, we would almost immediately change the
IESG's workload and might, in addition, change the job
description to the point that a larger range of people would be
qualified to serve on any given one of those bodies.
But maybe these wider ranges of options are, at some point,
worth thinking about rather than assuming that any effort to
spread the load out would inherently result in lower quality.
john
--On Tuesday, 26 April, 2005 21:41 -0400 Keith Moore
<moore@xxxxxxxxxx> wrote:
>> I wasn't advocating for more ADs, but for more 'virtual' ADs,
>> i.e., to move the work of reviewing out of the ADs, and let
>> the ADs distrbute the reviews and collect and interpret the
>> results.
>
> This is _more_ work for the ADs, not less, because the ADs
> have to read the reviews in addition to the documents. You
> might ask why the ADs' reviews are better than the virtual
> ADs' reviews. It's not inherently the case, of course, but
> the "real" ADs will be exposed to more information that
> informs such reviews, and the "real" ADs are in a better
> position to work out technical compromises that helps keep
> different protocols from fighting with one another. (for
> instance, keeping linklocal addressing or site-local
> addressing from doing harm to application-level
> interoperability).
>
> What you are advocating would help if the majority of
> documents presented to IESG were not close to being acceptable
> for standards track. But that's not the case. The majority
> of documents are close to being acceptable - maybe 10% are not
> close. But it can take a lot of work for those documents that
> are "close" to be made
>...
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf