diff options
Diffstat (limited to 'doc/rfc/rfc4089.txt')
| -rw-r--r-- | doc/rfc/rfc4089.txt | 3083 |
1 files changed, 3083 insertions, 0 deletions
diff --git a/doc/rfc/rfc4089.txt b/doc/rfc/rfc4089.txt new file mode 100644 index 0000000..e4cc23d --- /dev/null +++ b/doc/rfc/rfc4089.txt @@ -0,0 +1,3083 @@ + + + + + + +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 + + + + + + + + + + +Hollenbeck Informational [Page 1] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +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. + + + + + + +Hollenbeck Informational [Page 2] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + + 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: + + + + +Hollenbeck Informational [Page 3] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + + 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. + + + + +Hollenbeck Informational [Page 4] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + + 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. + + + + + +Hollenbeck Informational [Page 5] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + + 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. + + + + + + + + + + + + + + + +Hollenbeck Informational [Page 6] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +Appendix: Scenario C + + This Appendix reproduces the contents of an Internet-Draft defining + Scenario C, as it was posted on 20 September 2004. A table of + contents has been removed from this copy and the text has been + reformatted to fit within IETF publication guidelines. Each line is + prefixed with "C>>". + +C>> B. Wijnen +C>> LucentTechnologies +C>> H. Alvestrand +C>> Cisco Systems +C>> P. Resnick +C>> QUALCOMM Incorporated +C>> September 20, 2004 +C>> +C>> AdminRest Scenario C: An IETF Administrative Support Foundation as +C>> an Independent Nonprofit Corporation +C>> +C>> Abstract +C>> +C>> This document defines a proposal for an IETF Administrative +C>> Support Foundation (IASF) as an independent not-for-profit +C>> corporation as a means for providing focused support for IETF +C>> community activities. It proposes the creation of an IASF Board +C>> of Trustees (BoT) that is mainly selected by and accountable to +C>> the IETF community and would provide oversight for the IETF +C>> Administrative Support Foundation. The IASF will also establish +C>> and maintain a strong relationship with the Internet Society +C>> (ISOC) and the current relationships between IETF and ISOC will +C>> basically be left unchanged. +C>> +C>> In order to allow the community to properly evaluate this +C>> scenario, some draft Articles of Incorporation and draft Bylaws +C>> for the IASF are included. Some draft BCP wording for the IASF, +C>> IETF and ISOC relationships is also included. +C>> +C>> 1. Overview of Scenario C +C>> +C>> This document follows from two previous documents. [RFC3716] +C>> defined the overall parameters and criteria for an administrative +C>> restructuring. [I-D.malamud-consultant-report] provided an +C>> analysis of the implications of several of the suggested +C>> strategies. This document picks one strategy and develops it +C>> further. +C>> + + + + + +Hollenbeck Informational [Page 7] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> In order to provide the most focused and effective administrative +C>> support to the IETF community, this updated scenario C proposes a +C>> new and well-defined legal entity to support the IETF +C>> administrative functions. The name of that new entity is "The +C>> IETF Administrative Support Foundation" (IASF). +C>> +C>> First, it is important to understand that the IETF has been +C>> organized as an Activity of the Internet Society (ISOC) and as +C>> such represents the "Standards and Protocols" pillar of ISOC. +C>> Under this proposal, the IETF would continue to be an integral +C>> part of the Standards and Protocols pillar of ISOC. ISOC +C>> currently provides these important functions to the IETF: +C>> +C>> 1. Standards Process Functions. ISOC plays a fundamental role in +C>> the IETF Standards Process, including appointment of the +C>> Nominating Committee (Nomcom) chair, confirmation of IAB +C>> members, confirmation of documents that describe the +C>> standards processes, and acting as the last resort in the +C>> appeals process. These Standards Process Functions are +C>> defined in [RFC2026], [RFC2028], [RFC2031], and [RFC3677]. +C>> +C>> 2. IETF Fund Raising Functions. ISOC provides the fund raising +C>> function as one source for financial support the IETF. +C>> +C>> 3. Administration Functions. ISOC provides administrative and +C>> financial functions, managing the contract with the RFC +C>> Editor, providing insurance for selected IETF participants, +C>> and administering a discretionary fund for use by the IAB and +C>> the IETF Chairs. +C>> +C>> The administrative restructuring of the IETF proposed in this +C>> document keeps that basic relationship between IETF and ISOC. +C>> Specifically, the recommendation does not propose any changes to +C>> the "Standards Process Functions" or to the "IETF Fund Raising +C>> Functions". +C>> +C>> Under the "Administration Functions", ISOC both funds and +C>> administers some (as stated above) parts of the IETF +C>> Administrative Support Functions. Some of the funds (like for +C>> the RFC-Editor) go directly to the contractor who executes the +C>> administrative function. The streamlining of the administrative +C>> support for the IETF ultimately intends to put the complete +C>> Administrative Support Functions under the newly recommended +C>> IASF. This means that we recommend that ultimately, ISOC funds +C>> for the IETF will be transferred to the IASF, which will then +C>> administer all the contracts and payments according to an + + + + + +Hollenbeck Informational [Page 8] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> approved yearly budget. The details of that process will be +C>> documented in a Memorandum of Understanding (MoU) between ISOC, +C>> IETF and IASF. +C>> +C>> This updated AdminRest Scenario C aims to provide the following: +C>> +C>> o A continued close relationship between IETF and ISOC. +C>> +C>> o A well defined legal entity within which the IETF can define +C>> the administrative activity in terms of IETF community needs. +C>> +C>> o A Board of Trustees with operational oversight that is +C>> accountable to the IETF community. +C>> +C>> o Continued separation between the IETF standards activity and +C>> any fund-raising for standards work. +C>> +C>> o A close and well defined relationship between IASF and ISOC, +C>> documented in a BCP (or MoU). +C>> +C>> o Appropriate ISOC oversight of its standards activities funds +C>> via a yearly budget approval and open reporting of funds +C>> spent. +C>> +C>> In scenario C, it is intended that the IETF Administrative +C>> Support Foundation will be a tax-exempt not-for-profit +C>> corporation as defined by Articles of Incorporation and a set of +C>> Bylaws. These will describe the scope and purpose of the IASF +C>> and they also define the structure and responsibility of the +C>> Board of Trustees (BoT), a body that is mainly selected by the +C>> IETF and which is responsible for overseeing the IASF. A draft +C>> of the Articles of Incorporation and Bylaws is included in the +C>> next sections of this document. +C>> +C>> Scenario C allows us (IETF) to establish IETF control over our +C>> administrative support functions in terms of determining that +C>> they meet the community's needs, and adjusting them from time to +C>> time using IETF processes. This is to address the pressing +C>> administrative issues outlined in [RFC3716]. +C>> +C>> Scenario C also encourages us (the IETF) to regularly evaluate +C>> that we do want to continue the relationships with ISOC and the +C>> contracts with our services providers (contractors). It is based +C>> on the premise that we prefer to actively maintain relationships +C>> with other organizations and service providers instead of being +C>> bound to such relationships based on poorly defined and poorly + + + + + +Hollenbeck Informational [Page 9] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> documented historical facts. A draft BCP for the relationship +C>> between ISOC, IETF and IASF is included as a separate section in +C>> this document. +C>> +C>> Scenario C does however bring the burden of creating a new legal +C>> entity (IASF) and such an undertaking is also not without risks. +C>> It will need careful planning and execution. Migration from the +C>> current structure to this new structure is probably also somewhat +C>> more costly and time and labour consuming. The sections below +C>> try to show how that would be achieved and outlines what further +C>> steps are needed to provide more detail if this scenario is +C>> chosen. +C>> +C>> 2. Work Plan for the IETF Administrative Support Foundation +C>> +C>> This section gives the work plan for the IETF Administrative +C>> Support Foundation (IASF) for the remainder of 2004 and the year +C>> 2005. +C>> +C>> 2.1 Workplan goals +C>> +C>> The work plan below is intended to satisfy three goals: +C>> +C>> o Satisfy the IETF's need for support functions in 2005 +C>> +C>> o Operate with a positive account balance throughout 2005 +C>> +C>> o Start building up a fund inside the IASF to serve as a buffer +C>> against budgetary emergencies in later years (such as meetings +C>> with a severe cost overrun, or force-majeure cancellations). +C>> +C>> The fund target is 6 months of operating revenue, and the target +C>> for building up the fund is 3 years. The budgeted set-aside for +C>> the fund should thus be approximately 17% of operating revenue. +C>> +C>> 2.2 Incorporation process +C>> +C>> There are 3 things that need to be in place before that +C>> corporation can be considered viable at all: +C>> +C>> o IETF consensus on the plan +C>> +C>> o ISOC agreement on a reasonable support contract +C>> +C>> o Assurance that the corporation will have tax-exempt status +C>> + + + + + +Hollenbeck Informational [Page 10] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> Once this document has been discussed in the IETF, and the IESG +C>> and IAB gauges that rough consensus seems reached, the IETF +C>> leadership will take the following actions: +C>> +C>> o Publish a Last Call on this document (to determine plan +C>> consensus). +C>> +C>> o Choose a negotiating team to negotiate the ISOC contract. +C>> +C>> o Choose an executive search team to find the IASF +C>> Administrative Director (IAD). +C>> +C>> o Consult with legal counsel to determine how best to achieve +C>> tax-exempt status; this will affect the bylaws and articles of +C>> incorporation. +C>> +C>> When the Last Call is over, the IESG will consider whether there +C>> is still consensus, and if there is, approve this document for +C>> publication. Once that happens, it will take the following +C>> steps: +C>> +C>> o As soon as negotiations conclude, publish a Last Call on the +C>> ISOC contract. +C>> +C>> o As soon as drafting of legal documents is completed, publish a +C>> Last Call on the Bylaws and Articles of Incorporation, and ask +C>> the Nomcom to start the process of selecting Nomcom-selected +C>> board representatives. +C>> +C>> +C>> These Last Calls are "speak now" Last Calls - if someone wishes +C>> to challenge the IETF consensus to go ahead with these actions, +C>> knowing what the formal documents will look like, this is their +C>> last chance. +C>> +C>> When these Last Calls are over, the IETF chair, the IAB chair and +C>> the ISOC President will jointly file the articles of +C>> incorporation, and the IESG, IAB and ISOC will fill their board +C>> seats. +C>> +C>> Note: This document does not say when a Request for Information +C>> (RFI) for IETF support services such as meeting planning is sent +C>> out. Advice is sought on the earliest point where this can be +C>> done. +C>> + + + + + + +Hollenbeck Informational [Page 11] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 2.3 Contract establishment +C>> +C>> The most important activity for late 2004/early 2005 is to +C>> finalize contracts for the support of the IETF. This includes: +C>> +C>> o Funding +C>> +C>> o Technical infrastructure +C>> +C>> o Meeting management +C>> +C>> o Clerk's office +C>> +C>> o RFC Editor +C>> +C>> o IANA +C>> +C>> There appears to be consensus in the IETF community that these +C>> functions, whether they are offered for free, remunerated or +C>> arranged for other consideration, should be under contract. +C>> +C>> The contract for funding is expected to be with ISOC, and should +C>> be finalized before IASF is established. +C>> +C>> The contract for technical infrastructure is expected to be an +C>> RFP, published in November of 2004, with responses being +C>> evaluated in December 2004, and services rendered from a mutually +C>> agreed date early in 2005. +C>> +C>> The contract for meeting management will be influenced by the +C>> need to have stable agreements for the 2005 meetings at an early +C>> date. This indicates that IASF will honor a pre-IASF agreement +C>> to have these meeting contracts signed by Foretec (if that can be +C>> achieved). +C>> +C>> It is not clear how the contract for the clerk's office is to be +C>> managed at the time of this writing. +C>> +C>> The contract for the RFC Editor is expected to be with ISI, and +C>> is expected to be a continuation of the current contract with +C>> ISOC, which runs until the end of 2005. +C>> +C>> The contract with IANA will replace or augment the current MoU +C>> between the IETF and ICANN. In its simplest form, it would +C>> simply be a reconfirmation of the duties of ICANN under the MoU. +C>> + + + + + +Hollenbeck Informational [Page 12] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 2.4 Performance evaluation +C>> +C>> The second task of the IASF is to make sure the IETF gets the +C>> support it needs. The IASF will work together with the IETF +C>> community to make an effort to identify whether or not the IETF's +C>> needs are being met, and to coordinate improvements with the +C>> contractors. This is an ongoing activity. +C>> +C>> 2.5 Budgeting for 2006 +C>> +C>> In June 2005, the IASF will start the yearly budgeting process +C>> with ISOC, as specified in the ISOC contract, leading to a work +C>> plan and budget for 2006. +C>> +C>> 2.6 Reporting +C>> +C>> The IASF will present monthly updates on its economic status. +C>> These will be delivered to ISOC as part of the ISOC contract, and +C>> also be made publicly available so that the IETF community can +C>> inspect them. +C>> +C>> 3. Details of the IETF Administrative Support Foundation +C>> +C>> This section contains details about the proposal to change how +C>> the day-to-day IETF administrative support functions are +C>> provided. This recommendation is based on the initial +C>> description of "Scenario C" in the "Administrative Support +C>> Analysis" [I-D.malamud-consultant-report] provided by Carl +C>> Malamud. It is further based on discussion in the IESG and IAB +C>> and on feedback on Carl's document as received on the IETF +C>> mailing list. Further justifications, reasoning and motivations +C>> are given in Appendix A. Risk Analysis is done in Appendix C. +C>> +C>> This document recommends to create a well defined and legal +C>> entity called "The IETF Administrative Support Foundation" +C>> +C>> (IASF). The name intends to clearly express that this new legal +C>> entity has only one single function, namely to provide the +C>> administrative support of the IETF Standardization and Protocol +C>> Development activities. This entity will ultimately manage and +C>> administer all the administrative functions that are needed to +C>> support the IETF - the Standardization and Protocol Development +C>> activity of ISOC. +C>> + + + + + + + +Hollenbeck Informational [Page 13] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 3.1 Organizational Form and Legal Domicile +C>> +C>> The consultant report [I-D.malamud-consultant-report] contains a +C>> writeup on various choices in terms of how and where to +C>> incorporate. This recommendation has made the choice to +C>> incorporate in the US in the state of Virginia. Some detail can +C>> be found in Appendix B. +C>> +C>> In this scenario, administrative support functions for the IETF +C>> are legally housed in a focused, incorporated institution +C>> (although the Administrative Director might be physically housed +C>> within the Internet Society). +C>> +C>> This scenario defines a number of concrete linkages with the +C>> Internet Society, which supplement the current close +C>> interconnection of the IETF community with ISOC. The +C>> relationship is to be documented in a MoU (initial text is in +C>> Section 4). +C>> +C>> 3.2 Draft Core Principles +C>> +C>> 3.2.1 Principles of Establishment and Governance +C>> +C>> The following principles are to be respected for the +C>> establishment and governance of the IETF Administrative Support +C>> Foundation (IASF) and are the basis for the Draft Articles of +C>> Incorporation as in Section 6.1 and the Draft Bylaws as in +C>> Section 6.2: +C>> +C>> 1. The IASF shall be governed by a Board of Trustees (BoT), who +C>> shall be responsible for the fiscal, legal, and +C>> administrative infrastructure that supports the activities of +C>> the IETF. +C>> +C>> 2. The governance of the IETF, the standards process, and all +C>> other aspects of how we make our standards are defined in the +C>> procedural Best Current Practice (BCP) RFC series, which will +C>> be explicitly referenced in the organization documents of the +C>> IASF. +C>> +C>> 3. The IASF shall be transparent and responsible to the IETF. +C>> +C>> 4. The BoT shall appoint a Secretary and a Treasurer, who need +C>> not be members of the BoT. The IETF Administrative Director +C>> (IAD) of the IASF shall provide staff support to the BoT. +C>> + + + + + +Hollenbeck Informational [Page 14] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 5. The BoT shall be composed to strike a balance between +C>> "outside" and "inside" directors. The IESG and IAB will each +C>> select a representative to serve as a voting member of the +C>> BoT. Mechanisms such as the Nominating Committee (Nomcom) and +C>> the appointment of certain seats by the ISOC fulfill the +C>> outside director obligations. +C>> +C>> 6. IAB, IESG and ISOC will have liaisons to the BoT in order to +C>> have a good basis for interaction. +C>> +C>> The BoT will have strong governance over a limited scope of +C>> activities (e.g., the fiscal, legal, and administrative +C>> infrastructure that are the charter of the IASF) but will have no +C>> authority over the IETF standards process. In this board +C>> composition, the ISOC and Nomcom appointments ensure that outside +C>> directors with no perceived conflicts of interest are on the +C>> board. +C>> +C>> All nominating bodies should make strong fiscal, legal, and +C>> administrative acumen essential selection criteria for this +C>> position. +C>> +C>> IAB and IESG representatives will serve for one year. For other +C>> appointments, a term proposed for the nominated positions is +C>> three years with staggered appointments. However, the nominating +C>> body might have the power to change their appointee during their +C>> term. +C>> +C>> All members of the BoT selected by the IETF are subject to the +C>> same recall procedures in effect for the IETF leadership such as +C>> members of the IAB and IESG. +C>> +C>> 3.2.2 Principles of Operation of the IETF Administrative Support +C>> Foundation +C>> +C>> The following are general principles for the operation of the +C>> IASF: +C>> +C>> 1. The IASF shall employ an IETF Administrative Director (IAD) +C>> of the IASF, who shall be hired by the BoT with the advice +C>> and consent of the IESG and IAB. +C>> +C>> 2. All support services shall be contracted in an open and +C>> transparent manner. +C>> + + + + + + +Hollenbeck Informational [Page 15] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 3. The IAD shall submit a proposed annual budget to the BoT at +C>> least 90 days before the beginning of the fiscal year. Such +C>> budget shall be developed with the advice and consent of the +C>> IAB and IESG. +C>> +C>> 4. The IAD shall serve on the BoT as a non-voting, ex-officio +C>> member. +C>> +C>> 5. The BoT shall select a professional audit firm and shall +C>> commission an audit immediately upon the close of each fiscal +C>> year. +C>> +C>> 6. The IASF will conduct financial reporting in a fully +C>> transparent fashion. Audits shall be conducted promptly and +C>> published. Tax returns shall be published. Detailed +C>> financial statements will be published on a regular basis, +C>> including timely reports on the financial results of IETF +C>> meetings. +C>> +C>> 4. Draft MoU between ISOC, IETF and IETF Administrative Support +C>> Foundation +C>> +C>> 4.1 Form and Scope of the Agreement +C>> +C>> This section presents some principles to be incorporated in a +C>> draft MoU/Contract between the Internet Society (ISOC) and the +C>> IETF Administrative Support Foundation (IASF), detailing the work +C>> each is expected to perform, the responsibilities each has, and +C>> the means by which these functions are accomplished. This +C>> MoU/Contract shall be published as an RFC. +C>> +C>> The MoU/Contract will specify the responsibilities of the +C>> Internet Society, including: +C>> +C>> o Reaffirmation of the Standards Process Function that ISOC +C>> performs for the IETF. +C>> +C>> o Continuation of the Fund Raising Function that ISOC conducts, +C>> in which a single, unified campaign is used to solicit +C>> corporate, individual, and other organizational donations for +C>> funding of the 3 Pillars. +C>> +C>> o Disbursement of funds to the IASF according to the agreed-upon +C>> budgets and processes as specified in this agreement. +C>> +C>> o Verification that IASF spends these funds to support the work +C>> of the IETF, within the scope described in the IASF bylaws. +C>> + + + +Hollenbeck Informational [Page 16] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> Responsibilities of IASF: +C>> +C>> o Determine, in cooperation with the IETF, the support functions +C>> that are needed for the IETF, and can be achieved within +C>> available funds. +C>> +C>> o Enter into contracts for these support functions. +C>> +C>> o Supervise these contracts and ensure that they are being +C>> performed in the best interest of the IETF, within a +C>> reasonable budget and with agreed-upon performance. +C>> +C>> 4.2 Cooperation mechanism +C>> +C>> IASF and ISOC agree that they will perform a budgeting procedure +C>> each year, comprising the following steps: +C>> +C>> o IASF puts together a budget proposal to ISOC, and presents it +C>> in June. This will specify the functions that need to be +C>> performed, the cost of each, the expected revenue from IETF +C>> meeting participation, and how much is being requested for +C>> ISOC to contribute. +C>> +C>> o By the end of August, ISOC will give a budget number to IASF +C>> that says how much ISOC is willing to contribute to support +C>> the functions described in the IASF budget. +C>> +C>> o Before November 1, ISOC and IASF will agree on a budget, an +C>> ISOC contribution, and a disbursement schedule. +C>> +C>> o If either party sees that there is reason to change the +C>> budget, they can start a negotiation to do so at any time. On +C>> mutual agreement to a change, payments are modified +C>> accordingly. +C>> +C>> o ISOC may withhold funds if IASF fails to account for its +C>> expenditures, if it determines that IASF has departed +C>> significantly from its budgeted expenditures without agreement +C>> with ISOC to do so, or if ISOC determines that IASF is +C>> spending funds in violation of its bylaws. +C>> + + + + + + + + + + +Hollenbeck Informational [Page 17] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 4.3 Promises Not to Do Things +C>> +C>> This section lays out things that would constitute interference +C>> in each others' business, or things that are Just Plain Wrong. +C>> +C>> In legal terms, these are called "covenants." +C>> +C>> ISOC will not place requirements on how IASF does business, +C>> except on reporting. It will, for instance, not attempt to +C>> influence IASF choice of contractors or choice of meeting +C>> sponsors. This restriction is meant to enforce the separation +C>> between fund raising and the actual operation of the standards +C>> process. +C>> +C>> IASF will not ask companies for money. IASF may ask for sponsors +C>> for IETF events, per tradition, and may accept zero-cost provider +C>> contracts or in-kind donations, but ISOC is the organization +C>> charged with fundraising. +C>> +C>> Neither ISOC nor IASF will attempt to influence technical +C>> decisions of the IETF standards process. +C>> +C>> 4.4 Initial contribution +C>> +C>> The Internet Society has already allocated $700,000 in transition +C>> funds. As part of the formation process, this section sets out a +C>> way that a 2005 allocation of funds and an initial contribution +C>> for startup can be decided upon. NOTE: This section is a GUESS! +C>> Its purpose is to give some sense of where we're at. +C>> +C>> If this plan is pursued, one of the first activities is to put +C>> together a detailed 2005 budget, including an analysis of cash +C>> flow and balance sheets to make sure that the organization is +C>> properly funded and will be solvent throughout the year. This +C>> planning process should project out 3 years and show how the +C>> organization will be able to accumulate the appropriate cash +C>> reserve to make sure operations can continue in a stable manner. +C>> +C>> An initial estimate is for an on-going annual contribution of USD +C>> 900.000 to IASF in 2005. In addition, ISOC will contribute an +C>> additional USD 600.000 as an initial fund to start up IASF, +C>> payable after the Board of Trustees is seated and this contract +C>> is signed and approved by the IETF. +C>> +C>> ISOC commits to this ongoing level of contribution (USD 75.000 +C>> per month) for the lifetime of this contract, unless modified by +C>> mutual agreement. +C>> + + + +Hollenbeck Informational [Page 18] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 4.5 Termination, law and so on +C>> +C>> This agreement may be terminated by either party for any reason +C>> on 12 months' notice. +C>> +C>> The parties may reach mutual agreement on a shorter termination +C>> period. +C>> +C>> All conflicts under this agreement are to be adjudicated under +C>> the laws of the United States and the State of Virginia, however +C>> the parties may also agree to arbitration, mediation or any other +C>> conflict resolution mechanisms. +C>> +C>> 5. Notes and Explanations +C>> +C>> This is where we put down why things are the way they are. +C>> +C>> 5.1 Type of legal instrument +C>> +C>> This document is styled as a contract - an agreement between two +C>> parties, enforceable under law. An alternate formulation would +C>> be a Memorandum of Understanding - but we want it to be clear to +C>> everyone that the parties stand behind their responsibilities +C>> under this document. At the moment, the authors see no +C>> compelling arguments for not making it a contract. In either +C>> case, the document is published as an RFC. +C>> +C>> 5.2 Power Balance +C>> +C>> As written, it is designed to make it easy to do the right thing +C>> as long as the parties agree what that is, to make it clear that +C>> ISOC will continue to pay money as long as IASF does the Right +C>> Thing (and reports what it's doing), and that ISOC can stop the +C>> show quickly if it's clear that IASF is not doing the Right +C>> Thing. +C>> +C>> 5.3 Budget figures +C>> +C>> The main purpose of the numbers is to make it clear that there +C>> WILL be numbers in this contract, and that it WILL represent a +C>> solid commitment by ISOC. The numbers are "subject to change +C>> without notice" while this contract is negotiated. +C>> + + + + + + + + +Hollenbeck Informational [Page 19] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 6. Draft Incorporating Documents for the IETF Administrative +C>> Support Foundation +C>> +C>> 6.1 Draft Articles of Incorporation +C>> +C>> This section contains standard, pro-forma Articles of +C>> Incorporation. Note well that tax lawyers often make significant +C>> alterations to standard Articles as they consider a 501(c)(3) +C>> application. They are included here merely as a sample for +C>> illustrative purposes only. +C>> +C>> 'Commonwealth of Virginia -- State Corporation Commission'| +C>> 'Articles of Incorporation -- Virginia Nonstock Corporation'| +C>> Form SCC819, 07/ 03 [1] ------ +C>> +C>> The undersigned, pursuant to Chapter 10 of Title 13.1 of the Code +C>> of Virginia, [Virginia] state(s) as follows: +C>> +C>> 1. The name of the corporation is The IETF Administrative +C>> Support Foundation. +C>> +C>> 2. The corporation shall have no members. +C>> +C>> 3. The purpose of the corporation is to manage and administer +C>> all the administrative functions for the IETF - the +C>> Standardization and Protocol Development activity of the +C>> Internet Society. +C>> +C>> 4. The Trustees of the corporation shall be elected or appointed +C>> as specified in Article IV (Section 6.2.5) of the Bylaws. +C>> +C>> 5. Name and agent: +C>> +C>> A. The name of the corporation's initial registered agent +C>> is: XXX +C>> +C>> B. The initial registered agent is a domestic or foreign +C>> stock or nonstock corporation, limited liability company, +C>> or registered limited liability partnership authorized to +C>> transact business in Virginia. +C>> +C>> 6. The initial Trustees are: XXX +C>> +C>> 7. The incorporators are: XXX +C>> + + + + + + +Hollenbeck Informational [Page 20] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 6.2 Draft Bylaws of the IETF Administrative Support Foundation +C>> +C>> As with the Draft Articles, the Draft Bylaws included here are a +C>> pro-forma, standard version. Substantial alteration may be +C>> required as legal counsel reviews the specific nature of an +C>> incorporation. +C>> +C>> 6.2.1 Article I: Organization +C>> +C>> The name of the Corporation shall be The IETF Administrative +C>> Support Foundation (which is hereinafter also referred to as the +C>> "IASF"). +C>> +C>> 6.2.2 Article II: Purpose +C>> +C>> *Section 1: Purpose.* The IASF shall be operated exclusively for +C>> nonprofit educational, charitable, and scientific purposes, +C>> including, without limitation, the purposes stated in the IASF's +C>> Articles of Incorporation. +C>> +C>> *Section 2: Restrictions.* No part of the net earnings of the +C>> IASF shall inure to the benefit of, or be distributable to, +C>> private persons, except that the IASF shall be authorized and +C>> empowered to pay reasonable compensation for services rendered, +C>> and to make payments and distributions in furtherance of the +C>> purposes set forth in Article II, Section 1 hereof. Any other +C>> provision of these Bylaws to the contrary notwithstanding, the +C>> IASF shall not carry on any activities not permitted to be +C>> carried on by a corporation exempt from Federal Income Tax under +C>> Section 501(a) and Section 501(c)(3) of the Code. These Bylaws +C>> shall not be altered or amended in derogation of the provisions +C>> of this Section. +C>> +C>> 6.2.3 Article III: Members +C>> +C>> The IASF shall have no members and no stockholders. +C>> +C>> 6.2.4 Article IV: Offices +C>> +C>> The office of the IASF shall be as determined from time to time +C>> by the Board of Trustees (BoT) within or outside of the State of +C>> Virginia. +C>> +C>> 6.2.5 Article V: Board of Trustees +C>> +C>> *Section 1: Authority and Responsibilities.* The power, +C>> authority, property, and affairs of the IASF shall at all times +C>> be exclusively exercised, controlled, and conducted by or under + + + +Hollenbeck Informational [Page 21] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> the authority of the Board of Trustees (BoT) subject to any +C>> limitations set forth in the Articles of Incorporation and in +C>> accordance with the Virginia Nonstock Corporation Act as it now +C>> exists or hereafter may be amended. +C>> +C>> *Section 2: Board of Trustees Composition.* The Board of Trustees +C>> shall consist of seven (7) Trustees. +C>> +C>> One (1) Trustee will be selected by the IAB. +C>> +C>> One (1) Trustee will be selected by the IESG. +C>> +C>> Two (2) Trustees will be selected by the Internet Society. +C>> +C>> Three (3) Trustees will be selected by the IETF community. +C>> +C>> The IAB chair and IETF chair will functions as liaisons from the +C>> IAB and IESG respectively to the Board of Trustees. The chair +C>> and president of the Internet Society will function as liaisons +C>> from the ISOC to the Board of Trustees. +C>> +C>> *Section 3: Terms.* The term of office of IESG and IAB Selected +C>> Trustees shall be one (1) year or until their successors have +C>> been selected and assume office. The term of office of otherwise +C>> Selected Trustees shall be three (3) years or until their +C>> successors have been selected and assume office. Selected +C>> Trustees may be selected to serve multiple terms. +C>> +C>> *Section 4: Selection of the Board of Trustee* +C>> +C>> 1. *Selection of IESG and IAB Selected Trustees.* The IESG and +C>> IAB shall each select one representative Trustee, who is not +C>> at the same time an IESG or IAB member. +C>> +C>> 2. *Selection of otherwise Selected Trustees.* Three (3) IETF +C>> Selected Trustees shall be selected by the IETF nominations +C>> process (as defined in [RFC3777] or its successor) and +C>> confirmed by the IESG. Two ISOC Selected Trustees shall be +C>> selected by the Internet Society using means of their own +C>> choosing. +C>> +C>> 3. *Resignation.* A Selected Trustee may resign by delivering +C>> his resignation in writing to the IASF at its principal +C>> office or to the Secretary of the IASF. Such resignation +C>> shall be effective upon its receipt or upon such date (if +C>> any) as is stated in such resignation, unless otherwise +C>> determined by the Board. +C>> + + + +Hollenbeck Informational [Page 22] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 4. *Removal.* A Selected Trustee selected by the IETF +C>> nominations process may be removed from office at any time +C>> using the procedures specified in [RFC3777] or its successor. +C>> A Selected Trustee selected by the Internet Society may be +C>> removed by the Internet Society using means of their own +C>> choosing. +C>> +C>> 5. *Vacancies.* Any vacancy in the Board of Trustees shall be +C>> filled using the procedures set forth above on the +C>> composition of the Board of Trustees. The Trustees shall +C>> have and may exercise all of their powers notwithstanding the +C>> existence of one or more vacancies in their number. +C>> +C>> *Section 5: Quorum.* A majority (i.e. fifty (50) percent plus +C>> one (1)) of the Trustees shall constitute a quorum for the +C>> transaction of business. Unless otherwise stated in these +C>> +C>> Bylaws, decisions of the Board of Trustees shall be made by the +C>> concurrence of a majority of members of the Board of Trustees +C>> present and voting. If at any meeting there is no quorum +C>> present, the Board must not transact business. +C>> +C>> *Section 6: Compensation and Reimbursement.* No member of the +C>> Board of Trustees may receive compensation for his or her +C>> services as a Trustee. A Trustee shall, at their request, be +C>> reimbursed for actual, necessary and reasonable travel and +C>> subsistence expenses incurred by them in performance of their +C>> duties. +C>> +C>> *Section 7: Meetings.* The Board of Trustees shall meet at least +C>> twice annually. +C>> +C>> 1. *Written notice, waiver, action.* Wherever the text below +C>> speaks of "written" it is also permitted to use e-mail. +C>> +C>> 2. *Annual Meeting.* The Board of Trustees shall hold a public +C>> Annual Meeting at a time and place associated with the first +C>> IETF meeting each year. This Annual meeting shall be open to +C>> all IETF attendees except that the parts of the meeting +C>> dealing with personnel issues may be held in executive +C>> session. +C>> +C>> 3. *Meeting Types, Methods, and Notice.* Meetings of the Board +C>> may be held from time to time at such intervals and at such +C>> places as may be fixed by the Board. Meetings of the Board +C>> may be held only in person or via teleconference. Notice of +C>> all regular meetings of the Board shall be delivered to each +C>> Trustee by e-mail or by postal mail and announced on the + + + +Hollenbeck Informational [Page 23] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> IETF-Announce list at least ten (10) calendar days before the +C>> meeting. Special meetings of the Board may be called for any +C>> purpose at any time by the Chairman of the Board or by any +C>> three (3) Trustees. Notice of any special meeting shall state +C>> the purpose of the meeting. A Trustee may waive notice of a +C>> meeting of the Board of Trustees by submitting a signed, +C>> written waiver of notice, either before or after the meeting. +C>> A Trustee's attendance at or participation in a meeting +C>> waives any required notice of the meeting unless at the start +C>> of such meeting or promptly upon arrival the Trustee objects +C>> to holding the meeting or transacting business at the +C>> meeting, and does not thereafter vote for or assent to action +C>> taken at the meeting. +C>> +C>> 4. *Actions Taken By the Board of Trustees Without Meeting.* Any +C>> action required or permitted to be taken at any meeting of +C>> the Board of Trustees may be taken without a meeting if all +C>> +C>> Trustees consent in writing to such action. Such action +C>> shall be evidenced by written consents approving the lack of +C>> a meeting, signed by each Trustee. +C>> +C>> *Section 8: Board Committees.* The Trustees may elect or appoint +C>> one or more committees (including but not limited to an Executive +C>> Committee) and may delegate to any such committee or committees +C>> any or all of their powers, provided that any committee to which +C>> the powers of the Trustees are delegated shall consist solely of +C>> Trustees. Committees shall conduct their affairs in the same +C>> manner as is provided in these By Laws for the Trustees. The +C>> members of any committee shall remain in office at the pleasure +C>> of the Board of Trustees. +C>> +C>> *Section 9: Trustee Member Conflict of Interest.* +C>> +C>> 1. As set forth in Section 9(3) below, a Trustee of the IETF +C>> Administrative Support Foundation (IASF) who has a personal +C>> interest in a transaction, as defined below, may not +C>> participate in any discussion of that transaction by the +C>> Trustees of The IASF and may not vote to determine whether to +C>> authorize, approve, or ratify that transaction except as +C>> specifically described below. For purposes of these Bylaws, a +C>> "personal interest" is defined as any act that will provide, +C>> directly or indirectly, a financial benefit or a disparate +C>> benefit individually to the Trustee, or to a company he or +C>> she is employed by, has a significant financial interest in, +C>> or represents in any fashion. However, policies under +C>> consideration by the IASF are likely to have an impact on the +C>> business of every Trustee. It is expected that most policy + + + +Hollenbeck Informational [Page 24] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> decisions will have a direct or indirect impact on the +C>> Trustee's company, but such a non-individualized interest +C>> does not constitute a "personal interest" as used in these +C>> Bylaws. A "transaction" with The IASF for purposes of these +C>> Bylaws is a contract or consultancy in which the Trustee has +C>> a direct or indirect financial benefit, or a policy under +C>> consideration that will have a disparate and unusual impact +C>> on a business with which the Trustee is directly or +C>> indirectly associated. +C>> +C>> 2. The mere existence of a personal interest by a Trustee of The +C>> IASF in a transaction with the IASF shall not invalidate the +C>> IASF's ability to enter that transaction so long as the +C>> following conditions are met: (i) the material facts of the +C>> personal nature of the transaction with The IASF and the +C>> Trustee's interest in the transaction with the IASF are fully +C>> disclosed to the Board of Trustees of the IASF, either by the +C>> Trustee having a direct or indirect personal interest in the +C>> +C>> transaction with the IASF, or are brought to the attention of +C>> the Board by a third party; or (ii) the BoT of the IASF, by a +C>> vote of the Trustees (without a conflict of interest) of the +C>> IASF vote to authorize, approve, or ratify a transaction with +C>> the IASF; or (iii) the transaction with the IASF in which the +C>> direct or indirect personal interest of a IASF Trustee was +C>> disclosed to the BoT of The IASF and was determined by the +C>> BoT of the IASF entitled to vote on the matter is determined +C>> by the BoT voting to be in the IASF's interests, +C>> notwithstanding the personal interest of the non-voting +C>> Trustee. +C>> +C>> 3. In determining whether a conflict of interest exists, the BoT +C>> of the IASF has the prerogative, upon review of all facts and +C>> circumstances, to make its own determination of whether a +C>> conflict of interest exists and how it is appropriate to +C>> proceed. A Trustee who perceives the possibility of a +C>> conflict of interest for him or herself, or for another Board +C>> member, may raise this issue at any point prior to a vote on +C>> any issue. Any Trustee who perceives a possible conflict of +C>> interest may present justification with respect to whether or +C>> not a conflict of interest exists, but the entire Board, with +C>> the exception of the Trustee having the potential conflict of +C>> interest, shall make the final determination to proceed in +C>> such a matter. If the BoT finds there is a conflict of +C>> interest, the Trustee with the conflict may be excluded by +C>> the Chair of the Board from that portion of any meeting where +C>> a substantive discussion or decision to engage or not in such + + + + +Hollenbeck Informational [Page 25] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> a transaction is made, except that he or she may provide any +C>> information that will assist the Trustees in such a matter +C>> before leaving such a meeting. +C>> +C>> *Section 10. Approval of Meeting Minutes.* Minutes of the BoT of +C>> the IASF must be approved by a procedure adopted by the board and +C>> published on the IASF web site. +C>> +C>> 6.2.6 Article VI: Officers +C>> +C>> *Section 1: Number.* The officers of the IASF shall consist of a +C>> Chairman of the Board, a Treasurer and a Secretary, and such +C>> other inferior officers as the BoT may determine. +C>> +C>> *Section 2: Election Term of Office and Qualifications.* All +C>> officers shall be elected annually by the vote of a majority of +C>> the Board of Trustees present and voting (excluding abstentions) +C>> at the Annual Meeting. The Treasurer and Secretary need not be +C>> members of the Board. The Chair of the IETF nor the chair of the +C>> IAB shall be the Chairman of the Board of the IASF. +C>> +C>> *Section 3: Resignation.* An officer may resign by delivering his +C>> written resignation to the IASF at its principal office or to the +C>> Chair or Secretary. Such resignation shall be effective upon +C>> receipt or upon such date (if any) as is stated in such +C>> resignation, unless otherwise determined by the Board. +C>> +C>> *Section 4: Removal.* The BoT may remove any officer with or +C>> without cause by a vote of a majority of the entire number of +C>> Trustees then in office, at a meeting of the BoT called for that +C>> purpose. An officer may be removed for cause only if notice of +C>> such action shall have been given to all of the Trustees prior to +C>> the meeting at which such action is to be taken and if the +C>> officer so to be removed shall have been given reasonable notice +C>> and opportunity to be heard by the BoT. +C>> +C>> *Section 5: Vacancies.* In case any elected officer position of +C>> the IASF becomes vacant, the majority of the Trustees in office, +C>> although less than a quorum, may elect an officer to fill such +C>> vacancy at the next meeting of the BoT, and the officer so +C>> elected shall hold office and serve until the next Annual +C>> Meeting. +C>> +C>> *Section 6: Chairman of the Board.* The Chairman of the Board +C>> shall, when present, preside at all meetings of the BoT of the +C>> IASF. If the Chairman is not available to preside over a +C>> meeting, the majority of the Trustees present shall select +C>> another Trustee to preside at that meeting only. + + + +Hollenbeck Informational [Page 26] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> +C>> *Section 7: Treasurer.* The Treasurer shall have the custody of +C>> all funds, property, and securities of the IASF, subject to such +C>> regulations as may be imposed by the Board of Trustees. He or +C>> she may be required to give bond for the faithful performance of +C>> his or her duties, in such sum and with such sureties as the BoT +C>> may require or as required by law, whichever is greater. When +C>> necessary or proper, he or she may endorse on behalf of the IASF +C>> for collection, checks, notes and other obligations, and shall +C>> deposit same to the credit of the IASF at such bank or banks or +C>> depository as the BoT may designate. He or she shall make or +C>> cause to be made such payments as may be necessary or proper to +C>> be made on behalf of the IASF. He or she shall enter or cause to +C>> be entered regularly on the books of the IASF to be kept by him +C>> or her for that purpose, full and accurate account of all monies +C>> and obligations received and paid or incurred by him or her for +C>> or on account of the IASF, and shall exhibit such books at all +C>> reasonable times to any Trustee on application at the offices of +C>> the IASF incident to the Office of Treasurer, subject to the +C>> control of the BoT. Certain duties of the Treasurer as may be +C>> specified by the BoT may be delegated by the Treasurer. +C>> +C>> *Section 8: Secretary.* The Secretary shall have charge of such +C>> books, records, documents, and papers as the BoT may determine, +C>> and shall have custody of the corporate seal. The Secretary +C>> shall keep, or cause to be kept the minutes of all meetings of +C>> the BoT. The Secretary may sign, with the Chairman, in the name +C>> and on behalf of the IASF, any contracts or agreements, and he or +C>> she may affix the corporate seal of the IASF. He or she, in +C>> general, performs all the duties incident to the Office of +C>> Secretary, subject to the supervision and control of the Board of +C>> Trustees, and shall do and perform such other duties as may be +C>> assigned to him or her by the BoT or the Chairman of the BoT. +C>> Certain duties of the Secretary as may be specified by the BoT +C>> may be delegated by the Secretary. +C>> +C>> *Section 9: Other Powers and Duties.* Each officer shall have in +C>> addition to the duties and powers specifically set forth in these +C>> By Laws, such duties and powers as are customarily incident to +C>> his office, and such duties and powers as the Trustees may from +C>> time to time designate. +C>> + + + + + + + + + +Hollenbeck Informational [Page 27] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 6.2.7 Article VII: Amendments +C>> +C>> *Section 1: By Laws.* These By Laws may be amended by an +C>> affirmative vote of a majority of the Trustees then in office +C>> (excluding abstentions) at a regular meeting of the board or a +C>> meeting of the board called for that purpose as long as the +C>> proposed changes are made available to all trustees and posted to +C>> the IETF Announce list at least 30 days before any such meeting. +C>> +C>> *Section 2: Articles of Incorporation.* The Articles of +C>> Incorporation of the IASF may be amended by an affirmative vote +C>> of two-thirds of the BoT then in office at a regular meeting of +C>> the board or a meeting of the board called for that purpose as +C>> long as the proposed changes are made available to all trustees +C>> and posted to the IETF Announce list at least 30 days before any +C>> such meeting. +C>> +C>> 6.2.8 Article VIII: Dissolution +C>> +C>> Upon the dissolution of the IASF, the IASF, after paying or +C>> making provisions for the payment of all of the liabilities of +C>> the IASF, dispose of all of the assets of the IASF exclusively +C>> for the exempt purposes of the IASF in such manner or to such +C>> organization or organizations operated exclusively for social +C>> welfare or charitable purposes. Any such assets not so disposed +C>> of shall be disposed of by a court of competent jurisdiction of +C>> the county in which the principal office of the organization is +C>> then located, exclusively for such purposes. In the event of a +C>> +C>> sale or dissolution of the corporation, the surplus funds of the +C>> corporation shall not inure to the benefit of, or be +C>> distributable to, its Trustees, officers, or other private +C>> persons. +C>> +C>> 6.2.9 Article IX: Miscellaneous Provisions +C>> +C>> *Section 1: Fiscal Year.* The fiscal year of the IASF shall be +C>> from January 1 to December 31 of each year. +C>> +C>> *Section 2: Execution of Instruments.* All checks, deeds, leases, +C>> transfers, contracts, bonds, notes and other obligations +C>> authorized to be executed by an officer of the IASF in its behalf +C>> shall be signed by the Chairman of the Board or the Treasurer, or +C>> as the Trustees otherwise determine. A certificate by the +C>> Secretary as to any action taken by the BoT shall as to all +C>> persons who rely thereon in good faith be conclusive evidence of +C>> such action. +C>> + + + +Hollenbeck Informational [Page 28] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> *Section 3: Severability.* Any determination that any provision +C>> of these By-Laws is for any reason inapplicable, illegal or +C>> ineffective shall not affect or invalidate any other provision of +C>> these By-Laws. +C>> +C>> *Section 4: Articles of Incorporation.* All references in these +C>> By Laws to the Articles of Incorporation shall be deemed to refer +C>> to the Articles of Incorporation of the IASF, as amended and in +C>> effect from time to time. +C>> +C>> *Section 5: Gender.* Whenever used herein, the singular number +C>> shall include the plural, the plural shall include the singular, +C>> and the use of any gender shall include all genders. +C>> +C>> *Section 6: Successor Provisions.* All references herein: (1) to +C>> the Internal Revenue Code shall be deemed to refer to the +C>> Internal Revenue Code of 1986, as now in force or hereafter +C>> amended; (2) to the Code of the State of Virginia, or any Chapter +C>> thereof, shall be deemed to refer to such Code or Chapter as now +C>> in force or hereafter amended; (3) the particular sections of the +C>> Internal Revenue Code or such Code shall be deemed to refer to +C>> similar or successor provisions hereafter adopted; and (4) to the +C>> Request for Comment Series shall be deemed to refer to the +C>> Request for Comment Series as they are now in force or hereafter +C>> amended. +C>> +C>> 7. Acknowledgment of Contributions and Reviews +C>> +C>> A lot of text was taken from the report from Carl Malamud. +C>> +C>> Further review was done by various IESG and IAB members. Carl +C>> Malamud also reviewed this document and helped with making the +C>> text better English and easier to read. +C>> +C>> This document was created with "xml2rfc" +C>> <http://xml.resource.org/> using the format specified +C>> in [RFC2629]. +C>> +C>> 8. IANA Considerations +C>> +C>> This documents requires no action from IANA. +C>> + + + + + + + + + +Hollenbeck Informational [Page 29] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> 9. Security Considerations +C>> +C>> This document describes a scenario for the structure of the +C>> IETF's administrative support activities. It introduces no +C>> security considerations for the Internet. +C>> +C>> Safety considerations for the integrity of the standards process +C>> are outlined in Appendix C. +C>> +C>> 10. References +C>> +C>> 10.1 Normative References +C>> +C>> [RFC2026] Bradner, S., "The Internet Standards Process -- +C>> Revision 3", BCP 9, RFC 2026, October 1996. +C>> +C>> [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved +C>> in the IETF Standards Process", BCP 11, RFC 2028, +C>> October 1996. +C>> +C>> [RFC2031] Huizer, E., "IETF-ISOC relationship", RFC 2031, +C>> October 1996. +C>> +C>> [RFC3677] Daigle, L. and Internet Architecture Board, "IETF ISOC +C>> Board of Trustee Appointment Procedures", BCP 77, RFC +C>> 3677, December 2003. +C>> +C>> [RFC3716] Advisory, IAB., "The IETF in the Large: Administration +C>> and Execution", RFC 3716, March 2004. +C>> +C>> [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and +C>> Recall Process: Operation of the Nominating and Recall +C>> Committees", BCP 10, RFC 3777, June 2004. +C>> +C>> [Virginia] State of Virginia, "Title 13.1: Corporations, Limited +C>> Liability Companies, Business Trusts", Undated, +C>> +C>> <http://leg1.state.va.us/cgi- +C>> bin/legp504.exe?000+cod+TOC1301000> . +C>> +C>> 10.2 Informative References +C>> +C>> [I-D.ietf-xmpp-core] Saint-Andre, P., "Extensible Messaging and +C>> Presence Protocol (XMPP): Core", draft-ietf-xmpp- +C>> core-24 (work in progress), May 2004. +C>> + + + + + +Hollenbeck Informational [Page 30] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> [I-D.malamud-consultant-report] Malamud, C., "IETF Administrative +C>> Support Functions", draft-malamud-consultant-report-01 +C>> (work in progress), September 2004. +C>> +C>> [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, +C>> June 1999. +C>> +C>> URIs +C>> +C>> [1] <http://www.state.va.us/cgi-bin/scc- +C>> clerkdl.pl?scc819&Articles_of_Incorporation_-_Nonstock_Corpo +C>> ration> +C>> +C>> Authors' Addresses +C>> +C>> Bert Wijnen +C>> Lucent Technologies +C>> Schagen 33 +C>> 3461 GL Linschoten +C>> Netherlands +C>> Phone: +31-348-407-775 +C>> EMail: bwijnen at lucent.com +C>> +C>> Harald Tveit Alvestrand +C>> Cisco Systems +C>> Weidemanns vei 27 +C>> Trondheim 7043 +C>> Norway +C>> EMail: harald at alvestrand.no +C>> +C>> Peter W. Resnick +C>> QUALCOMM Incorporated +C>> 5775 Morehouse Drive +C>> San Diego, CA 92121-1714 +C>> US +C>> EMail: presnick at qualcomm.com +C>> + + + + + + + + + + + + + + +Hollenbeck Informational [Page 31] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> Appendix A. Justification, Reasoning and Motivations +C>> +C>> +C>> Quite a bit of the proposals from the consultant report have been +C>> incorporated in this recommendation. However, a number of +C>> changes have been made. In this section we try to explain which +C>> changes were made and why. +C>> +C>> A.1 Changes to the name of the administrative entity +C>> +C>> In order to make it very clear that the new and legal +C>> administrative entity is separate from the ISOC IETF activity +C>> that deals with standardization and protocol development, this +C>> recommendation uses "The IETF Administrative Support Foundation" +C>> as the name for the corporation to be created. +C>> +C>> A.2 Domicile +C>> +C>> Various questions have been raised if the choice of Domicile +C>> should be further investigated. In order to make progress this +C>> document recommends to make a definite choice now and go for a US +C>> based not-for-profit corporation in the state of Virginia. +C>> Further investigation would most probably delay the whole process +C>> by at least half a year. +C>> +C>> A.3 Changes to the composition of the BoT +C>> +C>> The consultant report had a proposal for Position-based Trustees, +C>> which would automatically make the IAB chair and the IETF chair +C>> voting members of the Board of Trustees (BoT) of the IETF +C>> Administrative Support Foundation. There was discussion on the +C>> IETF mailing list that those people are not selected because of +C>> their business acumen but rather for their technical leadership. +C>> We do not want to change those criteria. Another concern was +C>> that this might generate a conflict of interest as well. So this +C>> recommendation has made the IAB and IETF chairs liaisons to the +C>> BoT. +C>> +C>> Instead of making IAB and IESG chairs voting Trustees, this +C>> recommendation specifies that IAB and IESG can each select an +C>> outside (i.e. not a member of IAB or IESG) person as a voting +C>> Trustee. +C>> +C>> The selection of three (3) IETF selected Trustees has not changed +C>> in this recommendation. However, there is a concern that the +C>> current composition of the Nomcom is not tailored to selecting +C>> people for this position. So over time a different process may +C>> need to be defined for selecting those Trustees. + + + +Hollenbeck Informational [Page 32] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> +C>> In order to balance the ISOC and IETF people present at the BoT +C>> meetings, this recommendation also specifies that the chair and +C>> +C>> president of ISOC also function as liaisons to the BoT of the +C>> IETF Administrative Support Foundation. +C>> +C>> Appendix B. Domicile of the IETF Administrative Support Foundation +C>> +C>> A U.S. non-profit, non-member corporation is being recommended. +C>> This recommendation is based on simple considerations of +C>> expediency and pragmatism: a transition will be simplest and +C>> least risky (in the short term). The reasoning is as follows: +C>> +C>> o Administrative support for the IETF is currently enmeshed in a +C>> series of relationships with other institutions, most of which +C>> are also U.S.-chartered non-profit organizations. Any change +C>> in the institutional status of administrative support +C>> functions will require familiarity with U.S. nonprofit law. +C>> Incorporation in another country would require familiarity +C>> with those laws as well. Thus, the incorporation expenses +C>> would be higher and the process would take longer. +C>> +C>> o U.S. law has a strong concept of "nexus," which is a +C>> determination of when a foreign organization has enough +C>> relationship to U.S. law to fall under the jurisdiction of a +C>> U.S. court. Because of a long history of operating in the +C>> U.S., numerous meetings in the U.S., and the large number of +C>> U.S. residents who are participants and leaders, we feel it is +C>> likely that U.S. courts would find nexus in relation to our +C>> US-based activities, even if the IETF administrative support +C>> organization was incorporated in another country. In other +C>> words, incorporating in a country besides the U.S. does not +C>> necessarily free the support organization from any perceived +C>> vagaries of U.S. law. +C>> +C>> o Incorporating in a country other than the US may have tax +C>> implications if the Internet Society is providing funding +C>> support. +C>> +C>> o It is very likely that the IETF Administrative Support +C>> Foundation would be deemed to clearly fall under the +C>> "scientific" and "educational" grounds for classification as a +C>> tax-exempt charity under section 501(c)(3) of the IRS code, so +C>> a tax-exempt application should be quite straight-forward. +C>> +C>> o The incorporation laws of the U.S. states being considered do +C>> not require that any members of the Board of Trustees be of a + + + +Hollenbeck Informational [Page 33] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> certain nationality or state residency (e.g., there are no +C>> "local director" requirements). The U.S. Dept. of Commerce +C>> foreign-controlled organization reporting requirements apply +C>> only to "business enterprises", and do not apply to non-profit +C>> +C>> entities such as an IETF administrative support organization. +C>> +C>> Since this document recommends incorporating in the U.S., +C>> Virginia is the logical pick as the state of domicile to allow +C>> the IETF administrative support organization to make use of ISOC +C>> headquarters to house its single employee (though the employee +C>> might be able to be housed at the Internet Society even if the +C>> incorporation were elsewhere, for example the ISOC Geneva +C>> office). +C>> +C>> Appendix C. Risk Analysis +C>> +C>> This scenario (as do all scenarios) has some risks. This section +C>> tries to enumerate the sort of risks that we recognize and +C>> summarizes why we think we can accept the risk or what kind of +C>> action we think we can take if the risk indeed materializes into +C>> a problem. +C>> +C>> C.1 US Domicile risks +C>> +C>> As explained in [I-D.malamud-consultant-report], incorporating in +C>> the US carries two specific risks: the perception of the IETF +C>> being a US-based organization and the potential for (or +C>> perception of) governmental interference. +C>> +C>> The IETF is an international organization. However, even now, +C>> the fact that the IETF standards processes are run in English and +C>> that many of its current support organizations are US-based +C>> leaves an impression that the IETF is too US-centric. +C>> Incorporating the new administrative entity in the US may add to +C>> that perception. +C>> +C>> Also, the IETF history is based in US federal government research +C>> and funding. Though IETF is long separated from those +C>> beginnings, even in the past few years there have been +C>> interactions between the US government and the IETF that have +C>> concerned people. Incorporating the administrative entity in the +C>> US may invite more US governmental interference in the standards +C>> activity of the IETF, or at the very least may leave the +C>> perception that the US government might get involved. +C>> +C>> Both of these are serious problems, but we think there is +C>> justification for and at least one mitigation to these risks. Of + + + +Hollenbeck Informational [Page 34] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> course, the primary reason to consider US incorporation is +C>> expedience (See section 4.4.1.1 of [I-D.malamud-consultant- +C>> report]). We agree that the expedience makes US incorporation +C>> worth the risk. But incorporating in multiple domiciles would +C>> significantly mitigate the risk. Assuming we go down the path of +C>> +C>> US incorporation, we would like legal counsel to advise on the +C>> possibility of incorporating in other domiciles (specifically +C>> Switzerland and The Netherlands) at a later date after US +C>> incorporation has been completed. If this is (as we suspect) +C>> indeed possible, we think this would be the best way to go +C>> forward. +C>> +C>> C.2 Non-profit status risk +C>> +C>> One of the risks pointed out to incorporation was the potential +C>> that we would not get non-profit status, and that we must +C>> therefore preserve some money in escrow for tax liability +C>> purposes. Estimates for the time it will take to get such status +C>> can be several months or even longer in some cases. +C>> +C>> It is important to point out that the tax liability is based on +C>> profits, not on gross revenues. If the IASF is only taking in +C>> enough money to cover expenses, there would be very little tax +C>> liability. However, if more revenue is brought in than is spent, +C>> for example to build up an endowment or operating reserve, that +C>> "profit" is potentially taxable if non-profit status is not +C>> granted. +C>> +C>> To mitigate this risk, the corporation could be created and non- +C>> profit status applied for first, and operation of the corporation +C>> would only begin after non-profit status was obtained. The IETF +C>> would use an interim plan for continued operations until that +C>> time. This way, no money would need to be in escrow during the +C>> process of applying for non-profit status. However, that seems +C>> an excessively cautious path to take given what appears to be the +C>> fairly clear non-profit nature of the IETF. +C>> +C>> Commencing operations while the non-profit application is being +C>> considered, but being careful about balancing revenue with +C>> expenses and keeping an appropriate escrow account seems like a +C>> prudent task. Further, any fund raising campaigns that result in +C>> shifts to the balance sheet of the IASF should be conducted +C>> cautiously until non-profit status is granted. +C>> + + + + + + +Hollenbeck Informational [Page 35] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +C>> C.3 Execution risks +C>> +C>> It is important that the execution goes well. Risks that we are +C>> aware of include: +C>> +C>> o we can't hire a good IAD +C>> +C>> o we fail to project cash flow properly and go insolvent +C>> +C>> o we can't cut a deal with Foretec and have no 2005 meetings +C>> +C>> o we get bad lawyers and they take too long and charge too much +C>> +C>> o isoc runs out of money and doesn't tell us early enough +C>> +C>> In order to mitigate these problems we have a proposed work plan +C>> included in this document. It is important that we get review of +C>> this work plan by as many eyes as we can get, to make sure we +C>> have considered all the possible steps that need to be taken. +C>> +C>> C.4 Insolvency risk +C>> +C>> Improper management controls and procedures or other imprudent +C>> fiscal or administrative practices could expose the IETF to a +C>> risk of insolvency. Careful selection of trustees, a process of +C>> budget approval, and a methodical system of fiscal controls are +C>> necessary to minimize this risk. +C>> +C>> C.5 Legal risks +C>> +C>> Improper formulation of the legal framework underlying the IETF +C>> may expose the institution and individuals in leadership +C>> positions to potential legal risks. Any such risk under this +C>> plan appears to be equivalent to the risk faced by the community +C>> under the current legal framework. This risk is further +C>> mitigated by a thorough review by legal counsel, and by use of +C>> insurance coverage. +C>> +C>> The legal exposure is best minimized by a careful adherence to +C>> our procedures and processes, as defined by the Best Current +C>> Practice Series. A carefully stated process, such as the BCP +C>> documents that govern the selection of leadership positions and +C>> define the standards process are the best insurance against legal +C>> exposure, provided care is taken to stick to the process +C>> standards that have been set. Adherence to a public rule book and +C>> a fully open process are the most effective mechanisms the IETF +C>> community can use. + + + + +Hollenbeck Informational [Page 36] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +Appendix: Scenario O + + This Appendix reproduces the contents of an Internet-Draft defining + Scenario O, as it was posted on 20 September 2004. A table of + contents has been removed from this copy and the text has been + reformatted to fit within IETF publication guidelines. Each line is + prefixed with "O>>". + +O>> L. Daigle +O>> VeriSign +O>> M. Wasserman +O>> ThingMagic +O>> September 20, 2004 +O>> +O>> AdminRest Scenario O: An IETF-Directed Activity Housed Under the +O>> Internet Society (ISOC) Legal Umbrella +O>> +O>> Abstract +O>> +O>> This document defines an alternative proposal for the structure +O>> of the IETF's administrative support activity (IASA) -- an IETF- +O>> defined and directed activity that operates within the ISOC legal +O>> umbrella. It proposes the creation of an IETF Administrative +O>> Oversight Committee (IAOC) that is selected by and accountable to +O>> the IETF community. This committee would provide oversight for +O>> the IETF administrative support activity, which would be housed +O>> within the ISOC legal umbrella. In order to allow the community +O>> to properly evaluate this scenario, some draft BCP wording is +O>> included. +O>> +O>> 1. Overview of Scenario O +O>> +O>> IETF community discussions of the scenarios for administrative +O>> restructuring presented in Carl Malamud's consultant report [I- +O>> D.malamud-consultant-report] have led to the identification of a +O>> potentially viable alternative that is not included in that +O>> report -- an IETF-defined and directed administrative support +O>> function housed under the ISOC legal umbrella (called "IASA" +O>> hereafter). This new scenario retains some properties of the +O>> original ISOC-based scenarios, Scenarios A and B. However, this +O>> new scenario aims to provide: +O>> +O>> o continued close relationship with ISOC +O>> +O>> o a clear basis from which the IETF can define (and, over time, +O>> refine) the administrative activity in terms of IETF community +O>> needs, using existing IETF/ISOC processes +O>> + + + +Hollenbeck Informational [Page 37] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> o an operational oversight board that is accountable to the IETF +O>> community +O>> +O>> o continued separation between the IETF standards activity and +O>> any fund-raising for standards work (within ISOC) +O>> +O>> o appropriate ISOC oversight of its standards activities funds +O>> +O>> This scenario is nicknamed "Scenario O" -- it is derived from, +O>> but does not entirely encompass, Scenario A or Scenario B. +O>> +O>> In Scenario O, the IETF administrative support function would be +O>> defined in a BCP that would be created via the IETF standards +O>> process [RFC2026] and approved by the ISOC Board of Trustees. +O>> This BCP would describe the scope of an IETF Administrative +O>> Support Activity (IASA) and would define the structure and +O>> responsibilities of the IETF Administrative Oversight Committee +O>> (IAOC), an IETF-selected body responsible for overseeing the +O>> IASA. Like the Internet Architecture Board (IAB), the IASA would +O>> be housed within the ISOC legal umbrella. The BCP would also +O>> describe ISOC's responsibilities within this scenario, including +O>> requirements for financial accounting and transparency. A draft +O>> of this BCP is included in the next section of this document. +O>> +O>> Scenario O allows us to establish IETF control over our +O>> administrative support functions in terms of determining that +O>> they meet the community's needs, and adjusting them from time to +O>> time using IETF processes. At the same time, it does not require +O>> that the IETF community determine, create and undertake the risks +O>> associated with an appropriate corporate structure (with similar +O>> financial infrastructure and tax-exempt status to ISOC's) in +O>> order to solve the pressing administrative issues outlined in +O>> [RFC3716]. This proposal also defines the boundaries of the IASA +O>> so that it could be encapsulated and moved elsewhere at some +O>> future date, should that ever be desirable. +O>> +O>> 2. Draft of Administrative Support BCP +O>> +O>> This section proposes draft text for a BCP that would define the +O>> scope and structure of the IASA. Although this text would +O>> require further refinement within the IETF community, this +O>> section is intended to be clear and complete enough to allow the +O>> community to reach a well-informed opinion regarding this +O>> scenario. +O>> + + + + + + +Hollenbeck Informational [Page 38] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> 2.1 Definition of the IETF Administrative Support Activity (IASA) +O>> +O>> The IETF undertakes its technical activities as an ongoing, open, +O>> consensus-based process. The Internet Society has long been a +O>> part of the IETF's standards process, and this document does not +O>> affect the ISOC-IETF working relationship concerning standards +O>> development or communication of technical advice. The purpose of +O>> this memo is to define an administrative support activity that is +O>> responsive to the IETF technical community's needs, as well as +O>> consistent with ISOC's operational, financial and fiduciary +O>> requirements while supporting the IETF technical activity. +O>> +O>> The IETF Administrative Support Activity (IASA) provides +O>> administrative support for the technical work of the IETF. This +O>> +O>> includes, as appropriate, undertaking or contracting for the +O>> work described in (currently, [RFC3716] but the eventual BCP +O>> should include the detail as an appendix), covering IETF document +O>> and data management, IETF meetings, any operational agreements or +O>> contracts with the RFC Editor and IANA. This provides the +O>> administrative backdrop required to support the IETF standards +O>> process and to support the IETF organized technical activities, +O>> including the IESG, IAB and working groups. This includes the +O>> financial activities associated with such IETF support +O>> (collecting IETF meeting fees, payment of invoices, appropriate +O>> financial management, etc). The IASA is responsible for ensuring +O>> that the IETF's administrative activities are done and done well; +O>> it is not the expectation that the IASA will undertake the work +O>> directly, but rather contract the work from others, and manage +O>> the contractual relationships in line with key operating +O>> principles such as efficiency, transparency and cost +O>> effectiveness. +O>> +O>> The IASA is distinct from other IETF-related technical functions, +O>> such as the RFC editor, the Internet Assigned Numbers Authority +O>> (IANA), and the IETF standards process itself. The IASA is not +O>> intended to have any influence on the technical decisions of the +O>> IETF or on the technical contents of IETF work. +O>> +O>> 2.1.1 Structure of the IASA +O>> +O>> The IASA will be structured to allow accountability to the IETF +O>> community. It will determine the ongoing success of the activity +O>> in meeting IETF community needs laid out in this BCP, as well as +O>> ISOC oversight of its financial and resource contributions. The +O>> supervisory body defined for this will be called the IETF +O>> Administrative Oversight Committee (IAOC). The IAOC will consist +O>> of volunteers, all chosen directly or indirectly by the IETF + + + +Hollenbeck Informational [Page 39] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> community, as well as appropriate ex officio appointments from +O>> ISOC and IETF leadership. The IAOC will be accountable to the +O>> IETF community for the effectiveness, efficiency and transparency +O>> of the IASA. +O>> +O>> The IASA will initially consist of a single full-time employee of +O>> ISOC, the IETF Administrative Director (IAD). The IAD will +O>> require a variety of financial, legal and administrative support, +O>> and it is expected that this support will be provided by ISOC +O>> support staff following an expense and/or allocation model TBD. +O>> +O>> Although the IAD will be a full-time ISOC employee, he will work +O>> under the direction of the IAOC. The IAD will be selected by a +O>> committee of the IAOC, consisting minimally of the ISOC President +O>> and the IETF Chair. This same committee will be responsible for +O>> periodically reviewing the performance of the IAD and determining +O>> any changes to his employment and compensation. In certain cases +O>> (to be defined clearly -- chiefly cases where the ISOC employee +O>> is determined to have contravened basic ISOC policies), the ISOC +O>> President may make summary decisions, to be reviewed by the +O>> hiring committee after the fact. +O>> +O>> The IAD will be responsible for administering the IETF finances, +O>> managing a separate bank account for the IASA, and establishing +O>> and administering the IASA budget. To perform these activities, +O>> the IAD is expected to have signing authority comparable to other +O>> ISOC director-level employees. Generally, expenses or agreements +O>> outside that authority to be approved for financial soundness as +O>> determined by ISOC policy. The joint expectation is that ISOC's +O>> policies will be consistent with allowing the IAD to carry out +O>> IASA work effectively and efficiently. Should the IAOC have +O>> concerns about that, the IAOC and ISOC commit to working out +O>> other policies that are mutually agreeable. +O>> +O>> The IAD will also fill the role of the IETF Executive Director, +O>> as described in various IETF process BCPs. All other +O>> administrative functions will be outsourced via well-defined +O>> contracts. The IAD will be responsible for negotiating and +O>> maintaining those contracts, as well as providing any +O>> coordination that is necessary to make sure the IETF +O>> administrative support functions are properly covered. +O>> +O>> 2.1.2 IAD Responsibilities +O>> +O>> The day to day responsibilities of the IAD will focus on managing +O>> contracts with the entities providing the work supporting the +O>> IETF technical activity. +O>> + + + +Hollenbeck Informational [Page 40] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> The IAD will provide regular (monthly and quarterly) reports to +O>> the IAOC and ISOC. +O>> +O>> All contracts will be negotiated by the IAD (with input from any +O>> other appropriate bodies), and reviewed by the IAOC. The +O>> contracts will be executed by ISOC, on behalf of the IETF, after +O>> whatever review ISOC requires (e.g., legal, Board of Trustees). +O>> +O>> The IAD will prepare an annual budget, which will be reviewed and +O>> approved by the IAOC. The IAD will be responsible for presenting +O>> this budget to the ISOC Board of Trustees, as part of ISOC's +O>> annual financial planning process. The partnering is such that +O>> the IAOC is responsible for ensuring the suitability of the +O>> budget for meeting the IETF community's needs, but it does not +O>> bear fiduciary responsibility; the ISOC board needs to review and +O>> +O>> understand the budget and planned activity in have enough detail +O>> of the budget and proposed plans to properly carry out its +O>> fiduciary responsibility. +O>> +O>> 2.1.3 IAOC Responsibilities +O>> +O>> The role of the IAOC is to provide appropriate input to the IAD, +O>> and oversight of the IASA functioning. The IAOC is not expected +O>> to be regularly engaged in IASA work, but rather to provide +O>> appropriate approval and oversight. +O>> +O>> Therefore, the IAOC's responsibilities are: +O>> +O>> o Select the IAD, as described above. +O>> +O>> o Review the IAD's financial reports, and provide approval of +O>> the IAD's budget proposals in terms of fitness for IETF +O>> purposes. +O>> +O>> o Review IASA functioning with respect to meeting the IETF +O>> community's working needs. +O>> +O>> The IAOC's role is to review, not carry out the work of, the IAD +O>> and IASA. As such, it is expected the IAOC will have monthly +O>> teleconferences and periodic face to face meetings, probably +O>> coincident with IETF plenary meetings, consistent with ensuring +O>> an efficient and effective operation. +O>> + + + + + + + +Hollenbeck Informational [Page 41] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> 2.1.4 IASA Funding +O>> +O>> The IASA is supported financially in 3 ways: +O>> +O>> 1. IETF meeting revenues. The IAD, in consultation with the +O>> IAOC, sets the meeting fees as part of the budgeting process. +O>> All meeting revenues go to the IASA. +O>> +O>> 2. Designated ISOC donations. The IETF and IASA do no specific +O>> fund raising activities; this maintains separation between +O>> fundraising and standards activities. Any organization +O>> interested in supporting the IETF activity will continue to +O>> be directed to ISOC, and any funds ISOC receives specifically +O>> for IETF activities (as part of an ISOC program that allows +O>> for specific designation) will be put in the IASA bank +O>> account for IASA management. +O>> +O>> 3. Other ISOC support. ISOC will deposit in the IASA account, +O>> each quarter, the funds committed to providing as part of the +O>> IASA budget (where the meeting revenues and specific +O>> +O>> donations do not cover the budget). These funds may come +O>> from member fees or from other revenue streams ISOC may +O>> create. +O>> +O>> Note that the goal is to achieve and maintain a viable IETF +O>> support function based on meeting fees and specified donations, +O>> and the IAOC and ISOC are expected to work together to attain +O>> that goal. (I.e., dropping the meeting fees to $0 and expecting +O>> ISOC to pick up the slack is not desirable; nor is raising the +O>> meeting fees to prohibitive levels to fund all non-meeting- +O>> related activities!). +O>> +O>> Also, in normal operating circumstances, the IASA would look to +O>> have a 6 month operating reserve for its activities. Rather than +O>> having the IASA attempt to accrue that in its bank account, the +O>> IASA looks to ISOC to build and provide that operational reserve +O>> (through whatever mechanism instrument ISOC deems appropriate -- +O>> line of credit, financial reserves, etc). Such reserves do not +O>> appear instantaneously; the goal is to reach that level of +O>> reserve by 3 years after the creation of the IASA. It is not +O>> expected that any funds associated with such reserve will be held +O>> in the IASA bank account. +O>> + + + + + + + +Hollenbeck Informational [Page 42] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> 2.2 IAOC Membership, Selection and Accountability +O>> +O>> Note: This section is particularly subject to change as we work +O>> to find the best way to achieve the key principles. The key +O>> principles being adhered to are that while this should be +O>> reasonably separate from IETF Standards process management: +O>> +O>> o the IETF and IAB Chairs need to be involved to a level that +O>> permits them to be involved in and oversee the aspects +O>> pertinent to their roles in managing the technical work (e.g., +O>> the IAB looks after the RFC Editor relationship) +O>> +O>> o the IETF and IAB Chairs must not be critical path to getting +O>> decisions to and through the IASA. +O>> +O>> The current draft, below, therefore makes the IETF Chair ex +O>> officio voting member of the IAOC, and the IAB Chair a non-voting +O>> liaison. Future versions may change either or both, depending on +O>> what makes sense to the IETF community in its deliberations. +O>> +O>> The IAOC will consist of seven voting members who will be +O>> selected as follows: +O>> +O>> o 2 members chosen by the IETF Nominations Committee (NomCom) +O>> +O>> o 1 member chosen by the IESG +O>> +O>> o 1 member chosen by the IAB +O>> +O>> o 1 member chosen by the ISOC Board of Trustees +O>> +O>> o The IETF Chair (ex officio) +O>> +O>> o The ISOC President/CEO (ex officio) +O>> +O>> There will also be two non-voting, ex officio liaisons: +O>> +O>> o The IAB Chair +O>> +O>> o The IETF Administrative Director +O>> +O>> The voting members of the IAOC will choose their own chair each +O>> year using a consensus mechanism of its choosing. Any appointed +O>> voting member of the IAOC may serve as the IAOC Chair (i.e., not +O>> the IETF Chair or the ISOC President/CEO). The role of the IAOC +O>> Chair is to organize the IAOC. The IAOC Chair has no formal +O>> duties for representing the IAOC, except as directed by IAOC +O>> consensus. + + + +Hollenbeck Informational [Page 43] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> +O>> The members of the IAOC will typically serve two year terms. +O>> Initially, the IESG and ISOC Board will make one-year +O>> appointments, the IAB will make a two-year appointment, and the +O>> Nomcom will make one one-year appointment and one two-year +O>> appointment to establish a pattern where approximately half of +O>> the IAOC is selected each term. +O>> +O>> The two NomCom selected members will be selected using the +O>> procedures described in RFC 3777. For the initial selection, the +O>> IESG will provide the list of desired qualifications for these +O>> positions. In later years, this list will be provided by the +O>> IAOC. +O>> +O>> While there are no hard rules regarding how the IAB and the IESG +O>> should select members of the IAOC, it is not expected that they +O>> will typically choose current IAB or IESG members, if only to +O>> avoid overloading existing leadership. However, they should +O>> choose people who are familiar with the administrative support +O>> needs of the IAB, the IESG and/or the IETF standards process. It +O>> is suggested that a fairly open process be followed for these +O>> selections, perhaps with an open call for nominations and/or a +O>> period of public comment on the candidates. The IAB and IESG are +O>> encouraged to look at the procedure for IAB selection of ISOC +O>> Trustees for an example of how this might work. +O>> +O>> Although the IAB and IESG will choose some members of the IAOC, +O>> those members will not directly represent the bodies that chose +O>> them. All members of the IAOC are accountable directly to the +O>> IETF community. To receive direct feedback from the community, +O>> the IAOC will hold an open meeting at least once per year at an +O>> IETF meeting. This may take the form of an open IAOC plenary or +O>> a working meeting held during an IETF meeting slot. The form and +O>> contents of this meeting are left to the discretion of the IAOC +O>> Chair. +O>> +O>> Decisions of IAOC members or the entire IAOC are subject to +O>> appeal using the procedures described in RFC 2026. The initial +O>> appeal of an individual decision will go to the full IAOC. +O>> Appeals of IAOC decisions will go to the IESG and continue up the +O>> chain as necessary (to the IAB and the ISOC Board). The IAOC +O>> will play no role (aside from possible administrative support) in +O>> appeals of WG Chair, IESG or IAB decisions. +O>> + + + + + + + +Hollenbeck Informational [Page 44] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> In the event that an IAOC member abrogates his duties or acts +O>> against the bests interests of the IETF community, IAOC members +O>> are subject to recall using the recall procedure defined in RFC +O>> 3777. IAB and IESG-appointed members of the IAOC are not subject +O>> to recall by their appointing bodies. +O>> +O>> 2.3 IASA Budget Process +O>> +O>> While the IASA sets a budget for the IETF's administrative needs, +O>> its budget process clearly needs to be closely coordinated with +O>> ISOC's. The specific timeline will be established each year, +O>> before the second IETF meeting. A general annual timeline for +O>> budgeting will be: +O>> +O>> July 1 The IAD presents a budget proposal (for the following +O>> fiscal year, with 3 year projections) to the IAOC. +O>> +O>> August 1 The IAOC approves the budget proposal for IETF purposes, +O>> after any appropriate revisions. As the ISOC President is +O>> part of the IAOC, the IAOC should have a preliminary +O>> indication of how the budget will fit with ISOC's own +O>> budgetary expectations. The budget proposal is passed to the +O>> ISOC Board of Trustees for review in accordance with their +O>> fiduciary duty. +O>> +O>> September 1 The ISOC Board of Trustees approves the budget +O>> proposal provisionally. During the next 2 months, the budget +O>> may be revised to be integrated in ISOC's overall budgeting +O>> process. +O>> +O>> +O>> November 1 Final budget to the ISOC Board for approval. +O>> +O>> The IAD will provide monthly accountings of expenses, and will +O>> update forecasts of expenditures quarterly. This may necessitate +O>> the adjustment of the IASA budget. The revised budget will need +O>> to be approved by the IAOC and ISOC Board of Trustees. +O>> +O>> 2.4 Relationship of the IAOC to Existing IETF Leadership +O>> +O>> The IAOC will be directly accountable to the IETF Community. +O>> However, the nature of the IAOC's work will involve treating the +O>> IESG and IAB as internal customers. The IAOC should not consider +O>> its work successful unless the IESG and IAB are satisfied with +O>> the administrative support that they are receiving. +O>> + + + + + +Hollenbeck Informational [Page 45] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> 2.5 ISOC Responsibilities for IASA +O>> +O>> Within ISOC, support for the IASA should be structured to meet +O>> the following goals: +O>> +O>> Transparency: The IETF community should have complete visibility +O>> into the financial and legal structure of the ISOC standards +O>> activity. In particular, the IETF community should have access +O>> to a detailed budget for the entire standards activity, +O>> quarterly financial reports and audited annual financials. In +O>> addition, key contract material and MOUs should be publicly +O>> available. Most of these goals are already met by ISOC today. +O>> The IAOC will be responsible for providing the IETF community +O>> with regular overviews of the state of affairs. +O>> +O>> Unification: As part of this arrangement, ISOC's sponsorship of +O>> the RFC Editor, IAB and IESG, as well as insurance coverage +O>> for the IETF will be managed as part of the IASA under the +O>> IAOC. +O>> +O>> Independence: The IASA should be financially and legally distinct +O>> from other ISOC activities. IETF meeting fees should be +O>> deposited in a separate IETF-specific bank account and used to +O>> fund the IASA under the direction and oversight of the IAOC. +O>> Any fees or payments collected from IETF meeting sponsors +O>> should also be deposited into this account. This account will +O>> be administered by the IAD and used to fund the IASA in +O>> accordance with a budget and policies that are developed as +O>> described above. +O>> +O>> Support: ISOC may, from time to time, choose to transfer other +O>> funds into this account to fund IETF administrative projects +O>> or to cover IETF meeting revenue shortfalls. There may also +O>> +O>> be cases where ISOC chooses to loan money to the IASA to help +O>> with temporary cash flow issues. These cases should be +O>> carefully documented and tracked on both sides. ISOC will +O>> work to provide the 6 month operational reserve for IASA +O>> functioning described above. +O>> +O>> Removability: While there is no current plan to transfer the +O>> legal and financial home of the IASA to another corporation, +O>> the IASA should be structured to enable a clean transition in +O>> the event that the IETF community decides, through BCP +O>> publication, that such a transition is required. In that +O>> case, the IAOC will give ISOC a minimum six months notice +O>> before the transition formally occurs. During that period, +O>> the IAOC and ISOC will work together to create a smooth + + + +Hollenbeck Informational [Page 46] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> transition that does not result in any significant service +O>> outages or missed IETF meetings. All contracts that are +O>> executed by ISOC as part of the IASA should either include a +O>> clause allowing termination or transfer by ISOC with six +O>> months notice, or should be transferrable to another +O>> corporation in the event that the IASA is transitioned away +O>> from ISOC in the future. Any accrued funds, and IETF-specific +O>> intellectual property rights (concerning administrative data +O>> and/ or tools) would also be expected to be transitioned to +O>> any new entity, as well. +O>> +O>> Within the constraints outlined above, all other details of how +O>> to structure this activity within ISOC (as a cost center, a +O>> department or a formal subsidiary) should be determined by ISOC +O>> in consultation with the IAOC. +O>> +O>> 3. Workplan for Formalizing the IETF Administrative Support +O>> Activity +O>> +O>> This section proposes a workplan and schedule for formalizing the +O>> IETF administrative support activity (IASA) for the remainder of +O>> 2004 and 2005. +O>> +O>> 3.1 Workplan Goals +O>> +O>> This workplan is intended to satisfy four goals: +O>> +O>> o Satisfy the IETF's need for support functions through 2005, +O>> with a careful transition that minimizes the risk of +O>> substantial disruption to the IETF standards process. +O>> +O>> o Establish IETF community consensus and ISOC approval of a BCP +O>> formalizing the IASA as described in this scenario before any +O>> actions are taken that will have long term effects (hiring, +O>> +O>> contacts, etc.) +O>> +O>> o Make sure that decisions with long term impact, such as hiring +O>> the IAD and establishing contracts for administrative support, +O>> are made by people chosen for that purpose who will be +O>> responsible to the community for the effectiveness of this +O>> effort (the IAD and members of the IAOC) -- not by our already +O>> overloaded technical leadership. +O>> +O>> o Within the above constraints, move as quickly as possible +O>> towards a well-defined administrative support structure that +O>> is transparent and accountable to the IETF community. +O>> + + + +Hollenbeck Informational [Page 47] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> 3.2 Workplan Overview +O>> +O>> There are three major elements to this workplan which can, to +O>> some degree, take place in parallel after we establish IETF +O>> community consensus to pursue Scenario O: +O>> +O>> o Finalizing the BCP text and getting it approved by the IETF +O>> community and ISOC. +O>> +O>> o Selecting IASA leadership. This includes appointing an +O>> interim IAOC, recruiting the IAD, and eventually appointing +O>> the full IAOC. +O>> +O>> o Negotiating agreements with service providers. This includes +O>> determining the structure and work flow of the IASA, deciding +O>> which portions of the IASA should be staffed via an open +O>> request for proposals (RFP) process, and issuing a RFP for +O>> those portions, as well as establishing sole source contracts +O>> or MOUs for other portions of the IASA. +O>> +O>> Each of the three items listed above is described in more detail +O>> in the following sections. +O>> +O>> 3.3 Approval by the IETF Community and ISOC +O>> +O>> In scenario O, the IASA is formalized in a BCP that is approved +O>> by the IETF community and accepted by the ISOC Board of Trustees. +O>> There are three steps in this process: +O>> +O>> 1. Establishment of IETF community consensus that we should +O>> pursue Scenario O as defined in a joint IAB/IESG +O>> recommendation based on this proposal. This consensus will +O>> be established through community discussion and a formal two- +O>> week consensus call issued by the IETF chair on the IETF +O>> mailing list. +O>> +O>> 2. Establishment of IETF community consensus on a BCP that +O>> formalizes the IASA as described. This consensus would be +O>> established through public discussion, a four week IETF Last +O>> Call and IESG review and approval. +O>> +O>> 3. ISOC approval of the BCP and acceptance of ISOC's +O>> responsibilities as described therein. This approval and +O>> acceptance would be signified by an ISOC Board resolution. +O>> +O>> The timeline for these three stages is rather long, but there is +O>> significant progress that can be made in other areas once we have +O>> established IETF community consensus to pursue this scenario. + + + +Hollenbeck Informational [Page 48] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> +O>> 3.4 Selecting IASA Leadership +O>> +O>> Once we have IETF consensus to pursue this scenario, we can +O>> appoint an interim IAOC to begin working on the IASA transition. +O>> The interim IAOC could do substantial work on non-binding tasks, +O>> such as beginning the recruitment process for an IAD, determining +O>> the structure of the IASA work, issuing RFPs and negotiating +O>> potential agreements with service providers. The interim IAOC +O>> would not be empowered to make binding agreements, but could work +O>> appropriate consultants and advisors to make a lot of progress +O>> towards determining the initial structure and work flow of the +O>> IASA. +O>> +O>> Because the IETF Nominations Commitee (NomCom) process for new +O>> positions will consume a lot of resources and take a long time to +O>> complete, we propose that the interim IAOC consist of: +O>> +O>> o 1 IESG selected member +O>> +O>> o 1 IAB selected member +O>> +O>> o 1 ISOC selected member +O>> +O>> o The IETF Chair +O>> +O>> o The ISOC President/CEO +O>> +O>> The IAB chair will serve as a liaison, as described above. +O>> +O>> The IESG and ISOC Board appointments will be expected to serve +O>> until the first IETF meeting of 2006, and the IAB appointment +O>> will be expected to serve until the first IETF meeting of 2007, +O>> assuming that the BCP is approved and the IAOC continues to have +O>> appointed members from these bodies. +O>> +O>> +O>> After all of the interim IAOC members are selected, they will +O>> choose an interim IAOC chair from among the appointed members. +O>> +O>> When the BCP is approved, if the BCP indicates that there will be +O>> NomCom selected IAOC members they will be chosen at that time. +O>> Any adjustments to appointed members based on the BCP contents +O>> will also be made at that time. The IAOC will transition from +O>> interim to non-interim status when all non-interim members are +O>> seated. A new, non-interim chair selection process will then +O>> commence. +O>> + + + +Hollenbeck Informational [Page 49] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> 3.5 Recruiting the IETF Administrative Director +O>> +O>> The interim IAOC should appoint an IAD selection committee to +O>> recruit and select the IETF Administrative Director. This +O>> committee will consist entirely of IAOC members or liaisons, and +O>> will, at minimum, include the IETF chair and the ISOC President. +O>> If the IAOC chooses, this committee could include the entire +O>> IAOC. +O>> +O>> The IAD selection committee should determine a job description +O>> for the IAD, in consultation with other IETF leaders and the IETF +O>> community. Once the job description is established, the IAD +O>> selection committee should recruiting candidates for the +O>> position. +O>> +O>> Although the interim IAOC is not empowered to hire the IAD as a +O>> full-time employee, it might be possible for the IAOC to ask ISOC +O>> to engage the potential IAD as a consultant to help with other +O>> tasks during the interim period. +O>> +O>> 3.6 Establishing Agreement with Service Providers +O>> +O>> The most important activity of the IAOC during late 2004 and +O>> early 2005 will be to determine the structure and work flow of +O>> the IASA and to establish contracts or other agreements with +O>> service providers to do the required work. This work includes +O>> the following functions as defined in the consultant's report: +O>> +O>> o Technical infrastructure +O>> +O>> o Meeting management +O>> +O>> o Clerk's office +O>> +O>> o RFC Editor services to support IETF standards publication +O>> +O>> o IANA services to support IETF standards publication +O>> +O>> The interim IAOC should work with IETF leaders and other +O>> knowledgeable members of the community to determine the structure +O>> and work flow required for the IASA activity and make +O>> corresponding adjustments to the above list, if necessary. The +O>> interim IAOC can also identify which areas of IASA work should +O>> continue to be provided by existing IETF service providers, and +O>> work with those providers to establish proposed contracts or +O>> agreements for later approval by the non-interim IAOC. The IAOC +O>> can also choose to start an RFP process for any services that +O>> they believe should be filled through an open RFP process. + + + +Hollenbeck Informational [Page 50] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> +O>> 3.7 Establishing a 2005 Operating Budget +O>> +O>> Because the ISOC 2005 budgeting process will be finalized before +O>> the non-interim IAOC is seated, the interim IAOC should work with +O>> the ISOC staff and President to establish a proposed 2005 +O>> operating budget for the IASA. Since this will happen in advance +O>> of full knowledge regarding the costs of 2005 operations, it may +O>> be subject to significant adjustment later. +O>> +O>> 3.8 Proposed Schedule for IASA Transition +O>> +O>> As described above, the three stages of the IETF community and +O>> ISOC approval process will take some time. If the community +O>> chooses scenario O and we reach quick consensus on the details, +O>> an optimistic schedule for this approval would be: +O>> +O>> 1. IETF discussion of this proposal and other scenarios through +O>> 1-Oct-2005. IAB/IESG discusses this proposal with ISOC +O>> Board. +O>> +O>> 2. IAB/IESG joint recommendation issued on 8-Oct-04, including +O>> full BCP proposal. +O>> +O>> 3. Community discussion of the joint IAB/IESG recommendation +O>> through 22-Oct-04. +O>> +O>> 4. Two-week community consensus call issued on the IETF list on +O>> 23-Oct-04 regarding rough community consensus to pursue this +O>> direction and appoint an interim IAOC -- extends through +O>> IETF 61. IAOC selecting bodies begin search, based on +O>> expected community consensus. +O>> +O>> 5. Rough community consensus declared on 8-Nov-04 to pursue +O>> Scenario O and appoint the interim IAOC. +O>> +O>> 6. Interim IAOC seated on 15-Nov-04. Interim IAOC begins +O>> interim work outlined above, including establishment of +O>> +O>> estimated 2005 budget and IAD recruitment. +O>> +O>> 7. BCP text discussed by community, IETF leadership and ISOC +O>> Board until we have something that represents rough +O>> community consensus that is acceptable to all. We hope that +O>> this could be completed by 6-Dec-04. +O>> +O>> 8. Four week IETF Last Call issued for BCP on 6-Dec-04 -- +O>> extends through 3-Jan-04. + + + +Hollenbeck Informational [Page 51] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> +O>> 9. Simultaneous IESG and ISOC Board approvals by 17-Jan-04. +O>> +O>> 10. IAD officially hired in Jan 2005. +O>> +O>> 11. NomCom seats IAOC members at the first IETF of 2005, moving +O>> the IAOC from interim to non-interim status. +O>> +O>> 12. Formal agreements with all service providers in-place by +O>> June 2005. +O>> +O>> 4. Security Considerations +O>> +O>> This document describes a scenario for the structure of the +O>> IETF's administrative support activities. It introduces no +O>> security considerations for the Internet. +O>> +O>> 5. IANA Considerations +O>> +O>> This document has no IANA considerations in the traditional +O>> sense. As part of the extended IETF family, though, IANA may be +O>> interested in the contents. +O>> +O>> 6. Acknowledgements +O>> +O>> Most of the ideas in this document are not new, and many of them +O>> did not originate with the authors. This scenario represents a +O>> combination of ideas discussed within the IAB, the IESG and the +O>> IETF Community. +O>> +O>> This document was written using the xml2rfc tool described in RFC +O>> 2629 [RFC2629]. +O>> +O>> 7. References +O>> +O>> 7.1 Normative References +O>> +O>> [I-D.malamud-consultant-report] Malamud, C., "IETF Administrative +O>> Support Functions", draft-malamud-consultant-report-01 +O>> +O>> (work in progress), September 2004. +O>> +O>> [RFC2026] Bradner, S., "The Internet Standards Process -- +O>> Revision 3", BCP 9, RFC 2026, October 1996. +O>> +O>> [RFC3716] Advisory, IAB., "The IETF in the Large: Administration +O>> and Execution", RFC 3716, March 2004. +O>> + + + +Hollenbeck Informational [Page 52] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +O>> 7.2 Informative References +O>> +O>> [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, +O>> June 1999. +O>> +O>> [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, +O>> RFC 3667, February 2004. +O>> +O>> [RFC3668] Bradner, S., "Intellectual Property Rights in IETF +O>> Technology", BCP 79, RFC 3668, February 2004. +O>> +O>> Authors' Addresses +O>> +O>> Leslie Daigle +O>> VeriSign +O>> EMail: leslie at verisignlabs.com, leslie at thinkingcat.com +O>> +O>> Margaret Wasserman +O>> ThingMagic +O>> One Broadway, 14th Floor +O>> Cambridge, MA 02142 USA +O>> +O>> Phone: +1 617 758-4177 +O>> EMail: margaret at thingmagic.com +O>> URI: http://www.thingmagic.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Informational [Page 53] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +Informative References + + [1] IAB Advisory Committee, "The IETF in the Large: Administration + and Execution", RFC 3716, March 2004. + + [2] Malamud, C., "IETF Administrative Support Functions", + Work in Progress, September 2004. + + [3] <http://www.ietf.org/mail-archive/web/ietf/current/ + msg31321.html> + + [4] <http://www.ietf.org/mail-archive/web/ietf/current/ + msg31326.html> + + [5] <http://www.ietf.org/mail-archive/web/ietf/current/ + msg31493.html> + + [6] <http://www.ietf.org/mail-archive/web/ietf/current/ + msg31609.html> + +Author's Address + + Scott Hollenbeck, Editor + IAB and IESG + + EMail: sah@428cobrajet.net + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Informational [Page 54] + +RFC 4089 IAB-IESG AdminRest Rec May 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Hollenbeck Informational [Page 55] + |