This message was originally sent during holidays, but I was asked to re-send it now that most of us are back in the office. 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
