Re: IETF areas re-organisation steps

Alia Atlas <> Fri, 26 December 2014 17:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 45E241A911A for <>; Fri, 26 Dec 2014 09:46:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k1HAHGRTpUfM for <>; Fri, 26 Dec 2014 09:46:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 378B31A1A2E for <>; Fri, 26 Dec 2014 09:46:56 -0800 (PST)
Received: by with SMTP id 131so5127311ykp.41 for <>; Fri, 26 Dec 2014 09:46:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uusPQjNvF6yiDbtlefZsd/TitYpT0HdII5m+7qos5Tc=; b=FvdgVGMBx8XKQBPBB3ImjCA1v7SrcPLIO8bGAdokbZEqh2H90obVVLCxhKdrHqIwnJ wyczi/SudU5drNFp6MOvhyxIzXlm8yIEMw9a28l8iqiiPB03eXnXHzOhFD16ge/huieC wm9KJdaiRajNMIxM93KioagQnkmC7Iymdy1doQbAqdqxWQJM4Pns/O496VDe32RMxRK1 AjtCnAFqF92WBdkyd96kFKFmT6hrs4/9puQpAAM+4D3cozK6a8/gt9/eZ5ltALWmzTSR 98+AOudupW1ispEVcOQz6Yi5TUqFhkMJk+Zmc4szejn8LbPsI+Q7NdthVAfwjfV9JN1R tGqA==
MIME-Version: 1.0
X-Received: by with SMTP id b80mr31924473yha.60.1419616014387; Fri, 26 Dec 2014 09:46:54 -0800 (PST)
Received: by with HTTP; Fri, 26 Dec 2014 09:46:54 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Fri, 26 Dec 2014 12:46:54 -0500
Message-ID: <>
Subject: Re: IETF areas re-organisation steps
From: Alia Atlas <>
To: Michael Richardson <>
Content-Type: multipart/alternative; boundary=047d7b5d99a341525a050b221ceb
Cc: 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 17:46:59 -0000

Hi Michael,

On Fri, Dec 26, 2014 at 12:06 PM, Michael Richardson <>

> [I guess maybe future discussion might call this the "Xmas IESG Reorg"?]
> Jari Arkko <> wrote:
>     > 1) Agility: The IESG should be able to adapt as Internet engineering
>     > evolves.  When work focus shifts and new technologies emerge, it is
>     > critical that the the IESG can follow the shift and effectively
> manage
>     > the new work.
> I think that this is good.
> ...
>     > 4) Sustainability: The Area Director role should be a position that
>     > accomplished engineers aspire to and that employers want to support.
> We
>     > should emphasize the "steering" and "director" aspects, supporting
> and
>     > guiding the technical work in the working groups.
> Good...
>     > The ability to react to changes in the industry, for example the IESG
>     > YANG Model Work Redistribution [3], requires flexibility within the
>     > IETF leadership positions. There are numerous instances where the
>     > constituency of a WG exists in a particular IETF area, but the most
>     > appropriate AD for that work happens to be in a different area, or
>     > where the ADs in the area are simply overloaded and an AD outside of
>     > the area is perfectly capable of managing the work. To address these
>     > possibilities, the IESG is moving towards a model where a WG can
> exist
>     > in one area, but its shepherding AD comes from another area. This
> I think that this is perhaps the most important result.
>     > The IESG is considering requesting that the currently seated nomcom
>     > select an additional routing AD, such that two new routing ADs,
> rather
>     > than one, would be seated for two-year terms in spring 2015. The
>     > reasoning behind this request is that the load in the RTG area is
>     > currently unsustainably high. The placement of a third AD will have
> the
>     > effect of spreading that load such that the time requirement may now
> be
>     > more consistent with the work loads of ADs in other areas. The total
>     > number of ADs on the IESG would not change if the APP seat remains
>     > vacant.
> 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
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
load being about 8 WGs/AD.

Of course, in the next two years, it is likely that at least a couple WGs
will close.
The load from YANG work may decrease and regardless, the structure being
well established should reduce the work.

Between these three factors, a third routing AD would be quite useful in
the load more reasonable - possibly down to a theoretical 80%.

> <nomcom hat>
> I want to note to the community that the list of RTG AD candidates is large
> and highly qualified. Will the desired qualifications change in any way?
> Will the community need a chance to provide further feedback on this?
> When will the IESG make this decision?
> </nomcom hat>

Obviously, the IESG is soliciting feedback from the community now; I expect
that process to continue until mid-January.

I am quite aware that we have lots of excellent routing AD candidates this
I personally do not see a reason to change the desired qualifications.


>     > As previously noted [1], a significant amount of the work that is
> going
>     > on in the APP area pertains to the web protocols, but that has a good
>     > deal of crossover with work in RAI. There is also some crossover work
>     > between the APP and TSV areas. To accommodate these overlaps and
>     > provide better WG management across these three areas, the IESG is
>     > proposing to merge the APP, RAI, and TSV areas into one combined
>     > Network Applications (NAPP) area. From March 2015-March 2016, this
> Oh, please can we call it the "Network Working Group" :-)
> seriously: I think that this is a great idea.
> I'm curious if over time the four/five ADs would wind up specializing
> (SIP things, email things, web-things, congestion-related things), or
> if the Home AD for would be intentionally mixed up so as keep silos from
> forming.
> I imagine the various directorates will remain.
> I suggest that the WGs remain "affliated" to directorates, and we may want
> to
> create more of them, and that perhaps, in general, that WGs will affliate
> to
> areas identified by directorates rather than by ADs.
> THIS AFFLIATION might be prove useful and important when doing meeting
> scheduling.
>     > starting in March 2016. If possible, we could reduce down to 4 NAPP
> ADs
>     > prior to that time and re-assign the fifth AD’s duties to further
> help
>     > balance IESG load.
> I would raise the possibility that the fifth ADs' role could be that of
> either "IETF Chair-in-training" or "past-IETF Chair", and that the process
> of
> succession planning for IETF Chair could perhaps be made more explicit.
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]        |   ruby on
> rails    [