Re: IETF areas re-organisation steps

Robert Sparks <> Fri, 26 December 2014 16:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 81C251A8976 for <>; Fri, 26 Dec 2014 08:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xb1ASWzFpbdm for <>; Fri, 26 Dec 2014 08:27:10 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 065601A8974 for <>; Fri, 26 Dec 2014 08:27:09 -0800 (PST)
Received: from unnumerable.local ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id sBQGR82b042796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Fri, 26 Dec 2014 10:27:09 -0600 (CST) (envelope-from
X-Authentication-Warning: Host [] claimed to be unnumerable.local
Message-ID: <>
Date: Fri, 26 Dec 2014 10:27:03 -0600
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
Subject: Re: IETF areas re-organisation steps
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
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 16:27:12 -0000

I have several reactions to this, but one in particular I wanted to get 
into the conversation early.

Why did you settle on a proposed name for the combined upper-layers area 
that implies it will be sleeping?

This is more than just trying to pick a nit on the name. The IESG 
certainly couldn't have collectively missed that interpretation.

I'm surprised at the message this seems to be sending - can you share 
more about what the group has been discussing and thinking that led to 
this choice?

I would think it would make getting ADs even harder to be asking 
companies to sponsor an AD of napping.


On 12/25/14 1:16 PM, Jari Arkko wrote:
> Dear Community:
> In October, we let you know that we would be coming up with some proposals
> and consulting with you on the topic of re-organizing the IESG and the IETF
> areas with the intent to increase flexibility as IETF work evolves, to ensure that
> all IETF work is covered by an AD, and to balance and reduce the workload
> across the ADs [1]. We committed to developing a re-organization proposal by
> May 2015 (thus including ADs that will be newly seated in March 2015). We
> have taken several steps since then toward that goal: we recommended that the
> nomcom not to fill the APP AD vacancy in the current nomcom cycle [2], and we
> are taking steps to redistribute workload in order to allow for more resources
> to be focused on YANG model coordination [3].
> This message provides an outline of further steps we propose to take in 2015
> as part of the re-organization and invites community feedback on those steps.
> Step I below is already in progress. Step II in particular requires timely
> action, and therefore we are requesting community feedback by January 15,
> 2015 on that step in particular and on the overall proposal.
> None of the steps below should be viewed as permanent or overly constraining
> how the IESG and the areas might be organized in future years. In general we’d
> like to increase the ability for the IESG to be flexible going forward. We are
> suggesting the steps below as measures to experiment with as a means to
> determine their effectiveness. The IESG intends to continue to re-evaluate all
> of the steps on a regular basis.
> The IESG believes the re-organization should proceed according to the
> following principles:
> 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.
> 2) Relevance: The organization of the technical work must facilitate the
> IETF's continued relevance to the industry. As we change how we develop
> technology throughout the Internet, the IETF must be able to change how our
> standards development works with the technology development.
> 3) Flexibility: The organization of the IESG and of the technical areas should
> accommodate variations in workloads, time commitments, and AD skillsets, as
> well as changes in those over time. It is important to make it possible for
> more IETF participants to be able to serve as Area Directors and to make the
> work co-exist with their normal jobs.
> 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.
> We suggest taking the three steps described below to fulfill these principles.
> 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
> flexibility will allow the IESG to apply its skills where they can be of most
> use while still keeping related WGs together within an area. The IESG proposes
> to experiment with this approach initially by shifting to out-of-area ADs for
> RADEXT, DIME, LMAP, and ANIMA, perhaps with another few WGs to follow.
> In order to achieve the above, there is some tools development work needed.
> Many components of the IETF tool set (e.g., the datatracker) make assumptions
> about WG/AD relationships based on the WG's assigned area. That issue is
> currently being worked on by the tools team, but will take a few months' time.
> During this intermediate period (prior to the tools work completing), the
> cross-area shepherding effort will be done informally by the IESG. This
> informal approach will address:
> a. Shepherding AD - Each WG will still have an AD assigned to it from its
> area, referred to as the Home Area AD. The actual shepherding AD will be
> temporarily listed as the Technical Advisor. The shepherding AD will be in
> charge of all WG management issues. The IESG will develop a way to explicitly
> indicate the shepherding AD on the WG's charter page.
> b. E-mail aliases - WG chairs and participants who wish to reach the ADs for a
> WG via the <foo>-ads tools aliases should explicitly include the AD listed as
> Technical Advisor for the WG.
> c. Document shepherding - When a WG chair submits a publication request, that
> request will flow to the Home Area AD. The Home Area AD should then delegate
> shepherding responsibilities to the shepherding AD for handling.
> d. Appeals - IETF participants should be directed to send any appeals related
> to the WG to the shepherding AD rather than the Home Area AD.
> 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.
> This request is further justified by the considerable increase in
> management-related work in the RTG area. Specifically, there are a lot of new
> YANG models being written. Although the coordination of YANG across the IETF
> falls as the responsibility of the OPS ADs (specifically the Management AD) it
> is expected that the RTG ADs will need to work on an increasing number of YANG
> documents as well.
> If an additional RTG AD were to be seated, the IESG would propose to move
> three working groups from the INT area to the RTG area to balance AD loads:
> As with all of the proposed organizational changes, the IESG would expect to
> re-evaluate the need for this third RTG AD in future years and balance that
> need against the need to have other skill sets or more generalist roles
> represented on the IESG.
> Work is underway to create support for this model in our process documentation:
> 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 combined area would be overseen by the five remaining
> ADs from APP, RAI, and TSV, with some redistribution of WG shepherding
> responsibilities among them to balance workloads. DISPATCH, TSVWG, and APPSAWG
> would continue to function much as they currently do.
> The NAPP ADs would continue to encourage progress towards closure of the many
> WGs in the area that are close to completing their chartered work. As such,
> the IESG would expect to request in the 2015-16 nomcom cycle a reduction in
> NAPP AD headcount, yielding four seated NAPP ADs 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.
> Jari Arkko for the IESG
> [1]
> [2]
> [3]