Experiences from Cross-Area Work at the IETF
draft-arkko-iesg-crossarea-00

Abstract

This memo discusses the reasons for IETF work on topics that cross area boundaries. Such cross-area work presents challenges for the organization of the IETF as well as on how interested parties can participate the work. The memo also provides some suggestions on managing these challenges.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on June 01, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Examples of Cross-Area Work
• 3. Rationale for Cross-Area Work
• 4. Challenges
• 5. Recommendations
• 6. References
• Appendix A. Acknowledgments
• Author's Address

1. Introduction

This memo discusses IETF work that crosses area boundaries. Some examples about such work are given in Section 2. The reasons for initiating work that involves cross-area aspects are discussed in Section 3. Cross-area work presents challenges for the organization of the IETF as well as on how interested parties can participate the work. These issues are discussed in Section 4. Finally, Section 5 provides some suggestions on managing these challenges in an effective way.

2. Examples of Cross-Area Work

Many IETF efforts cross area boundaries. Some recent examples of such work include:

• The development of a routing-protocol based bridging model. This work has been going on in the TRILL WG on the Internet Area and in parallel in the ISIS WG on the Routing Area.
• The work that started in 2008-2009 to address impending IPv4 address runout and remaining needs for transition mechanisms to support IPv6 deployment. This was worked on in the V6OPS WG on the Operations and Management Area, in the BEHAVE WG on the Transport Area, and in the SOFTWIRE WG on the Internet Area.
• The HOMENET WG is developing automatic provisioning tools for home networks and will require assistance from, for instance, Routing Area WGs to build the necessary routing protocol zero-configuration extensions.
• The RENUM WG on the Operations and Management Area is addressing renumbering issues, but will have to work with other areas if changes or extensions to specific protocols are required.
• The allocation of a new private address space to employ a shared address for multiple subscribers in networks employing NAT44 was discussed in the INTAREA, OPSAREA, BEHAVE, and V6OPS WGs.
• The LWIG WG on the Internet Area is documenting existing practices for creating lightweight implementations of the TCP/IP stack and application protocols. Specific recommendations on transport and application protocols obviously need participation from those areas, however.
• The Routing Area, Transport Area, and Security Area have worked together on security mechanisms and key management tools necessary to secure BGP sessions carried on top of TCP.
• Many IETF topics involve operational aspects as well as protocol development. For instance, issues with address selection policies have been discussed in the V6OPS WG on the Operations and Management Area, and solutions for these problems were taken up by the 6MAN WG on the Internet Area.

3. Rationale for Cross-Area Work

Cross-area work is needed, of course, in any situation where a particular technical problem does not cleanly map to one organization. For instance, some problems may be more about the entire system than any individual node or protocol layer. The work done in the RENUM and LWIG WGs falls into this category, for instance.

In other cases different organizations may have specific expertise that is helpful to solve a problem. For instance, some models of interworking between IPv4 and IPv6 required expertise both from the specialists on IPv6 on the Internet Area and the specialists on translation tools on the Transport Area. A common form of providing expertise from multiple areas involves operational aspects and protocol development. Such work often happens in a sequential manner. The operators first discuss practical problems, then provide suggestions for operational ways to contain the problems, and eventually may ask for new solutions to reduce these problems. The actual solution work is then taken up by the relevant technical community that works on the protocol that needs to be extended.

Another common example of a situation where two different areas of expertise are needed is developing security features for a protocol. The protocol specialists are needed to understand the application and its requirements and the security specialists are needed to help with understanding the possible security issues and potential solutions. Such work is commonly not organized as cross-area work, however. Typically, a "security advisor" is assigned to a protocol working group. The advisor and other security experts merely attend the group. The same model is used, for instance, with MIB doctors and is also often used to provide routing area expertise. However, in some cases the need to work together goes beyond such individual participation. For instance, the security mechanisms and their key management tools necessary to secure BGP sessions carried on top of TCP have led to the creation of significant efforts both in the Routing and Security Areas.

