Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 4089

Pages: 55
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IAB

IAB and IESG Recommendation for IETF Administrative Restructuring

Part 1 of 3, p. 1 to 6
None       Next RFC Part


Top       ToC       Page 1 
Network Working Group                                 S. Hollenbeck, Ed.
Request for Comments: 4089                                  IAB and IESG
Category: Informational                                         May 2005

   IAB and IESG Recommendation for IETF Administrative Restructuring

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document describes a joint recommendation of the Internet
   Architecture Board and the Internet Engineering Steering Group for
   administrative restructuring of the Internet Engineering Task Force.
   The IETF Chair declared that the IETF had consensus to follow this
   recommendation on November 11, 2004.  Further work has been done to
   revise and refine the structures proposed.  The recommendation is
   being published for the record.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  The Process That Produced This Recommendation  . . . . . . . .  2
   3.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Arguments That Had Particular Weight in the Discussions  . . .  4
       4.1.  Focusing on Scenarios C and O  . . . . . . . . . . . . .  4
       4.2.  Why We Chose Scenario O  . . . . . . . . . . . . . . . .  5
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
   Appendix: Scenario C . . . . . . . . . . . . . . . . . . . . . . .  7
   Appendix: Scenario O . . . . . . . . . . . . . . . . . . . . . . . 37
   Informative References . . . . . . . . . . . . . . . . . . . . . . 54

Top      ToC       Page 2 
1.  Introduction

   The Internet Engineering Task Force (IETF) has a need for
   administrative support functions.  The debate and dialogue of 2003
   and 2004 has led to the belief that the way these functions are
   provided needs to be changed.

   This document gives the recommendation of the Internet Engineering
   Steering Group (IESG) and Internet Architecture Board (IAB) on what
   the next step in that change process should be, and some of the
   background and reasoning behind this recommendation.

2.  The Process That Produced This Recommendation

   During several months in 2004, the Internet Architecture Board (IAB)
   and the Internet Engineering Steering Group (IESG) worked together to
   consider several different options for restructuring the Internet
   Engineering Task Force (IETF) administrative functions.  The goal of
   this effort was to produce a recommendation for consideration by and
   approval of the IETF community.  The rationale for this effort is
   described in RFC 3716 [1].  Much background work and several detailed
   proposals for community consideration are provided in a report
   prepared by a consultant titled "IETF Administrative Support
   Functions" [2].

   The consultant's report included several possible scenarios for
   administrative restructuring (named scenario A, B, C, and D).  As
   discussion took place within the IETF community, it became clear that
   some of the scenarios had features that appeared more promising than
   others, but that we did not have enough of a concrete proposal to
   crystallize opinions into a consensus for action.  Members of the
   IESG and IAB took on the task of working out more complete
   descriptions of two of the scenarios.  They were:

   o  Scenario C (section 4.4 of the report) describes when
      "administrative support functions for the IETF are legally housed
      in a focused, incorporated institution" with close ties to the
      Internet Society (ISOC).  Scenario C is included here as the first

   o  A new scenario, called Scenario O, that includes features derived
      from scenarios A and B (sections 4.2 and 4.3 of the report),
      focusing on the formalization of the ISOC/IETF relationship while
      housing administrative support functions for the IETF within ISOC.
      Scenario O is included here as the second appendix.

Top      ToC       Page 3 
   These descriptions were not intended to close off discussion of other
   scenarios, but to focus discussion on what appeared to be two
   independent loci of support.

   Both scenarios were presented to the IETF community as mail notes
   (Scenario C [3], Scenario O [4]) sent to the IETF discussion list.
   IETF participants' opinions, while quite divided on the subject,
   seemed to indicate a preference for Scenario O as a "lower risk
   operation", but some participants indicated that they felt unable to
   give an informed opinion, disagreed with the process, or declared the
   subject out of their field of competence.  This discussion garnered
   perhaps 40 participants who contributed on the list.

   The IETF Chair then requested an informal poll of IETF opinion.
   People interested in participating in the poll were directed to a web
   site where their opinions could be noted, including whether they
   wanted to state an opinion or not.  The raw poll results [5] were
   also shared with the community via a mail note to the IETF discussion

   The poll sparked additional discussion on the list, and not all
   participants agreed with the methodology of the poll.  Taken with the
   discussion, though, the IESG and IAB members believe that there is a
   stronger indication of community support for change based on Scenario
   O than on other scenarios.  The IESG and IAB members believe that
   Scenario O can be a workable basis for further progress, even if it
   is not the first preference for all members.  Taken together, this
   has led to the IESG/IAB recommendation given below.

3.  Recommendation

   The collective recommendation of the IAB and IESG was presented to
   the IETF community of Friday 8 October 2004 via a mail note [6] sent
   to the IETF mailing list:

      "IETF folks,

      The IESG and IAB have been considering the input from the IETF
      community on the next steps going forward in IETF administrative

      It appears clear to us that the community mostly sees scenario O
      as the lower-risk scenario, and the one that gives us the greatest
      probability of successfully doing what we have to do.

      Based on this, the IESG and the IAB make the following

