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
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 . Much background work and several detailed proposals for community consideration are provided in a report prepared by a consultant titled "IETF Administrative Support Functions" . 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.
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 , Scenario O ) 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  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  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:
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 , 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.
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.
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.