Sometimes a large body of work is split into different parts merely to share the workload. The IPv6 transition topic has been so big for the IETF that part of the reason for splitting the work to three areas was to ensure there was enough participants, chairs, and area directors to handle the workload.

4. Challenges

Cross-area work does present some challenges, however. Apart from the advisor model there are no established practices and the processes and division of responsibility differs from case to case [RFC2026].

Some of the issues include:

Fuzzy Hot Topics

Many recently proposed "hot" areas of work for the IETF have been on vaguely defined topics that cover many possible areas. For instance, work on new technologies for data centers or cloud computing. In many cases it is unclear if the topic is truly a cross-area topic through some fundamental reason, or if the IETF has just not succeeded yet in teasing out concrete tasks from this topic. For instance, while data center networking in general is a very broad topic, specific improvements on ARP performance discussed in the ARMD WG is a clearly identifiable topic that falls on the Internet Area as soon as it becomes clear that there is operational evidence for the need to make ARP modifications.

Area Shopping

If the IESG does not manage the process in an coordinated manner, this can lead to "area shopping" where a particular topic is being discussed in several areas and working groups and may be taken up in one area even if if dismissed in others. This may be fine, if the decision is made due to the topic fitting better an area. But it is also possible that concerns raised in one forum are not understood in another, and this can lead to an effort going forward after finding the "lowest bar" forum to take it up.

Lack of Common IESG Vision

In many of the complex cross-area topics, the IESG has initially had no strategy on how the work shall be divided, or even on the goals. The IESG has also had several internal arguments over some topics. Clearly, establishing a common vision between the relevant ADs for how to proceed with a given topic is essential for a successful outcome. Part of the problem here is that IESG does not normally develop a master plan, but rather individual documents and charter proposals are brought to the IESG in a piecemeal fashion, one by one. This can cause surprises. Similarly, the yearly changes to the people on the IESG may change the position that IESG members have on a topic, which again can lead to surprises to the community.

Problem Ownership

A more common issue is that the different organizations typically have different motivations. A group of developers may be very interested in solving, say, a bridging problem in a particular way and funded full time by their employers to do this work. If this group is dependent on some other people on making changes to a technology that they are in charge of, it is likely that there is no similar level of commitment. The other people are unlikely to be able to spend all their time on this project, for instance. This creates an eventual tussle between different interests and may lead to frustration and different expectations on the timelines necessary for the work.

Of course, the other side of the issue is that in most cases it would not be a good idea to let the first group develop the necessary changes by themselves either. Often the second group is the true expert on the technology and needs to be involved in order for a change to be done so that it does not cause breakage elsewhere.

Rigid Topic Ownership

A related issue is that topic ownership should not necessarily be static over time. Sometimes it makes sense to review and change the area that is responsible for a particular topic. Many working groups and topics have moved back and forth between Internet and Routing or Applications and Transport areas, for instance. A periodic review and re-assessment is encouraged.

Attention Focus

It is natural for the leaders of an organization to develop a closer relationship with work within their own part of the organization. An AD may make a status check with his own WG chairs, for instance, but not with those on neighboring areas working on another half of some common topic.

Scheduling

Current IETF scheduling principle is centered around a sequences of meetings of working groups in the same area. This makes it possible for someone to follow all meetings in his or hers area, and enables the ADs to attend all the meetings they have to. Cross-area work breaks this principle, as, for instance, technical experts on some commonly used technology now may have to attend a meeting from another area. The same applies to ADs and chairs. This has been a practical problem for Internet Area ADs, for instance, as they have to attend V6OPS and BEHAVE WG meetings in addition to their own, but this is not readily apparent to the people who perform scheduling.

Process vs. Substance

