One document matched: draft-arkko-iesg-crossarea-03.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902"
     docName="draft-arkko-iesg-crossarea-03"
     category="info">

<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>

<front>

<title abbrev="Cross-Area Work">Experiences from Cross-Area Work at the IETF</title>

<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>

<date month="February" year="2013" />

<keyword>IETF</keyword>

<abstract>

<t>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.</t>

</abstract>

</front>
<middle>

<section anchor="introduction" title="Introduction">

<t>This memo discusses IETF work that crosses area boundaries. Some
examples about such work are given in <xref target="examples"/>. The
reasons for initiating work that involves cross-area aspects are
discussed in <xref target="rationale"/>. From the perspective of a
participant interested in a specific effort, the area designations
matter little. If the work is interesting, the necessary people come
to the meetings and work on the specifications. However, cross-area
work does present some challenges for the organization of the IETF as
well as on how interested parties can participate the work. These
issues are discussed in <xref target="challenges"/>. Finally, <xref
target="recommendations"/> provides some suggestions on managing these
challenges in an effective way.</t>

</section>

<section anchor="examples" title="Examples of Cross-Area Work">

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

<list style="symbols">

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>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. For instance, the SIDR and
KARP WGs are in the Routing Area, but they are clearly focused on
topics that are generally found in the Security Area.</t>

<t>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.</t>

</list>

</t>

</section>

<section anchor="rationale" title="Rationale for Cross-Area Work">

<t>From an IETF participant's point of view, it is important that
there is a working group where the technical topic that he or she is
interested in can be discussed.  The area and the management structure
matters little for this, as long as the working group can work on all of
the relevant aspects. These aspects, may, however, involve different
types of expertise or topics commonly handled in different groups of
people at the IETF.  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.</t>

<t>In other cases different types of individuals may have specific expertise
that is helpful to solve a problem. For instance, some models of
interworking between IPv4 and IPv6 required expertise 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.</t>

<t>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 advisor model is used in other instances as well, including MIB
doctors and 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.</t>

<t>Sometimes a large body of work is split into different parts merely
to spread 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.</t>

</section>

<section anchor="challenges" title="Challenges">

<t>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 <xref
target="RFC2026"/>.</t>

<t>Some of the issues include:

<list style="hanging">

<t hangText="Fuzzy Hot Topics"><vspace blankLines="1"/> 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 for some fundamental
reason, or if the IETF has just not succeeded yet in teasing out
concrete tasks from this topic. For instance, operational and
performance problems are often discussed in Operations & Management
area working groups. Sometimes, after some analysis, these problems
turn out to be something where protocol modifications or extensions
would help. But as soon as such a conclusion is made, it typically
falls on other areas to make the actual modifications. Typically,
there are existing working groups that are responsible for the
technology in question.</t>

<t hangText="Area Shopping"><vspace blankLines="1"/>

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 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.</t>

<t hangText="Lack of Common IESG Vision"><vspace blankLines="1"/>

In many of the complex cross-area topics, the IESG has initially had
no strategy on how the work shall be divided, or even a common set of
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 makes it hard to see bigger trends and possibilities for
colliding work.

<vspace blankLines="1"/>
Similarly, the yearly changes to the
people on the IESG may change the position that IESG members have
on a topic, which can lead to surprises to the community and
new discussions in the IESG.

<vspace blankLines="1"/>
These problems exist both for specific efforts and the general
strategies for handling cross-area work. IESG members have had
varying opinions on whether to create specific, formally recognized
cross-area working groups or handle them in some other way.</t>

<t hangText="Problem Ownership"><vspace blankLines="1"/>

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 they are funded full-time by their employers to get this work done. 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 not a 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.
<vspace blankLines="1"/>
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.</t>

<t hangText="Rigid Topic Ownership"><vspace blankLines="1"/>

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. Periodic review and
re-assessment is healthy and encouraged.
<vspace blankLines="1"/>

Similarly, requests for cross-area review are relatively infrequent or
sent only to a particular subset of people in an area (such as a
directorate). For the regular participant it is difficult to find out
where there are important documents that would deserve more review.
</t>

