Re: IETF areas re-organisation steps
Robert Sparks <rjsparks@nostrum.com> Fri, 26 December 2014 16:27 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C251A8976 for <ietf@ietfa.amsl.com>; Fri, 26 Dec 2014 08:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb1ASWzFpbdm for <ietf@ietfa.amsl.com>; Fri, 26 Dec 2014 08:27:10 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065601A8974 for <ietf@ietf.org>; Fri, 26 Dec 2014 08:27:09 -0800 (PST)
Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBQGR82b042796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <ietf@ietf.org>; Fri, 26 Dec 2014 10:27:09 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local
Message-ID: <549D8C57.8090402@nostrum.com>
Date: Fri, 26 Dec 2014 10:27:03 -0600
From: Robert Sparks <rjsparks@nostrum.com>
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
To: ietf@ietf.org
Subject: Re: IETF areas re-organisation steps
References: <ED473823-2B1E-4431-8B42-393D20BA72DF@piuha.net>
In-Reply-To: <ED473823-2B1E-4431-8B42-393D20BA72DF@piuha.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/IA89tDOAgUBxyiyk9qciBniRBrk
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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. RJS 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. > > > PRINCIPLES > > 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. > > > THREE STEPS > > We suggest taking the three steps described below to fulfill these principles. > > > I. FURTHER SHIFTING OF WG RESPONSIBILITY TO OUT-OF-AREA ADS > > 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. > > > II. ADDING A THIRD RTG 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: > L2TPEXT, LISP, and TRILL. > > 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: > http://tools.ietf.org/html/draft-dawkins-iesg-one-or-more-04. > > > III. MERGING OF UPPER LAYER PROTOCOL AREAS > > 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 > > > REFERENCES > > [1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13314.html > [2] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13364.html > [3] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13576.html
- Re: IETF areas re-organisation steps Ted Lemon
- IETF areas re-organisation steps Jari Arkko
- Re: IETF areas re-organisation steps Huub van Helvoort
- Re: IETF areas re-organisation steps Robert Sparks
- Re: IETF areas re-organisation steps Dave Crocker
- Re: IETF areas re-organisation steps Paul Hoffman
- Re: IETF areas re-organisation steps Steve Crocker
- Re: IETF areas re-organisation steps Ted Lemon
- Re: IETF areas re-organisation steps Michael Richardson
- Re: IETF areas re-organisation steps Michael Richardson
- Re: IETF areas re-organisation steps Scott Brim
- Re: IETF areas re-organisation steps Ole Jacobsen
- Re: IETF areas re-organisation steps Dave Crocker
- Re: IETF areas re-organisation steps Alia Atlas
- WGs/AD [IETF areas re-organisation steps] Brian E Carpenter
- Re: WGs/AD [IETF areas re-organisation steps] Stephen Farrell
- Re: WGs/AD [IETF areas re-organisation steps] Alia Atlas
- Re: IETF areas re-organisation steps Phillip Hallam-Baker
- Re: WGs/AD [IETF areas re-organisation steps] Brian E Carpenter
- Re: IETF areas re-organisation steps Ted Hardie
- Re: WGs/AD [IETF areas re-organisation steps] Jari Arkko
- Re: WGs/AD [IETF areas re-organisation steps] Alia Atlas
- Re: WGs/AD [IETF areas re-organisation steps] Melinda Shore
- Re: IETF areas re-organisation steps Eggert, Lars
- Re: IETF areas re-organisation steps Nico Williams
- Re: IETF areas re-organisation steps Robert Sparks
- Re: IETF areas re-organisation steps Spencer Dawkins at IETF
- Re: IETF areas re-organisation steps Alissa Cooper
- Re: IETF areas re-organisation steps Ted Hardie
- Re: IETF areas re-organisation steps Robert Sparks
- Re: IETF areas re-organisation steps Eggert, Lars
- Re: IETF areas re-organisation steps Jari Arkko
- Re: IETF areas re-organisation steps Dave Crocker
- Re: IETF areas re-organisation steps Brian Trammell
- Re: IETF areas re-organisation steps Mary Barnes
- Re: IETF areas re-organisation steps Dave Crocker
- Re: IETF areas re-organisation steps Ben Campbell
- Re: IETF areas re-organisation steps Benoit Claise
- RE: IETF areas re-organisation steps Larry Masinter
- Re: IETF areas re-organisation steps Yoav Nir
- RE: IETF areas re-organisation steps Larry Masinter
- Re: IETF areas re-organisation steps Kathleen Moriarty
- Re: IETF areas re-organisation steps Phillip Hallam-Baker
- Re: IETF areas re-organisation steps joel jaeggli
- RE: IETF areas re-organisation steps Larry Masinter
- Re: IETF areas re-organisation steps Julian Reschke
- Re: IETF areas re-organisation steps Phillip Hallam-Baker
- Re: IETF areas re-organisation steps Brian E Carpenter
- Re: IETF areas re-organisation steps t.p.