Re: IETF areas re-organisation steps

Steve Crocker <steve@shinkuro.com> Fri, 26 December 2014 16:51 UTC

Return-Path: <steve@shinkuro.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 CD39D1A9044 for <ietf@ietfa.amsl.com>; Fri, 26 Dec 2014 08:51:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.781
X-Spam-Level:
X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no
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 XYFalKTlmzms for <ietf@ietfa.amsl.com>; Fri, 26 Dec 2014 08:50:58 -0800 (PST)
Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA561A9004 for <ietf@ietf.org>; Fri, 26 Dec 2014 08:50:58 -0800 (PST)
Received: from dummy.name; Fri, 26 Dec 2014 16:50:57 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_FB7C58DB-CABF-471B-939B-B6059ED80641"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: IETF areas re-organisation steps
From: Steve Crocker <steve@shinkuro.com>
In-Reply-To: <549D8C57.8090402@nostrum.com>
Date: Fri, 26 Dec 2014 11:50:55 -0500
Message-Id: <066F9DA5-6F6D-4BA3-A2C7-5C3F3D8E4FB2@shinkuro.com>
References: <ED473823-2B1E-4431-8B42-393D20BA72DF@piuha.net> <549D8C57.8090402@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/w2ccg8sRRFA9Y2s3hKBzKGCIsYc
Cc: ietf@ietf.org
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:51:02 -0000

From http://en.wikipedia.org/wiki/Nap_(textile)

> Primarily, nap is the raised (fuzzy) surface on certain kinds of cloth, such as velvet.

Not a bad analogy for the upper layers of the protocol stack.

Steve



On Dec 26, 2014, at 11:27 AM, Robert Sparks <rjsparks@nostrum.com> wrote:

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