Re: WGs/AD [IETF areas re-organisation steps]

Brian E Carpenter <> Fri, 26 December 2014 22:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D9FD1ACF08 for <>; Fri, 26 Dec 2014 14:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iFEJRKcRLchm for <>; Fri, 26 Dec 2014 14:22:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CDF51ACEF7 for <>; Fri, 26 Dec 2014 14:22:09 -0800 (PST)
Received: by with SMTP id fp1so13494611pdb.5 for <>; Fri, 26 Dec 2014 14:22:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qyZ7bn1Bo65fpMKdluuYsQYnrDYMYgr6Puzm+Xx99Ew=; b=mSmBDIVezYpbydmRVDdnCXuvCzmvCceecbFkIxWTEJNdnTR1UmnIupB3nd34w96avK FuSawMAB9APnzlqnJMY+wWG+VPZlJw6QbQKbv7ZEaPDqtqkmuJi1JAS09LDm8ss7pjsl EO2QSRnATBgm5iPGT67e6aCR81guiBPBFyNlLd6wJDl/2O0NCGVXkwxme1TBkwZXXf6Q R7pXLCAtCBaFU6maQQOhDBNLtM62OPawZNDv1dCIRfiEo0YemBz9PV89NW4bshJC/vlF boCTEcZiDW4Cs1PIgM2MckevNxx6nNkLdaR3NywTonxiT483x1tPQKJdRtZ7i+jLnYaA nVHg==
X-Received: by with SMTP id wk3mr2791187pab.95.1419632528816; Fri, 26 Dec 2014 14:22:08 -0800 (PST)
Received: from ?IPv6:2406:e007:4072:1:28cc:dc4c:9703:6781? ([2406:e007:4072:1:28cc:dc4c:9703:6781]) by with ESMTPSA id oa8sm29069343pdb.84.2014. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Dec 2014 14:22:07 -0800 (PST)
Message-ID: <>
Date: Sat, 27 Dec 2014 11:22:16 +1300
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Alia Atlas <>
Subject: Re: WGs/AD [IETF areas re-organisation steps]
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Michael Richardson <>, IETF-Discussion list <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Dec 2014 22:22:11 -0000

Hi Alia,

On 27/12/2014 08:59, Alia Atlas wrote:
> Hi Brian,
> On Fri, Dec 26, 2014 at 2:40 PM, Brian E Carpenter < 
>> wrote:
>> On 27/12/2014 06:46, Alia Atlas wrote: ...
>>>> I'm a little bit surprised that the RTG area load has gone up 
>>>> like this, and so quickly.  Is it the various SDN things that 
>>>> are pushing this, or is it
>>>> that the RTG area currently has the most enthusiasm for YANG 
>>>> work?
>>> It's a mixture of things combined with RTG already being at the 
>>> very top edge of workload.  In RTG we have/will have about 21
>>> active WGs; if we add a third routing AD, then RTG will absorb 3
>>> WGs from INT. Granted that one is not active and may be merged
>>> in, we are still looking at about 23 WGs for RTG with a more
>>> average load being about 8 WGs/AD.
>> So let's be frank about this. Today (excluding the General Area AD
>> with his crippling load of 1 WG) we have 129 WGs for 14 Ads,
>> which is 9.2 WGs/AD. That is clearly too many, so should there be
>> a target ratio and a plan for reaching it?
> No, as you well know, it depends on the size and business of the
> WGs, the management load, etc., as well as the number.  Clearly we
> don't want to not create new WGs when appropriate nor to discourage 
> existing useful work.

Of course, an average is only an average, but the point is: we've
had about 125 WGs for at least ten years now, and we've had
over-burdened ADs for all that time. That seems to be a fundamental
problem, regardless of the sort of adjustments the IESG is currently

There are two words in your second sentence above implying a value
judgment: "appropriate" and "useful". Unfortunately, as far as I can
tell, the only way to truly manage the IESG workload is by raising
the bar for "appropriate" and "useful". (The same applies to
the bar for a WG to adopt a particular work item.)

> This is a question of balancing load and there is a surge of 
> YANG-related work which does require more focused management.  Is it 
> better to have 2 ADs at 100%-120% and others with less load when the 
> size of the IESG would be otherwise reduced.  Are you suggesting
> that suggesting another routing AD to take load from RTG and INT is a
> bad idea compared to dropping the IESG to 14 & eventually 13?

No, I was specifically trying to avoid being specific. I think we have a
general long-term problem.

It's entirely appropriate for the IESG to propose workload re-balancing
to deal with the current workload. I may have some quibbles, but it's the
IESG's decision.

> Are you simply concerned with the dynamics of how many ADs have the 
> various perspectives on the IESG?
> Obviously, we are looking for feedback and opinions and ideas.  Do 
> you have other well thought out suggestions?

In terms of the long-term problem, unless I am mistaken, neither the IESG
nor the community has ever said much about how to make the judgment calls
that new work is useful and appropriate for the IETF. We've got a very
good document to help BOF proponents (RFC 5434) but I don't think we've
ever tackled the next bit: deciding whether this work should be chartered?

One result of that is that proponents who have what they think is a
successful BOF are sometimes very puzzled and frustrated by their
failure to form a WG. Another result is that it's a bit harder for
the IESG to say "no" than it would be if the decision criteria were
a bit more transparent. A third aspect is that every new IESG member
has to discover for herself how this vital bit of the process works
on the inside.

I think my suggestion is that to have any serious hope of controlling
the workload *in the long term*, we need to have something (it could be
an IESG statement, it could be an RFC) the stakes out a position on
what it means for a WG or work item to be judged appropriate and useful.