<t hangText="Attention Focus"><vspace blankLines="1"/>

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.</t>

<t hangText="Scheduling"><vspace blankLines="1"/>

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 her 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 ones in their own area, but this is not
readily apparent to the people who perform scheduling.</t>

<t hangText="Process vs. Substance"><vspace blankLines="1"/>

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 relevant mail list.
<vspace blankLines="1"/>

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.</t>

<t hangText="Incentives"><vspace blankLines="1"/>

Ultimately, motivation determines the effort that IETF participants
will make toward topics that are not part of their primary goals or
day job requirements. The participants are volunteers that do not have
time to keep up with unlimited number of mailing lists and
documents. Some of them may end up following some topics based on
attending a meeting that they found interesting. Some of them may end
up doing something because someone else requested them to look at a
particular issue. And some may dig into a topic based on hearing about
in the hallways of an IETF meeting. But in general, there is limited
opportunity and bandwidth for looking into new topics.
</t>

</list>
</t>

</section>

<section anchor="recommendations" title="Ten Recommendations">

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

<list style="numbers">

<t>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.</t>

<t>People matter, organizations do not. The essence of most cross-area
work is getting the right expertise to the room and to the mail list. This
does not happen through mere organizational forms, people have to be
interested in the problem.

<list style="empty"><t>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.</t></list></t>

<t>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.</t>

<t>Cross-area review. Similarly, expertise is not brought in by an
area designation, it is brought through the right people actually
commenting on the specifications. Encouraging cross-area review is therefore
helpful, for instance through directorates assigned to review
important documents from other areas.</t>

<t>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 support the plan.</t>

<t>As with every topic, the management (IESG and working group chairs)
need to clearly communicate the work plan to all interested participants.
Who is
responsible for what? What is in scope for a working group? Can
additional items outside this scope be taken elsewhere, and if so,
where? When a working group closes, where are remaining items and
maintenance topics expected to be handled?
<vspace blankLines="1"/>

The key tool for defining the scope is the working group charter.
When work is identified as cross-area, it is necessary to to make this
clear in the charter. The charter should also provide guidance on the
work scope and who is responsible for what. This helps then later when
it is necessary to assign area advisors, get early cross-area review,
and so on.</t>

<t>The best examples of successful cross-area work involve combining
two pieces of expertise, with both parties having an incentive to
complete the work.</t>

<t>One good model that has been used in the Internet Area employs a
protocol detail working group and a consumer working group.
<vspace blankLines="1"/>

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.
<vspace blankLines="1"/>

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.
<vspace blankLines="1"/>

Division of responsibilities in this manner is encouraged in
other situations as well.
</t>

<t>Scheduling models for the IETF should take cross-area work into
account in a better way. Possible tools to improve this include the
ability to specify entire areas as conflicts in the meeting request
tool. One commonly occurring special case of such conflicts is ADs
from multiple areas that are interested in a working group. However,
it is perhaps more important to consider the wider audiences, such as
directorates.</t>

<t>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.</t>

</list>

</t>

</section>

</middle>

<back>

<references title="Informative References">
      <?rfc include="reference.RFC.2026.xml"?>
</references>

<section title="Acknowledgments">

<t>The author would like to thank the IESG for inspiring discussions
around the IETF processes. In particular, Dan Romascanu, Adrian
Farrell, Russ Housley, Lars Eggert, David Harrington, Ron Bonica,
Ralph Droms, Brian Haberman, Robert Sparks, and Stewart Bryant have
shared their thoughts on this matter over the years. Nothing in this
draft should be interpreted as an IESG opinion, however, as the draft
is the author's opinion only.</t>

<t>The author would also like to thank Joel Halpern, Keith Moore, Paul
Hoffman, Samita Chakrabarti, Melinda Shore, Barry Leiba, JW Atwood,
Tom Petch, Wesley George, Thomas Narten, Tony Hansen, SM, and Dan Wing for
feedback.</t>

</section>

</back>
</rfc>