Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4089

IAB and IESG Recommendation for IETF Administrative Restructuring

Pages: 55
Informational
Part 1 of 3 – Pages 1 to 6
None   None   Next

Top   ToC   RFC4089 - 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).

Abstract

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   RFC4089 - 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 appendix. 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   RFC4089 - 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
   list.

   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 restructuring. 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 recommendation:
Top   ToC   RFC4089 - 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   RFC4089 - 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   RFC4089 - 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 Zinin. 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.