Internet DRAFT - draft-arkko-iesg-crossarea


Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Informational                          February 7, 2013
Expires: August 11, 2013

              Experiences from Cross-Area Work at the IETF


   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

   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 August 11, 2013.

Copyright Notice

   Copyright (c) 2013 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
   ( 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.

Arkko                    Expires August 11, 2013                [Page 1]
Internet-Draft               Cross-Area Work               February 2013

Table of Contents

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

Arkko                    Expires August 11, 2013                [Page 2]
Internet-Draft               Cross-Area Work               February 2013

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

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

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

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

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

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

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

Arkko                    Expires August 11, 2013                [Page 3]
Internet-Draft               Cross-Area Work               February 2013

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

   o  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

   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.

   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.

   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

Arkko                    Expires August 11, 2013                [Page 4]
Internet-Draft               Cross-Area Work               February 2013

   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.

   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.

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

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

   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 dismissed in others.  This may be fine, if the

Arkko                    Expires August 11, 2013                [Page 5]
Internet-Draft               Cross-Area Work               February 2013

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

      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.

      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

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

      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

Arkko                    Expires August 11, 2013                [Page 6]
Internet-Draft               Cross-Area Work               February 2013

   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.
      Periodic review and re-assessment is healthy and encouraged.

      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.

   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.


      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.

   Process vs. Substance

      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.

      Cross-area and cross-WG work, duplicated presentations in multiple

Arkko                    Expires August 11, 2013                [Page 7]
Internet-Draft               Cross-Area Work               February 2013

      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.


      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.

5.  Ten 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
        mail list.  This does not happen through mere organizational
        forms, people have to be interested in 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

Arkko                    Expires August 11, 2013                [Page 8]
Internet-Draft               Cross-Area Work               February 2013

        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

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

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

   6.   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?

        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.

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

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

Arkko                    Expires August 11, 2013                [Page 9]
Internet-Draft               Cross-Area Work               February 2013

        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.

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

   10.  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.  Informative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

Appendix A.  Acknowledgments

   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.

   The author would also like to thank Joel Halpern, Keith Moore, Paul

Arkko                    Expires August 11, 2013               [Page 10]
Internet-Draft               Cross-Area Work               February 2013

   Hoffman, Samita Chakrabarti, Melinda Shore, Barry Leiba, JW Atwood,
   Tom Petch, Wesley George, Thomas Narten, Tony Hansen, SM, and Dan
   Wing for feedback.

Author's Address

   Jari Arkko
   Jorvas  02420


Arkko                    Expires August 11, 2013               [Page 11]