Re: IETF areas re-organisation steps

Michael Richardson <> Fri, 26 December 2014 17:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 360681A908F for <>; Fri, 26 Dec 2014 09:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PzTdOifcHq16 for <>; Fri, 26 Dec 2014 09:06:58 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D88AA1A8978 for <>; Fri, 26 Dec 2014 09:06:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C398D20098 for <>; Fri, 26 Dec 2014 12:11:37 -0500 (EST)
Received: by (Postfix, from userid 179) id AC93B637FE; Fri, 26 Dec 2014 12:06:56 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id 963F5637EA for <>; Fri, 26 Dec 2014 12:06:56 -0500 (EST)
From: Michael Richardson <>
To: IETF-Discussion list <>
Subject: Re: IETF areas re-organisation steps
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 26 Dec 2014 12:06:56 -0500
Message-ID: <>
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:07:00 -0000

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



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

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


    > 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

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    [