IETF reorganization

At 20:25 25/12/2014, IETF Chair 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
Dear Community:

The IESG is considering a change in structure, 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. 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. While the specific amount of work in any IETF area fluctuates over time, we have noticed that the number of WGs in the APP area, particularly on the non-web protocols, is currently shrinking. So we are starting to think about reorganizing the areas a bit, possibly merging parts (or all) of the APP and RAI areas into a single area, possibly redistributing work in other ways between all of the areas, but in any event changing the load balance among the areas and the ADs, while continuing the work that the WGs are currently doing. It is explicitly not our intention to bar any existing or new work from the IETF with these changes. We are committing to coming up with a proposal to the community for that by May 2015. We believe the end result of that could be to reduce the number of areas by one.

In the short term, however, we would like to advise the NomCom to *not* fill the APP AD vacancy in this NomCom cycle. We believe the current load can be handled by the one remaining APP AD, and the RAI and TSV ADs are committed to helping out if need be. We believe that it is unreasonable to have the NomCom find a new AD and ask them to commit to two years only to discover later that we may want to eliminate or significantly change the responsibilities for that position within a year. Whether the end result is that we end up with a combined larger RAI/APP area that requires three ADs, or recombining in some other way, we think reducing down to 14 ADs in this NomCom cycle is the right thing to do.

We want and need community consultation on this topic. We believe this is the correct path, but we need to hear if there are any concerns from the rest of the community before we tell the NomCom to do this. Please send your comments toietf at ietf.org, or alternatively to iesg at ietf.org if you prefer, by 13 October 2014. We need to let the NomCom know ASAP if we decide to move forward with this.

Jari Arkko for the IESG

[2] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13364.html
Dear NomCom (Cc IAB),

As we indicated in our earlier message to the community, the IESG is planning to reorganise areas and working groups within areas. This is done to better match our structure to current topics in the IETF, and to increase our ability to deal with the naturally occurring fluctuations in the topic areas. While there are ideas about what this would mean in practice, our plan is to work within the IESG and the community in the coming months to come up with a detailed plan by May 2015. However, it seems clear to us that the reorganisation will affect the applications and real-time applications areas. The IETF remains working very actively on these areas, but it is expected that the number of area directors overseeing applications work can be smaller (and perhaps increase in other areas). The IESG is in charge of organising its work, and a part of that is proper matching management resources to current topic areas. The IESG felt that at this time, not filling the position of the other APP area director would be a prudent course of action. It would match our view about where the topic areas currently are at, would still retain sufficient expertise in the IESG, and would give maximum flexibility for making a restructuring decision in 2015.

We put the above information to the community, and there have been a number of concerns about telling you to simply not fill the position. Some comments indicated that we should ask you to fill it for a one year term, or that we should focus on other aspects of the IESG’s organisation, and so on. But we heard no concerns about undertaking the reorganization in principle. In the meantime, some willing nominees for the APP area position have surfaced.

As a result, the IESG would like to inform you that you (and the IAB as a confirming body) should choose to do what you decide is best. You can either fill the seat or not fill it. However, the IESG does believe that leaving the seat un-filled at this time would be the best course of action. If the seat is filled, the candidates should be aware that we think the skillset described in the desired qualifications is not accurate as it stands, and candidates should be prepared to help in the reorganization, which may end them up in a position with an as-yet-undefined set of skills and responsibilities. But again, we don't think it's strictly necessary that you fill the position.

Barry Leiba (Nomcom Liaison) for the IESG

[3] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13576.html
The IESG plans on redistributing workload in order to allow for resources to be focused on YANG model coordination. Discussion on how to do so based on demand has been going on for some time.

https://www.ietf.org/blog/2014/11/yang-really-takes-off-in-the-industry/

Primary oversight responsibility and coordination of this work across areas (AD document ownership) becomes the responsibility of Benoit Claise.

Working groups with YANG model work remain the responsibility of the currently responsible AD.

A YANG Model Coordination group (a RFC2418 directorate) will be created by the IESG to assist the AD and complement the work of the, YANG Doctors, Operations and Management Directorate and Routing area directorate and IAB liaison managers. The YANG doctor's responsibility to validate models remains unchanged. The YANG Model Coordination group will consist of up to three members initially and report to the Operations and Management AD assuming the YANG Model work.

The responsible AD for some Operations and Management working groups will be shifted to in order to distribute the workload. For now the area associated with the working-group doesn't change.

The Title of Operations and Management AD remains associated with the current responsibilities. New BOFs or working groups created to support YANG model work will be assigned to the appropriate area. As with SNMP MIBs the preference is for work to occur in the working group where the expertise exists for each data model.

The IESG thinks about organizational effectiveness on an ongoing basis both tactically and strategically; When newly seated ADs are installed in March It is likely that the distribution of working groups will be revisited, as it typically is in a more limited fashion.

Jari Arkko for the IESG

YANG Really Takes Off in the Industry

Just after the IETF 90 meeting last July, I posted this “YANG Takes Off in the Industry” blog.

One IETF meeting 91 later (just 2 weeks ago), the trend is confirmed: a big wave of YANG models is coming!

This big wave was confirmed by Dave Ward, in his “Open Standards, Open Source, Open Loop” talk to the IETF community.

New YANG models are not only seen in the OPS area, but also in the RTG, INT, TSV, and SEC areas. In total, about 20 working groups, 65 YANG model Internet-Drafts currently active, and 43 of these are at version 00. Granted, there are some redundant drafts, while the community organizes itself, but this shows a willingness to build data models with the YANG language [RFC 6020]. There are two types of models. First, the protocol-specific YANG models: For example QoS, ISIS, OSPF, MPLS, Traffic Engineering, 6Tisch, Multicast … to name a few. However, the end goal is for the operators to create services out of these building blocks, and some services YANG models start to appear at IETF, such as L2VPN or L3VPN. Some (services) YANG models were discussed in the different BoFs: In Abstraction and Control of Transport Networks (ACTN), in I2NSF (Interface to Network Security Functions, and also in the SUPA (Shared Unified Policy Automation) bar BoF

The second YANG Advice and Editing Session, was again a success with 15 YANG models reviewed by the YANG doctors. I was extremely pleased to see one operator, with a “newcomer” badge, present at this session to get feedback on his YANG model. Note that, in preparation for the review of all these YANG models, the YANG doctors team recently expanded.

Finally, a new working group, LIME, has been created just before the IETF meeting, focusing on YANG data model(s) for generic layer-independent and technology-independent configuration, reporting and presentation for Operations, Administration, and Maintenance (OAM) mechanisms.

It’s great to see some YANG traction within the IETF, and in the industry. My prediction is that more YANG models will follow. Many more, and not only from the IETF but from different Standard Development Organizations and consortia. Now it’s time to organize the coordination of all these YANG model so that the big wave doesn’t turn into a tsunami.

Benoit Claise, OPS Area Director

This entry was posted in IETF on 2014/11/27.