Finally, in recent years there has been a tendency to take up organizational discussions in the precious few hours that we have for face-to-face discussions at the IETF. The author believes that it would be most useful to reserve the face-to-face discussion time for the difficult technical topics, and the relevant chairs and ADs should decide organizational matters off-line after a consultation with the list.

Cross-area and cross-WG work, duplicated presentations in multiple forums, and formal messages between groups are usually not good signs about the health of a standards organization. Too much time may be spent on internal discussions, and too little on technical substance, running code, and customer or user input.

5. Recommendations

There are no hard and fast rules for complex development efforts that span multiple areas of expertise. However, the author believes that experience has shown the following guidelines can improve the situation in many cases.

1. Complex organizational structure should not be initiated lightly. It should be reserved for situations that truly demand it. Re-organization and moving responsibilities to one place should be considered as alternatives.
2. People matter, organizations do not. The essence of most cross-area work is getting the right expertise to the room and to the list. This does not happen through mere organizational forms, people have to be interested about the problem.
   • Example: The IPv6 transition problem has been such an interesting issue for a large class of IETF contributors that a significant number of key participants appear in the relevant meetings no matter what area or working group they are under.
3. Chair and advisor selection. Given that people matter, many cross-area issues can be solved through assigning suitable people to act as chairs and technical advisors. For instance, many groups have one chair focused on protocol aspects and another one focused on operational aspects. Typically, the first type of a chair has protocol design and implementation experience in the topic, and the second one may be operating networks and may have an Operations and Management Area background.
4. Cross-area review. Similarly, expertise is not brought in by an area designation, it is brought through the right people actually reading the specifications. Encouraging cross-area review is therefore helpful, for instance through directorates assigned to review important documents from other areas.
5. Ensure that the IESG has a clear understanding of the topic area and the plan ahead. It is recommended that the IESG discusses the division of responsibilities and the plan for any major cross-area effort upfront, and documents the agreed plan in writing. Plans may naturally have to be revisited, as understanding the needs for further work is a continuous process. In addition, as the membership of the IESG evolves, it is necessary to ensure that the new members are happy with the plan.
6. The best examples of successful cross-area work involve combining two pieces of expertise, with both parties having an incentive to complete the work.
7. One good model that has been used in the Internet Area employs a protocol detail working group and a consumer working group.
   
   This model has been used with work that touches upon the DHCP protocol, for instance. There are always two working groups: the protocol working group and the consumer working group. The DHC WG is not chartered to develop any extensions except for maintaining the DHCP infrastructure itself. Extensions for a specific application purpose (such as delivering location information) must be owned by some other working group that is chartered to develop those applications (such as the GEOPRIV WG in the Real-Time Applications Area). The role of this consumer working group is to drive the development of the entire application where a DHCP option may play a small role.
   
   The role of the DHC WG is to ensure that the DHCP aspects of these extensions are properly designed. It is often easy to see how the DHCP experts are clearly better at designing the right container and behavior model for the DHCP part, and how the consumer working group experts clearly understand the semantics and needs for the actual data much better.
   
   Division of responsibilities in this manner is encouraged in other situations as well.
8. Scheduling models for the IETF should take cross-area work into account in a better way. Possible tools to improve this include ability to specify ADs from multiple areas as interested in a working group or the ability to specify entire areas as conflicts in the meeting request tool.
9. In general, the ability to associate work with all the areas that it relates to will be helpful not just for scheduling, but also for participants following an area of work, review teams, and so on.

6. References

Appendix A. Acknowledgments

The author would like to thank the rest of the IESG for inspiring discussions around the IETF processes. In particular, Dan Romascanu, Russ Housley, Lars Eggert, David Harrington, Ron Bonica, Robert Sparks, and Stewart Bryant provided input. Nothing in this draft should be interpreted as an IESG opinion, however, as the draft is the author's opinion only.

The author would also like to thank Joel Halpern, Keith Moore, Paul Hoffman, Samita Chakrabarti, Melinda Shore, and Dan Wing for feedback.

Author's Address