Top      ToC       Page 4 
             We recommend that the IETF pursue scenario O, with the
             understanding that further work is needed to define the
             roles and responsibilities of the IETF, the IAOC and the
             ISOC BoT under this scenario.

      The "BCP section" of the scenario O note will be pulled out and
      published as an internet-draft.  We'd like to put this description
      to the IETF community for a formal Last Call before the November
      IETF meeting, if possible.

      Also, as noted in the recommendation above, there are a number of
      points where we need to work out in more detail how the system is
      going to work - who takes decisions, who accepts those decisions,
      and what conflict resolution mechanisms may be necessary, and so
      on.  The IAB and IESG are drafting a document that will describe
      the finer level of detail as to the respective roles and
      responsibilities of each of the players.  We will publish this as
      an internet-draft shortly.

      We will continue to work intensely on this!"

4.  Arguments That Had Particular Weight in the Discussions

4.1.  Focusing on Scenarios C and O

   The IETF list was presented with four scenarios in the consultant
   report [2], which should be read for the full context.  In slogan
   form, they might be rendered as

   o  A: Leave it to ISOC.

   o  B: Increase IETF control of ISOC, and use ISOC to do it.

   o  C: Isolate the functions, let ISOC gather money, share control.

   o  D: Cut the IETF off from ISOC and do it ourselves.

   On the list, there seemed to be very few who were comfortable with
   the idea that "we" (for some version of "we") could "do it ourselves"
   as envisioned in Scenario D.  There was also considerable worry about
   the risk associated with Scenario C, especially with regard to
   financial stability, and that the perceived danger of problems would
   cause sponsors to withhold funding, thus precipitating problems even
   if there was no other reason for them.  Scenario C spoke strongly to
   those who worried about a possible conflict of interest between ISOC
   and the IETF community at some future date - "we don't know what ISOC
   will turn into" was the capsule summary.

Top      ToC       Page 5 
   Scenario A worried people because it did not seem to acknowledge the
   IETF community's ability to determine if its needs were being met and
   what could be done if they were not.  The phrase "replace existing
   problematic structures by ISOC" was perhaps a capsule summary.
   However, Scenario B's list of possible mechanisms for involving IETF
   community directly in ISOC's operations was not viewed as acceptable
   or in balance with the full scope of ISOC's activities.  Members of
   the IAB & IESG developed Scenario O, a solution scenario that put the
   administrative activity within ISOC, but aimed to provide a means for
   the IETF to provide oversight and control of that specific activity
   within ISOC.  Its name is derived from the classification of blood
   types -- "neither A nor B".

   Thus, the decision to focus on C and O as "alternatives to be worked
   out in detail" was made.

4.2.  Why We Chose Scenario O

   Capsule summary: It might be possible to make either scenario work.
   But Scenario O could be made to work faster, and less painfully.

   The ISOC Board of Trustees was significantly worried that scenario C
   would make fundraising more difficult, which would necessarily affect
   its ability to support the IETF.

   The question of tax status for the new corporation was debated at
   some length on the list; legal counsel indicated that a corporation
   that did the IETF work (Scenario D) would probably be easy to get
   classified as 501(c)(3) (a type of non-profit corporation defined by
   U.S. Internal Revenue Service (IRS) regulations).  However, a
   corporation that did only administrative support functions, as
   scenario C envisioned, would have more problems.  In all cases, the
   process of determining this would take months, and could be dragged
   out longer if we were unlucky.

   The community feedback, in addition to contributing many well-formed
   and well-argued points to the discussion, gave a powerful indication
   on where it was possible to get IETF consensus:

   o  It seemed possible to garner IETF consensus around Scenario O; the
      people arguing for Scenario C indicated that they "could live
      with" the alternative.

   o  It seemed much more difficult to garner IETF consensus around
      Scenario C; many people arguing against it indicated that they
      were firmly convinced that it was the wrong choice for the IETF.

Top      ToC       Page 6 
   The IETF is based on the idea that the consensus process, when it
   works, comes up with reasonable decisions.  We concluded that the
   apparent drift of community consensus was a reasonable basis for the
   IESG/IAB recommendations.

5.  IANA Considerations

   This document does not require any IANA actions.  However, the IETF
   administrative restructuring process is likely to affect how the
   relationship between the IETF and the IANA is managed.

6.  Security Considerations

   This document does not introduce any security considerations for the
   operation of the Internet.  However, administrative restructuring
   introduces several areas of risk to the future of the IETF.  The
   risks and their mitigation strategies are described in the scenarios
   as appended to this document.

7.  Acknowledgements

   This document is a collective work of the members of the IAB and the
   IESG.  Members of the IAB at the time of this writing include Bernard
   Aboba, Harald Alvestrand, Rob Austein, Leslie Daigle, Patrik
   Faltstrom, Sally Floyd, Mark Handley, Bob Hinden, Geoff Huston, Jun-
   ichiro Itojun Hagano, Eric Rescorla, Pete Resnick, and Jonathan
   Rosenberg.  Members of the IESG at the time of this writing include
   Harald Alvestrand, Steve Bellovin, Bill Fenner, Ted Hardie, Scott
   Hollenbeck, Russ Housley, David Kessens, Allison Mankin, Thomas
   Narten, Jon Peterson, Margaret Wasserman, Bert Wijnen, and Alex

   The administrative restructuring effort cannot succeed without
   community support and participation.  Thus, the IAB and IESG wish to
   acknowledge the collective contributions of members of the IETF
   community who have participated in the discussion of this topic.

Next RFC Part