Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
INFORMATIONAL
Network Working Group S. Hollenbeck, Ed.Request for Comments: 4089 IAB and IESGCategory: Informational May 2005IAB and IESG Recommendation for IETF Administrative RestructuringStatus 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 Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .22. The Process That Produced This Recommendation . . . . . . . .23. Recommendation . . . . . . . . . . . . . . . . . . . . . . . .34. Arguments That Had Particular Weight in the Discussions . . .44.1. Focusing on Scenarios C and O . . . . . . . . . . . . .44.2. Why We Chose Scenario O . . . . . . . . . . . . . . . .55. IANA Considerations . . . . . . . . . . . . . . . . . . . . .66. Security Considerations . . . . . . . . . . . . . . . . . . .67. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .6 Appendix: Scenario C . . . . . . . . . . . . . . . . . . . . . . .7 Appendix: Scenario O . . . . . . . . . . . . . . . . . . . . . . .37 Informative References . . . . . . . . . . . . . . . . . . . . . .54Hollenbeck Informational [Page 1]
RFC 4089 IAB-IESG AdminRest Rec May 20051. 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 inRFC 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 (sections4.2 and4.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 Discussions4.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 2005Appendix: 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. WijnenC>> LucentTechnologiesC>> H. AlvestrandC>> Cisco SystemsC>> P. ResnickC>> QUALCOMM IncorporatedC>> September 20, 2004C>>C>> AdminRest Scenario C: An IETF Administrative Support Foundation asC>> an Independent Nonprofit CorporationC>>C>> AbstractC>>C>> This document defines a proposal for an IETF AdministrativeC>> Support Foundation (IASF) as an independent not-for-profitC>> corporation as a means for providing focused support for IETFC>> community activities. It proposes the creation of an IASF BoardC>> of Trustees (BoT) that is mainly selected by and accountable toC>> the IETF community and would provide oversight for the IETFC>> Administrative Support Foundation. The IASF will also establishC>> and maintain a strong relationship with the Internet SocietyC>> (ISOC) and the current relationships between IETF and ISOC willC>> basically be left unchanged.C>>C>> In order to allow the community to properly evaluate thisC>> scenario, some draft Articles of Incorporation and draft BylawsC>> 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 CC>>C>> This document follows from two previous documents. [RFC3716]C>> defined the overall parameters and criteria for an administrativeC>> restructuring. [I-D.malamud-consultant-report] provided anC>> analysis of the implications of several of the suggestedC>> strategies. This document picks one strategy and develops itC>> further.C>>Hollenbeck Informational [Page 7]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> In order to provide the most focused and effective administrativeC>> support to the IETF community, this updated scenario C proposes aC>> new and well-defined legal entity to support the IETFC>> administrative functions. The name of that new entity is "TheC>> IETF Administrative Support Foundation" (IASF).C>>C>> First, it is important to understand that the IETF has beenC>> organized as an Activity of the Internet Society (ISOC) and asC>> such represents the "Standards and Protocols" pillar of ISOC.C>> Under this proposal, the IETF would continue to be an integralC>> part of the Standards and Protocols pillar of ISOC. ISOCC>> currently provides these important functions to the IETF:C>>C>> 1. Standards Process Functions. ISOC plays a fundamental role inC>> the IETF Standards Process, including appointment of theC>> Nominating Committee (Nomcom) chair, confirmation of IABC>> members, confirmation of documents that describe theC>> standards processes, and acting as the last resort in theC>> appeals process. These Standards Process Functions areC>> defined in [RFC2026], [RFC2028], [RFC2031], and [RFC3677].C>>C>> 2. IETF Fund Raising Functions. ISOC provides the fund raisingC>> function as one source for financial support the IETF.C>>C>> 3. Administration Functions. ISOC provides administrative andC>> financial functions, managing the contract with the RFCC>> Editor, providing insurance for selected IETF participants,C>> and administering a discretionary fund for use by the IAB andC>> the IETF Chairs.C>>C>> The administrative restructuring of the IETF proposed in thisC>> document keeps that basic relationship between IETF and ISOC.C>> Specifically, the recommendation does not propose any changes toC>> the "Standards Process Functions" or to the "IETF Fund RaisingC>> Functions".C>>C>> Under the "Administration Functions", ISOC both funds andC>> administers some (as stated above) parts of the IETFC>> Administrative Support Functions. Some of the funds (like forC>> the RFC-Editor) go directly to the contractor who executes theC>> administrative function. The streamlining of the administrativeC>> support for the IETF ultimately intends to put the completeC>> Administrative Support Functions under the newly recommendedC>> IASF. This means that we recommend that ultimately, ISOC fundsC>> for the IETF will be transferred to the IASF, which will thenC>> administer all the contracts and payments according to anHollenbeck Informational [Page 8]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> approved yearly budget. The details of that process will beC>> 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 defineC>> the administrative activity in terms of IETF community needs.C>>C>> o A Board of Trustees with operational oversight that isC>> accountable to the IETF community.C>>C>> o Continued separation between the IETF standards activity andC>> 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 fundsC>> via a yearly budget approval and open reporting of fundsC>> spent.C>>C>> In scenario C, it is intended that the IETF AdministrativeC>> Support Foundation will be a tax-exempt not-for-profitC>> corporation as defined by Articles of Incorporation and a set ofC>> Bylaws. These will describe the scope and purpose of the IASFC>> and they also define the structure and responsibility of theC>> Board of Trustees (BoT), a body that is mainly selected by theC>> IETF and which is responsible for overseeing the IASF. A draftC>> of the Articles of Incorporation and Bylaws is included in theC>> next sections of this document.C>>C>> Scenario C allows us (IETF) to establish IETF control over ourC>> administrative support functions in terms of determining thatC>> they meet the community's needs, and adjusting them from time toC>> time using IETF processes. This is to address the pressingC>> administrative issues outlined in [RFC3716].C>>C>> Scenario C also encourages us (the IETF) to regularly evaluateC>> that we do want to continue the relationships with ISOC and theC>> contracts with our services providers (contractors). It is basedC>> on the premise that we prefer to actively maintain relationshipsC>> with other organizations and service providers instead of beingC>> bound to such relationships based on poorly defined and poorlyHollenbeck Informational [Page 9]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> documented historical facts. A draft BCP for the relationshipC>> between ISOC, IETF and IASF is included as a separate section inC>> this document.C>>C>> Scenario C does however bring the burden of creating a new legalC>> entity (IASF) and such an undertaking is also not without risks.C>> It will need careful planning and execution. Migration from theC>> current structure to this new structure is probably also somewhatC>> more costly and time and labour consuming. The sections belowC>> try to show how that would be achieved and outlines what furtherC>> steps are needed to provide more detail if this scenario isC>> chosen.C>>C>> 2. Work Plan for the IETF Administrative Support FoundationC>>C>> This section gives the work plan for the IETF AdministrativeC>> Support Foundation (IASF) for the remainder of 2004 and the yearC>> 2005.C>>C>> 2.1 Workplan goalsC>>C>> The work plan below is intended to satisfy three goals:C>>C>> o Satisfy the IETF's need for support functions in 2005C>>C>> o Operate with a positive account balance throughout 2005C>>C>> o Start building up a fund inside the IASF to serve as a bufferC>> against budgetary emergencies in later years (such as meetingsC>> with a severe cost overrun, or force-majeure cancellations).C>>C>> The fund target is 6 months of operating revenue, and the targetC>> for building up the fund is 3 years. The budgeted set-aside forC>> the fund should thus be approximately 17% of operating revenue.C>>C>> 2.2 Incorporation processC>>C>> There are 3 things that need to be in place before thatC>> corporation can be considered viable at all:C>>C>> o IETF consensus on the planC>>C>> o ISOC agreement on a reasonable support contractC>>C>> o Assurance that the corporation will have tax-exempt statusC>>Hollenbeck Informational [Page 10]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> Once this document has been discussed in the IETF, and the IESGC>> and IAB gauges that rough consensus seems reached, the IETFC>> leadership will take the following actions:C>>C>> o Publish a Last Call on this document (to determine planC>> consensus).C>>C>> o Choose a negotiating team to negotiate the ISOC contract.C>>C>> o Choose an executive search team to find the IASFC>> Administrative Director (IAD).C>>C>> o Consult with legal counsel to determine how best to achieveC>> tax-exempt status; this will affect the bylaws and articles ofC>> incorporation.C>>C>> When the Last Call is over, the IESG will consider whether thereC>> is still consensus, and if there is, approve this document forC>> publication. Once that happens, it will take the followingC>> steps:C>>C>> o As soon as negotiations conclude, publish a Last Call on theC>> ISOC contract.C>>C>> o As soon as drafting of legal documents is completed, publish aC>> Last Call on the Bylaws and Articles of Incorporation, and askC>> the Nomcom to start the process of selecting Nomcom-selectedC>> board representatives.C>>C>>C>> These Last Calls are "speak now" Last Calls - if someone wishesC>> to challenge the IETF consensus to go ahead with these actions,C>> knowing what the formal documents will look like, this is theirC>> last chance.C>>C>> When these Last Calls are over, the IETF chair, the IAB chair andC>> the ISOC President will jointly file the articles ofC>> incorporation, and the IESG, IAB and ISOC will fill their boardC>> seats.C>>C>> Note: This document does not say when a Request for InformationC>> (RFI) for IETF support services such as meeting planning is sentC>> out. Advice is sought on the earliest point where this can beC>> done.C>>Hollenbeck Informational [Page 11]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 2.3 Contract establishmentC>>C>> The most important activity for late 2004/early 2005 is toC>> finalize contracts for the support of the IETF. This includes:C>>C>> o FundingC>>C>> o Technical infrastructureC>>C>> o Meeting managementC>>C>> o Clerk's officeC>>C>> o RFC EditorC>>C>> o IANAC>>C>> There appears to be consensus in the IETF community that theseC>> functions, whether they are offered for free, remunerated orC>> arranged for other consideration, should be under contract.C>>C>> The contract for funding is expected to be with ISOC, and shouldC>> be finalized before IASF is established.C>>C>> The contract for technical infrastructure is expected to be anC>> RFP, published in November of 2004, with responses beingC>> evaluated in December 2004, and services rendered from a mutuallyC>> agreed date early in 2005.C>>C>> The contract for meeting management will be influenced by theC>> need to have stable agreements for the 2005 meetings at an earlyC>> date. This indicates that IASF will honor a pre-IASF agreementC>> to have these meeting contracts signed by Foretec (if that can beC>> achieved).C>>C>> It is not clear how the contract for the clerk's office is to beC>> managed at the time of this writing.C>>C>> The contract for the RFC Editor is expected to be with ISI, andC>> is expected to be a continuation of the current contract withC>> ISOC, which runs until the end of 2005.C>>C>> The contract with IANA will replace or augment the current MoUC>> between the IETF and ICANN. In its simplest form, it wouldC>> simply be a reconfirmation of the duties of ICANN under the MoU.C>>Hollenbeck Informational [Page 12]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 2.4 Performance evaluationC>>C>> The second task of the IASF is to make sure the IETF gets theC>> support it needs. The IASF will work together with the IETFC>> community to make an effort to identify whether or not the IETF'sC>> needs are being met, and to coordinate improvements with theC>> contractors. This is an ongoing activity.C>>C>> 2.5 Budgeting for 2006C>>C>> In June 2005, the IASF will start the yearly budgeting processC>> with ISOC, as specified in the ISOC contract, leading to a workC>> plan and budget for 2006.C>>C>> 2.6 ReportingC>>C>> The IASF will present monthly updates on its economic status.C>> These will be delivered to ISOC as part of the ISOC contract, andC>> also be made publicly available so that the IETF community canC>> inspect them.C>>C>> 3. Details of the IETF Administrative Support FoundationC>>C>> This section contains details about the proposal to change howC>> the day-to-day IETF administrative support functions areC>> provided. This recommendation is based on the initialC>> description of "Scenario C" in the "Administrative SupportC>> Analysis" [I-D.malamud-consultant-report] provided by CarlC>> Malamud. It is further based on discussion in the IESG and IABC>> and on feedback on Carl's document as received on the IETFC>> mailing list. Further justifications, reasoning and motivationsC>> are given inAppendix A. Risk Analysis is done inAppendix C.C>>C>> This document recommends to create a well defined and legalC>> entity called "The IETF Administrative Support Foundation"C>>C>> (IASF). The name intends to clearly express that this new legalC>> entity has only one single function, namely to provide theC>> administrative support of the IETF Standardization and ProtocolC>> Development activities. This entity will ultimately manage andC>> administer all the administrative functions that are needed toC>> support the IETF - the Standardization and Protocol DevelopmentC>> activity of ISOC.C>>Hollenbeck Informational [Page 13]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 3.1 Organizational Form and Legal DomicileC>>C>> The consultant report [I-D.malamud-consultant-report] contains aC>> writeup on various choices in terms of how and where toC>> incorporate. This recommendation has made the choice toC>> incorporate in the US in the state of Virginia. Some detail canC>> be found inAppendix B.C>>C>> In this scenario, administrative support functions for the IETFC>> are legally housed in a focused, incorporated institutionC>> (although the Administrative Director might be physically housedC>> within the Internet Society).C>>C>> This scenario defines a number of concrete linkages with theC>> Internet Society, which supplement the current closeC>> interconnection of the IETF community with ISOC. TheC>> relationship is to be documented in a MoU (initial text is inC>>Section 4).C>>C>> 3.2 Draft Core PrinciplesC>>C>> 3.2.1 Principles of Establishment and GovernanceC>>C>> The following principles are to be respected for theC>> establishment and governance of the IETF Administrative SupportC>> Foundation (IASF) and are the basis for the Draft Articles ofC>> Incorporation as inSection 6.1 and the Draft Bylaws as inC>>Section 6.2:C>>C>> 1. The IASF shall be governed by a Board of Trustees (BoT), whoC>> shall be responsible for the fiscal, legal, andC>> administrative infrastructure that supports the activities ofC>> the IETF.C>>C>> 2. The governance of the IETF, the standards process, and allC>> other aspects of how we make our standards are defined in theC>> procedural Best Current Practice (BCP) RFC series, which willC>> be explicitly referenced in the organization documents of theC>> 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 needC>> not be members of the BoT. The IETF Administrative DirectorC>> (IAD) of the IASF shall provide staff support to the BoT.C>>Hollenbeck Informational [Page 14]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 5. The BoT shall be composed to strike a balance betweenC>> "outside" and "inside" directors. The IESG and IAB will eachC>> select a representative to serve as a voting member of theC>> BoT. Mechanisms such as the Nominating Committee (Nomcom) andC>> the appointment of certain seats by the ISOC fulfill theC>> outside director obligations.C>>C>> 6. IAB, IESG and ISOC will have liaisons to the BoT in order toC>> have a good basis for interaction.C>>C>> The BoT will have strong governance over a limited scope ofC>> activities (e.g., the fiscal, legal, and administrativeC>> infrastructure that are the charter of the IASF) but will have noC>> authority over the IETF standards process. In this boardC>> composition, the ISOC and Nomcom appointments ensure that outsideC>> directors with no perceived conflicts of interest are on theC>> board.C>>C>> All nominating bodies should make strong fiscal, legal, andC>> administrative acumen essential selection criteria for thisC>> position.C>>C>> IAB and IESG representatives will serve for one year. For otherC>> appointments, a term proposed for the nominated positions isC>> three years with staggered appointments. However, the nominatingC>> body might have the power to change their appointee during theirC>> term.C>>C>> All members of the BoT selected by the IETF are subject to theC>> same recall procedures in effect for the IETF leadership such asC>> members of the IAB and IESG.C>>C>> 3.2.2 Principles of Operation of the IETF Administrative SupportC>> FoundationC>>C>> The following are general principles for the operation of theC>> 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 adviceC>> and consent of the IESG and IAB.C>>C>> 2. All support services shall be contracted in an open andC>> transparent manner.C>>Hollenbeck Informational [Page 15]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 3. The IAD shall submit a proposed annual budget to the BoT atC>> least 90 days before the beginning of the fiscal year. SuchC>> budget shall be developed with the advice and consent of theC>> IAB and IESG.C>>C>> 4. The IAD shall serve on the BoT as a non-voting, ex-officioC>> member.C>>C>> 5. The BoT shall select a professional audit firm and shallC>> commission an audit immediately upon the close of each fiscalC>> year.C>>C>> 6. The IASF will conduct financial reporting in a fullyC>> transparent fashion. Audits shall be conducted promptly andC>> published. Tax returns shall be published. DetailedC>> financial statements will be published on a regular basis,C>> including timely reports on the financial results of IETFC>> meetings.C>>C>> 4. Draft MoU between ISOC, IETF and IETF Administrative SupportC>> FoundationC>>C>> 4.1 Form and Scope of the AgreementC>>C>> This section presents some principles to be incorporated in aC>> draft MoU/Contract between the Internet Society (ISOC) and theC>> IETF Administrative Support Foundation (IASF), detailing the workC>> each is expected to perform, the responsibilities each has, andC>> the means by which these functions are accomplished. ThisC>> MoU/Contract shall be published as an RFC.C>>C>> The MoU/Contract will specify the responsibilities of theC>> Internet Society, including:C>>C>> o Reaffirmation of the Standards Process Function that ISOCC>> 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 solicitC>> corporate, individual, and other organizational donations forC>> funding of the 3 Pillars.C>>C>> o Disbursement of funds to the IASF according to the agreed-uponC>> budgets and processes as specified in this agreement.C>>C>> o Verification that IASF spends these funds to support the workC>> of the IETF, within the scope described in the IASF bylaws.C>>Hollenbeck Informational [Page 16]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> Responsibilities of IASF:C>>C>> o Determine, in cooperation with the IETF, the support functionsC>> that are needed for the IETF, and can be achieved withinC>> available funds.C>>C>> o Enter into contracts for these support functions.C>>C>> o Supervise these contracts and ensure that they are beingC>> performed in the best interest of the IETF, within aC>> reasonable budget and with agreed-upon performance.C>>C>> 4.2 Cooperation mechanismC>>C>> IASF and ISOC agree that they will perform a budgeting procedureC>> each year, comprising the following steps:C>>C>> o IASF puts together a budget proposal to ISOC, and presents itC>> in June. This will specify the functions that need to beC>> performed, the cost of each, the expected revenue from IETFC>> meeting participation, and how much is being requested forC>> ISOC to contribute.C>>C>> o By the end of August, ISOC will give a budget number to IASFC>> that says how much ISOC is willing to contribute to supportC>> the functions described in the IASF budget.C>>C>> o Before November 1, ISOC and IASF will agree on a budget, anC>> ISOC contribution, and a disbursement schedule.C>>C>> o If either party sees that there is reason to change theC>> budget, they can start a negotiation to do so at any time. OnC>> mutual agreement to a change, payments are modifiedC>> accordingly.C>>C>> o ISOC may withhold funds if IASF fails to account for itsC>> expenditures, if it determines that IASF has departedC>> significantly from its budgeted expenditures without agreementC>> with ISOC to do so, or if ISOC determines that IASF isC>> spending funds in violation of its bylaws.C>>Hollenbeck Informational [Page 17]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 4.3 Promises Not to Do ThingsC>>C>> This section lays out things that would constitute interferenceC>> 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 toC>> influence IASF choice of contractors or choice of meetingC>> sponsors. This restriction is meant to enforce the separationC>> between fund raising and the actual operation of the standardsC>> process.C>>C>> IASF will not ask companies for money. IASF may ask for sponsorsC>> for IETF events, per tradition, and may accept zero-cost providerC>> contracts or in-kind donations, but ISOC is the organizationC>> charged with fundraising.C>>C>> Neither ISOC nor IASF will attempt to influence technicalC>> decisions of the IETF standards process.C>>C>> 4.4 Initial contributionC>>C>> The Internet Society has already allocated $700,000 in transitionC>> funds. As part of the formation process, this section sets out aC>> way that a 2005 allocation of funds and an initial contributionC>> 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 putC>> together a detailed 2005 budget, including an analysis of cashC>> flow and balance sheets to make sure that the organization isC>> properly funded and will be solvent throughout the year. ThisC>> planning process should project out 3 years and show how theC>> organization will be able to accumulate the appropriate cashC>> reserve to make sure operations can continue in a stable manner.C>>C>> An initial estimate is for an on-going annual contribution of USDC>> 900.000 to IASF in 2005. In addition, ISOC will contribute anC>> additional USD 600.000 as an initial fund to start up IASF,C>> payable after the Board of Trustees is seated and this contractC>> is signed and approved by the IETF.C>>C>> ISOC commits to this ongoing level of contribution (USD 75.000C>> per month) for the lifetime of this contract, unless modified byC>> mutual agreement.C>>Hollenbeck Informational [Page 18]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 4.5 Termination, law and so onC>>C>> This agreement may be terminated by either party for any reasonC>> on 12 months' notice.C>>C>> The parties may reach mutual agreement on a shorter terminationC>> period.C>>C>> All conflicts under this agreement are to be adjudicated underC>> the laws of the United States and the State of Virginia, howeverC>> the parties may also agree to arbitration, mediation or any otherC>> conflict resolution mechanisms.C>>C>> 5. Notes and ExplanationsC>>C>> This is where we put down why things are the way they are.C>>C>> 5.1 Type of legal instrumentC>>C>> This document is styled as a contract - an agreement between twoC>> parties, enforceable under law. An alternate formulation wouldC>> be a Memorandum of Understanding - but we want it to be clear toC>> everyone that the parties stand behind their responsibilitiesC>> under this document. At the moment, the authors see noC>> compelling arguments for not making it a contract. In eitherC>> case, the document is published as an RFC.C>>C>> 5.2 Power BalanceC>>C>> As written, it is designed to make it easy to do the right thingC>> as long as the parties agree what that is, to make it clear thatC>> ISOC will continue to pay money as long as IASF does the RightC>> Thing (and reports what it's doing), and that ISOC can stop theC>> show quickly if it's clear that IASF is not doing the RightC>> Thing.C>>C>> 5.3 Budget figuresC>>C>> The main purpose of the numbers is to make it clear that thereC>> WILL be numbers in this contract, and that it WILL represent aC>> solid commitment by ISOC. The numbers are "subject to changeC>> without notice" while this contract is negotiated.C>>Hollenbeck Informational [Page 19]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 6. Draft Incorporating Documents for the IETF AdministrativeC>> Support FoundationC>>C>> 6.1 Draft Articles of IncorporationC>>C>> This section contains standard, pro-forma Articles ofC>> Incorporation. Note well that tax lawyers often make significantC>> alterations to standard Articles as they consider a 501(c)(3)C>> application. They are included here merely as a sample forC>> 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 CodeC>> of Virginia, [Virginia] state(s) as follows:C>>C>> 1. The name of the corporation is The IETF AdministrativeC>> Support Foundation.C>>C>> 2. The corporation shall have no members.C>>C>> 3. The purpose of the corporation is to manage and administerC>> all the administrative functions for the IETF - theC>> Standardization and Protocol Development activity of theC>> Internet Society.C>>C>> 4. The Trustees of the corporation shall be elected or appointedC>> 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 agentC>> is: XXXC>>C>> B. The initial registered agent is a domestic or foreignC>> stock or nonstock corporation, limited liability company,C>> or registered limited liability partnership authorized toC>> transact business in Virginia.C>>C>> 6. The initial Trustees are: XXXC>>C>> 7. The incorporators are: XXXC>>Hollenbeck Informational [Page 20]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 6.2 Draft Bylaws of the IETF Administrative Support FoundationC>>C>> As with the Draft Articles, the Draft Bylaws included here are aC>> pro-forma, standard version. Substantial alteration may beC>> required as legal counsel reviews the specific nature of anC>> incorporation.C>>C>> 6.2.1 Article I: OrganizationC>>C>> The name of the Corporation shall be The IETF AdministrativeC>> Support Foundation (which is hereinafter also referred to as theC>> "IASF").C>>C>> 6.2.2 Article II: PurposeC>>C>> *Section 1: Purpose.* The IASF shall be operated exclusively forC>> nonprofit educational, charitable, and scientific purposes,C>> including, without limitation, the purposes stated in the IASF'sC>> Articles of Incorporation.C>>C>> *Section 2: Restrictions.* No part of the net earnings of theC>> IASF shall inure to the benefit of, or be distributable to,C>> private persons, except that the IASF shall be authorized andC>> empowered to pay reasonable compensation for services rendered,C>> and to make payments and distributions in furtherance of theC>> purposes set forth in Article II,Section 1 hereof. Any otherC>> provision of these Bylaws to the contrary notwithstanding, theC>> IASF shall not carry on any activities not permitted to beC>> carried on by a corporation exempt from Federal Income Tax underC>>Section 501(a) andSection 501(c)(3) of the Code. These BylawsC>> shall not be altered or amended in derogation of the provisionsC>> of this Section.C>>C>> 6.2.3 Article III: MembersC>>C>> The IASF shall have no members and no stockholders.C>>C>> 6.2.4 Article IV: OfficesC>>C>> The office of the IASF shall be as determined from time to timeC>> by the Board of Trustees (BoT) within or outside of the State ofC>> Virginia.C>>C>> 6.2.5 Article V: Board of TrusteesC>>C>> *Section 1: Authority and Responsibilities.* The power,C>> authority, property, and affairs of the IASF shall at all timesC>> be exclusively exercised, controlled, and conducted by or underHollenbeck Informational [Page 21]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> the authority of the Board of Trustees (BoT) subject to anyC>> limitations set forth in the Articles of Incorporation and inC>> accordance with the Virginia Nonstock Corporation Act as it nowC>> exists or hereafter may be amended.C>>C>> *Section 2: Board of Trustees Composition.* The Board of TrusteesC>> 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 theC>> IAB and IESG respectively to the Board of Trustees. The chairC>> and president of the Internet Society will function as liaisonsC>> from the ISOC to the Board of Trustees.C>>C>> *Section 3: Terms.* The term of office of IESG and IAB SelectedC>> Trustees shall be one (1) year or until their successors haveC>> been selected and assume office. The term of office of otherwiseC>> Selected Trustees shall be three (3) years or until theirC>> successors have been selected and assume office. SelectedC>> 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 andC>> IAB shall each select one representative Trustee, who is notC>> at the same time an IESG or IAB member.C>>C>> 2. *Selection of otherwise Selected Trustees.* Three (3) IETFC>> Selected Trustees shall be selected by the IETF nominationsC>> process (as defined in [RFC3777] or its successor) andC>> confirmed by the IESG. Two ISOC Selected Trustees shall beC>> selected by the Internet Society using means of their ownC>> choosing.C>>C>> 3. *Resignation.* A Selected Trustee may resign by deliveringC>> his resignation in writing to the IASF at its principalC>> office or to the Secretary of the IASF. Such resignationC>> shall be effective upon its receipt or upon such date (ifC>> any) as is stated in such resignation, unless otherwiseC>> determined by the Board.C>>Hollenbeck Informational [Page 22]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 4. *Removal.* A Selected Trustee selected by the IETFC>> nominations process may be removed from office at any timeC>> using the procedures specified in [RFC3777] or its successor.C>> A Selected Trustee selected by the Internet Society may beC>> removed by the Internet Society using means of their ownC>> choosing.C>>C>> 5. *Vacancies.* Any vacancy in the Board of Trustees shall beC>> filled using the procedures set forth above on theC>> composition of the Board of Trustees. The Trustees shallC>> have and may exercise all of their powers notwithstanding theC>> existence of one or more vacancies in their number.C>>C>> *Section 5: Quorum.* A majority (i.e. fifty (50) percent plusC>> one (1)) of the Trustees shall constitute a quorum for theC>> transaction of business. Unless otherwise stated in theseC>>C>> Bylaws, decisions of the Board of Trustees shall be made by theC>> concurrence of a majority of members of the Board of TrusteesC>> present and voting. If at any meeting there is no quorumC>> present, the Board must not transact business.C>>C>> *Section 6: Compensation and Reimbursement.* No member of theC>> Board of Trustees may receive compensation for his or herC>> services as a Trustee. A Trustee shall, at their request, beC>> reimbursed for actual, necessary and reasonable travel andC>> subsistence expenses incurred by them in performance of theirC>> duties.C>>C>> *Section 7: Meetings.* The Board of Trustees shall meet at leastC>> twice annually.C>>C>> 1. *Written notice, waiver, action.* Wherever the text belowC>> speaks of "written" it is also permitted to use e-mail.C>>C>> 2. *Annual Meeting.* The Board of Trustees shall hold a publicC>> Annual Meeting at a time and place associated with the firstC>> IETF meeting each year. This Annual meeting shall be open toC>> all IETF attendees except that the parts of the meetingC>> dealing with personnel issues may be held in executiveC>> session.C>>C>> 3. *Meeting Types, Methods, and Notice.* Meetings of the BoardC>> may be held from time to time at such intervals and at suchC>> places as may be fixed by the Board. Meetings of the BoardC>> may be held only in person or via teleconference. Notice ofC>> all regular meetings of the Board shall be delivered to eachC>> Trustee by e-mail or by postal mail and announced on theHollenbeck Informational [Page 23]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> IETF-Announce list at least ten (10) calendar days before theC>> meeting. Special meetings of the Board may be called for anyC>> purpose at any time by the Chairman of the Board or by anyC>> three (3) Trustees. Notice of any special meeting shall stateC>> the purpose of the meeting. A Trustee may waive notice of aC>> 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 meetingC>> waives any required notice of the meeting unless at the startC>> of such meeting or promptly upon arrival the Trustee objectsC>> to holding the meeting or transacting business at theC>> meeting, and does not thereafter vote for or assent to actionC>> taken at the meeting.C>>C>> 4. *Actions Taken By the Board of Trustees Without Meeting.* AnyC>> action required or permitted to be taken at any meeting ofC>> the Board of Trustees may be taken without a meeting if allC>>C>> Trustees consent in writing to such action. Such actionC>> shall be evidenced by written consents approving the lack ofC>> a meeting, signed by each Trustee.C>>C>> *Section 8: Board Committees.* The Trustees may elect or appointC>> one or more committees (including but not limited to an ExecutiveC>> Committee) and may delegate to any such committee or committeesC>> any or all of their powers, provided that any committee to whichC>> the powers of the Trustees are delegated shall consist solely ofC>> Trustees. Committees shall conduct their affairs in the sameC>> manner as is provided in these By Laws for the Trustees. TheC>> members of any committee shall remain in office at the pleasureC>> of the Board of Trustees.C>>C>> *Section 9: Trustee Member Conflict of Interest.*C>>C>> 1. As set forth inSection 9(3) below, a Trustee of the IETFC>> Administrative Support Foundation (IASF) who has a personalC>> interest in a transaction, as defined below, may notC>> participate in any discussion of that transaction by theC>> Trustees of The IASF and may not vote to determine whether toC>> authorize, approve, or ratify that transaction except asC>> specifically described below. For purposes of these Bylaws, aC>> "personal interest" is defined as any act that will provide,C>> directly or indirectly, a financial benefit or a disparateC>> benefit individually to the Trustee, or to a company he orC>> she is employed by, has a significant financial interest in,C>> or represents in any fashion. However, policies underC>> consideration by the IASF are likely to have an impact on theC>> business of every Trustee. It is expected that most policyHollenbeck Informational [Page 24]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> decisions will have a direct or indirect impact on theC>> Trustee's company, but such a non-individualized interestC>> does not constitute a "personal interest" as used in theseC>> Bylaws. A "transaction" with The IASF for purposes of theseC>> Bylaws is a contract or consultancy in which the Trustee hasC>> a direct or indirect financial benefit, or a policy underC>> consideration that will have a disparate and unusual impactC>> on a business with which the Trustee is directly orC>> indirectly associated.C>>C>> 2. The mere existence of a personal interest by a Trustee of TheC>> IASF in a transaction with the IASF shall not invalidate theC>> IASF's ability to enter that transaction so long as theC>> following conditions are met: (i) the material facts of theC>> personal nature of the transaction with The IASF and theC>> Trustee's interest in the transaction with the IASF are fullyC>> disclosed to the Board of Trustees of the IASF, either by theC>> Trustee having a direct or indirect personal interest in theC>>C>> transaction with the IASF, or are brought to the attention ofC>> the Board by a third party; or (ii) the BoT of the IASF, by aC>> vote of the Trustees (without a conflict of interest) of theC>> IASF vote to authorize, approve, or ratify a transaction withC>> the IASF; or (iii) the transaction with the IASF in which theC>> direct or indirect personal interest of a IASF Trustee wasC>> disclosed to the BoT of The IASF and was determined by theC>> BoT of the IASF entitled to vote on the matter is determinedC>> by the BoT voting to be in the IASF's interests,C>> notwithstanding the personal interest of the non-votingC>> Trustee.C>>C>> 3. In determining whether a conflict of interest exists, the BoTC>> of the IASF has the prerogative, upon review of all facts andC>> circumstances, to make its own determination of whether aC>> conflict of interest exists and how it is appropriate toC>> proceed. A Trustee who perceives the possibility of aC>> conflict of interest for him or herself, or for another BoardC>> member, may raise this issue at any point prior to a vote onC>> any issue. Any Trustee who perceives a possible conflict ofC>> interest may present justification with respect to whether orC>> not a conflict of interest exists, but the entire Board, withC>> the exception of the Trustee having the potential conflict ofC>> interest, shall make the final determination to proceed inC>> such a matter. If the BoT finds there is a conflict ofC>> interest, the Trustee with the conflict may be excluded byC>> the Chair of the Board from that portion of any meeting whereC>> a substantive discussion or decision to engage or not in suchHollenbeck Informational [Page 25]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> a transaction is made, except that he or she may provide anyC>> information that will assist the Trustees in such a matterC>> before leaving such a meeting.C>>C>> *Section 10. Approval of Meeting Minutes.* Minutes of the BoT ofC>> the IASF must be approved by a procedure adopted by the board andC>> published on the IASF web site.C>>C>> 6.2.6 Article VI: OfficersC>>C>> *Section 1: Number.* The officers of the IASF shall consist of aC>> Chairman of the Board, a Treasurer and a Secretary, and suchC>> other inferior officers as the BoT may determine.C>>C>> *Section 2: Election Term of Office and Qualifications.* AllC>> officers shall be elected annually by the vote of a majority ofC>> the Board of Trustees present and voting (excluding abstentions)C>> at the Annual Meeting. The Treasurer and Secretary need not beC>> members of the Board. The Chair of the IETF nor the chair of theC>> IAB shall be the Chairman of the Board of the IASF.C>>C>> *Section 3: Resignation.* An officer may resign by delivering hisC>> written resignation to the IASF at its principal office or to theC>> Chair or Secretary. Such resignation shall be effective uponC>> receipt or upon such date (if any) as is stated in suchC>> resignation, unless otherwise determined by the Board.C>>C>> *Section 4: Removal.* The BoT may remove any officer with orC>> without cause by a vote of a majority of the entire number ofC>> Trustees then in office, at a meeting of the BoT called for thatC>> purpose. An officer may be removed for cause only if notice ofC>> such action shall have been given to all of the Trustees prior toC>> the meeting at which such action is to be taken and if theC>> officer so to be removed shall have been given reasonable noticeC>> and opportunity to be heard by the BoT.C>>C>> *Section 5: Vacancies.* In case any elected officer position ofC>> the IASF becomes vacant, the majority of the Trustees in office,C>> although less than a quorum, may elect an officer to fill suchC>> vacancy at the next meeting of the BoT, and the officer soC>> elected shall hold office and serve until the next AnnualC>> Meeting.C>>C>> *Section 6: Chairman of the Board.* The Chairman of the BoardC>> shall, when present, preside at all meetings of the BoT of theC>> IASF. If the Chairman is not available to preside over aC>> meeting, the majority of the Trustees present shall selectC>> another Trustee to preside at that meeting only.Hollenbeck Informational [Page 26]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>>C>> *Section 7: Treasurer.* The Treasurer shall have the custody ofC>> all funds, property, and securities of the IASF, subject to suchC>> regulations as may be imposed by the Board of Trustees. He orC>> she may be required to give bond for the faithful performance ofC>> his or her duties, in such sum and with such sureties as the BoTC>> may require or as required by law, whichever is greater. WhenC>> necessary or proper, he or she may endorse on behalf of the IASFC>> for collection, checks, notes and other obligations, and shallC>> deposit same to the credit of the IASF at such bank or banks orC>> depository as the BoT may designate. He or she shall make orC>> cause to be made such payments as may be necessary or proper toC>> be made on behalf of the IASF. He or she shall enter or cause toC>> be entered regularly on the books of the IASF to be kept by himC>> or her for that purpose, full and accurate account of all moniesC>> and obligations received and paid or incurred by him or her forC>> or on account of the IASF, and shall exhibit such books at allC>> reasonable times to any Trustee on application at the offices ofC>> the IASF incident to the Office of Treasurer, subject to theC>> control of the BoT. Certain duties of the Treasurer as may beC>> specified by the BoT may be delegated by the Treasurer.C>>C>> *Section 8: Secretary.* The Secretary shall have charge of suchC>> books, records, documents, and papers as the BoT may determine,C>> and shall have custody of the corporate seal. The SecretaryC>> shall keep, or cause to be kept the minutes of all meetings ofC>> the BoT. The Secretary may sign, with the Chairman, in the nameC>> and on behalf of the IASF, any contracts or agreements, and he orC>> she may affix the corporate seal of the IASF. He or she, inC>> general, performs all the duties incident to the Office ofC>> Secretary, subject to the supervision and control of the Board ofC>> Trustees, and shall do and perform such other duties as may beC>> 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 BoTC>> may be delegated by the Secretary.C>>C>> *Section 9: Other Powers and Duties.* Each officer shall have inC>> addition to the duties and powers specifically set forth in theseC>> By Laws, such duties and powers as are customarily incident toC>> his office, and such duties and powers as the Trustees may fromC>> time to time designate.C>>Hollenbeck Informational [Page 27]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 6.2.7 Article VII: AmendmentsC>>C>> *Section 1: By Laws.* These By Laws may be amended by anC>> affirmative vote of a majority of the Trustees then in officeC>> (excluding abstentions) at a regular meeting of the board or aC>> meeting of the board called for that purpose as long as theC>> proposed changes are made available to all trustees and posted toC>> the IETF Announce list at least 30 days before any such meeting.C>>C>> *Section 2: Articles of Incorporation.* The Articles ofC>> Incorporation of the IASF may be amended by an affirmative voteC>> of two-thirds of the BoT then in office at a regular meeting ofC>> the board or a meeting of the board called for that purpose asC>> long as the proposed changes are made available to all trusteesC>> and posted to the IETF Announce list at least 30 days before anyC>> such meeting.C>>C>> 6.2.8 Article VIII: DissolutionC>>C>> Upon the dissolution of the IASF, the IASF, after paying orC>> making provisions for the payment of all of the liabilities ofC>> the IASF, dispose of all of the assets of the IASF exclusivelyC>> for the exempt purposes of the IASF in such manner or to suchC>> organization or organizations operated exclusively for socialC>> welfare or charitable purposes. Any such assets not so disposedC>> of shall be disposed of by a court of competent jurisdiction ofC>> the county in which the principal office of the organization isC>> then located, exclusively for such purposes. In the event of aC>>C>> sale or dissolution of the corporation, the surplus funds of theC>> corporation shall not inure to the benefit of, or beC>> distributable to, its Trustees, officers, or other privateC>> persons.C>>C>> 6.2.9 Article IX: Miscellaneous ProvisionsC>>C>> *Section 1: Fiscal Year.* The fiscal year of the IASF shall beC>> 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 obligationsC>> authorized to be executed by an officer of the IASF in its behalfC>> shall be signed by the Chairman of the Board or the Treasurer, orC>> as the Trustees otherwise determine. A certificate by theC>> Secretary as to any action taken by the BoT shall as to allC>> persons who rely thereon in good faith be conclusive evidence ofC>> such action.C>>Hollenbeck Informational [Page 28]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> *Section 3: Severability.* Any determination that any provisionC>> of these By-Laws is for any reason inapplicable, illegal orC>> ineffective shall not affect or invalidate any other provision ofC>> these By-Laws.C>>C>> *Section 4: Articles of Incorporation.* All references in theseC>> By Laws to the Articles of Incorporation shall be deemed to referC>> to the Articles of Incorporation of the IASF, as amended and inC>> effect from time to time.C>>C>> *Section 5: Gender.* Whenever used herein, the singular numberC>> 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) toC>> the Internal Revenue Code shall be deemed to refer to theC>> Internal Revenue Code of 1986, as now in force or hereafterC>> amended; (2) to the Code of the State of Virginia, or any ChapterC>> thereof, shall be deemed to refer to such Code or Chapter as nowC>> in force or hereafter amended; (3) the particular sections of theC>> Internal Revenue Code or such Code shall be deemed to refer toC>> similar or successor provisions hereafter adopted; and (4) to theC>> Request for Comment Series shall be deemed to refer to theC>> Request for Comment Series as they are now in force or hereafterC>> amended.C>>C>> 7. Acknowledgment of Contributions and ReviewsC>>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. CarlC>> Malamud also reviewed this document and helped with making theC>> text better English and easier to read.C>>C>> This document was created with "xml2rfc"C>> <http://xml.resource.org/> using the format specifiedC>> in [RFC2629].C>>C>> 8. IANA ConsiderationsC>>C>> This documents requires no action from IANA.C>>Hollenbeck Informational [Page 29]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> 9. Security ConsiderationsC>>C>> This document describes a scenario for the structure of theC>> IETF's administrative support activities. It introduces noC>> security considerations for the Internet.C>>C>> Safety considerations for the integrity of the standards processC>> are outlined inAppendix C.C>>C>> 10. ReferencesC>>C>> 10.1 Normative ReferencesC>>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 InvolvedC>> 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 ISOCC>> Board of Trustee Appointment Procedures",BCP 77, RFCC>> 3677, December 2003.C>>C>> [RFC3716] Advisory, IAB., "The IETF in the Large: AdministrationC>> and Execution",RFC 3716, March 2004.C>>C>> [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, andC>> Recall Process: Operation of the Nominating and RecallC>> Committees",BCP 10,RFC 3777, June 2004.C>>C>> [Virginia] State of Virginia, "Title 13.1: Corporations, LimitedC>> 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 ReferencesC>>C>> [I-D.ietf-xmpp-core] Saint-Andre, P., "Extensible Messaging andC>> 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 2005C>> [I-D.malamud-consultant-report] Malamud, C., "IETF AdministrativeC>> Support Functions",draft-malamud-consultant-report-01C>> (work in progress), September 2004.C>>C>> [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML",RFC 2629,C>> June 1999.C>>C>> URIsC>>C>> [1] <http://www.state.va.us/cgi-bin/scc-C>> clerkdl.pl?scc819&Articles_of_Incorporation_-_Nonstock_CorpoC>> ration>C>>C>> Authors' AddressesC>>C>> Bert WijnenC>> Lucent TechnologiesC>> Schagen 33C>> 3461 GL LinschotenC>> NetherlandsC>> Phone: +31-348-407-775C>> EMail: bwijnen at lucent.comC>>C>> Harald Tveit AlvestrandC>> Cisco SystemsC>> Weidemanns vei 27C>> Trondheim 7043C>> NorwayC>> EMail: harald at alvestrand.noC>>C>> Peter W. ResnickC>> QUALCOMM IncorporatedC>> 5775 Morehouse DriveC>> San Diego, CA 92121-1714C>> USC>> EMail: presnick at qualcomm.comC>>Hollenbeck Informational [Page 31]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>>Appendix A. Justification, Reasoning and MotivationsC>>C>>C>> Quite a bit of the proposals from the consultant report have beenC>> incorporated in this recommendation. However, a number ofC>> changes have been made. In this section we try to explain whichC>> changes were made and why.C>>C>> A.1 Changes to the name of the administrative entityC>>C>> In order to make it very clear that the new and legalC>> administrative entity is separate from the ISOC IETF activityC>> that deals with standardization and protocol development, thisC>> recommendation uses "The IETF Administrative Support Foundation"C>> as the name for the corporation to be created.C>>C>> A.2 DomicileC>>C>> Various questions have been raised if the choice of DomicileC>> should be further investigated. In order to make progress thisC>> document recommends to make a definite choice now and go for a USC>> based not-for-profit corporation in the state of Virginia.C>> Further investigation would most probably delay the whole processC>> by at least half a year.C>>C>> A.3 Changes to the composition of the BoTC>>C>> The consultant report had a proposal for Position-based Trustees,C>> which would automatically make the IAB chair and the IETF chairC>> voting members of the Board of Trustees (BoT) of the IETFC>> Administrative Support Foundation. There was discussion on theC>> IETF mailing list that those people are not selected because ofC>> their business acumen but rather for their technical leadership.C>> We do not want to change those criteria. Another concern wasC>> that this might generate a conflict of interest as well. So thisC>> recommendation has made the IAB and IETF chairs liaisons to theC>> BoT.C>>C>> Instead of making IAB and IESG chairs voting Trustees, thisC>> recommendation specifies that IAB and IESG can each select anC>> outside (i.e. not a member of IAB or IESG) person as a votingC>> Trustee.C>>C>> The selection of three (3) IETF selected Trustees has not changedC>> in this recommendation. However, there is a concern that theC>> current composition of the Nomcom is not tailored to selectingC>> people for this position. So over time a different process mayC>> need to be defined for selecting those Trustees.Hollenbeck Informational [Page 32]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>>C>> In order to balance the ISOC and IETF people present at the BoTC>> meetings, this recommendation also specifies that the chair andC>>C>> president of ISOC also function as liaisons to the BoT of theC>> IETF Administrative Support Foundation.C>>C>>Appendix B. Domicile of the IETF Administrative Support FoundationC>>C>> A U.S. non-profit, non-member corporation is being recommended.C>> This recommendation is based on simple considerations ofC>> expediency and pragmatism: a transition will be simplest andC>> least risky (in the short term). The reasoning is as follows:C>>C>> o Administrative support for the IETF is currently enmeshed in aC>> series of relationships with other institutions, most of whichC>> are also U.S.-chartered non-profit organizations. Any changeC>> in the institutional status of administrative supportC>> functions will require familiarity with U.S. nonprofit law.C>> Incorporation in another country would require familiarityC>> with those laws as well. Thus, the incorporation expensesC>> would be higher and the process would take longer.C>>C>> o U.S. law has a strong concept of "nexus," which is aC>> determination of when a foreign organization has enoughC>> relationship to U.S. law to fall under the jurisdiction of aC>> U.S. court. Because of a long history of operating in theC>> U.S., numerous meetings in the U.S., and the large number ofC>> U.S. residents who are participants and leaders, we feel it isC>> likely that U.S. courts would find nexus in relation to ourC>> US-based activities, even if the IETF administrative supportC>> organization was incorporated in another country. In otherC>> words, incorporating in a country besides the U.S. does notC>> necessarily free the support organization from any perceivedC>> vagaries of U.S. law.C>>C>> o Incorporating in a country other than the US may have taxC>> implications if the Internet Society is providing fundingC>> support.C>>C>> o It is very likely that the IETF Administrative SupportC>> Foundation would be deemed to clearly fall under theC>> "scientific" and "educational" grounds for classification as aC>> tax-exempt charity undersection 501(c)(3) of the IRS code, soC>> a tax-exempt application should be quite straight-forward.C>>C>> o The incorporation laws of the U.S. states being considered doC>> not require that any members of the Board of Trustees be of aHollenbeck Informational [Page 33]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> certain nationality or state residency (e.g., there are noC>> "local director" requirements). The U.S. Dept. of CommerceC>> foreign-controlled organization reporting requirements applyC>> only to "business enterprises", and do not apply to non-profitC>>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 allowC>> the IETF administrative support organization to make use of ISOCC>> headquarters to house its single employee (though the employeeC>> might be able to be housed at the Internet Society even if theC>> incorporation were elsewhere, for example the ISOC GenevaC>> office).C>>C>>Appendix C. Risk AnalysisC>>C>> This scenario (as do all scenarios) has some risks. This sectionC>> tries to enumerate the sort of risks that we recognize andC>> summarizes why we think we can accept the risk or what kind ofC>> action we think we can take if the risk indeed materializes intoC>> a problem.C>>C>> C.1 US Domicile risksC>>C>> As explained in [I-D.malamud-consultant-report], incorporating inC>> the US carries two specific risks: the perception of the IETFC>> being a US-based organization and the potential for (orC>> 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 andC>> that many of its current support organizations are US-basedC>> leaves an impression that the IETF is too US-centric.C>> Incorporating the new administrative entity in the US may add toC>> that perception.C>>C>> Also, the IETF history is based in US federal government researchC>> and funding. Though IETF is long separated from thoseC>> beginnings, even in the past few years there have beenC>> interactions between the US government and the IETF that haveC>> concerned people. Incorporating the administrative entity in theC>> US may invite more US governmental interference in the standardsC>> activity of the IETF, or at the very least may leave theC>> perception that the US government might get involved.C>>C>> Both of these are serious problems, but we think there isC>> justification for and at least one mitigation to these risks. OfHollenbeck Informational [Page 34]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> course, the primary reason to consider US incorporation isC>> expedience (Seesection 4.4.1.1 of [I-D.malamud-consultant-C>> report]). We agree that the expedience makes US incorporationC>> worth the risk. But incorporating in multiple domiciles wouldC>> significantly mitigate the risk. Assuming we go down the path ofC>>C>> US incorporation, we would like legal counsel to advise on theC>> possibility of incorporating in other domiciles (specificallyC>> Switzerland and The Netherlands) at a later date after USC>> incorporation has been completed. If this is (as we suspect)C>> indeed possible, we think this would be the best way to goC>> forward.C>>C>> C.2 Non-profit status riskC>>C>> One of the risks pointed out to incorporation was the potentialC>> that we would not get non-profit status, and that we mustC>> therefore preserve some money in escrow for tax liabilityC>> purposes. Estimates for the time it will take to get such statusC>> can be several months or even longer in some cases.C>>C>> It is important to point out that the tax liability is based onC>> profits, not on gross revenues. If the IASF is only taking inC>> enough money to cover expenses, there would be very little taxC>> liability. However, if more revenue is brought in than is spent,C>> for example to build up an endowment or operating reserve, thatC>> "profit" is potentially taxable if non-profit status is notC>> granted.C>>C>> To mitigate this risk, the corporation could be created and non-C>> profit status applied for first, and operation of the corporationC>> would only begin after non-profit status was obtained. The IETFC>> would use an interim plan for continued operations until thatC>> time. This way, no money would need to be in escrow during theC>> process of applying for non-profit status. However, that seemsC>> an excessively cautious path to take given what appears to be theC>> fairly clear non-profit nature of the IETF.C>>C>> Commencing operations while the non-profit application is beingC>> considered, but being careful about balancing revenue withC>> expenses and keeping an appropriate escrow account seems like aC>> prudent task. Further, any fund raising campaigns that result inC>> shifts to the balance sheet of the IASF should be conductedC>> cautiously until non-profit status is granted.C>>Hollenbeck Informational [Page 35]
RFC 4089 IAB-IESG AdminRest Rec May 2005C>> C.3 Execution risksC>>C>> It is important that the execution goes well. Risks that we areC>> aware of include:C>>C>> o we can't hire a good IADC>>C>> o we fail to project cash flow properly and go insolventC>>C>> o we can't cut a deal with Foretec and have no 2005 meetingsC>>C>> o we get bad lawyers and they take too long and charge too muchC>>C>> o isoc runs out of money and doesn't tell us early enoughC>>C>> In order to mitigate these problems we have a proposed work planC>> included in this document. It is important that we get review ofC>> this work plan by as many eyes as we can get, to make sure weC>> have considered all the possible steps that need to be taken.C>>C>> C.4 Insolvency riskC>>C>> Improper management controls and procedures or other imprudentC>> fiscal or administrative practices could expose the IETF to aC>> risk of insolvency. Careful selection of trustees, a process ofC>> budget approval, and a methodical system of fiscal controls areC>> necessary to minimize this risk.C>>C>> C.5 Legal risksC>>C>> Improper formulation of the legal framework underlying the IETFC>> may expose the institution and individuals in leadershipC>> positions to potential legal risks. Any such risk under thisC>> plan appears to be equivalent to the risk faced by the communityC>> under the current legal framework. This risk is furtherC>> mitigated by a thorough review by legal counsel, and by use ofC>> insurance coverage.C>>C>> The legal exposure is best minimized by a careful adherence toC>> our procedures and processes, as defined by the Best CurrentC>> Practice Series. A carefully stated process, such as the BCPC>> documents that govern the selection of leadership positions andC>> define the standards process are the best insurance against legalC>> exposure, provided care is taken to stick to the processC>> standards that have been set. Adherence to a public rule book andC>> a fully open process are the most effective mechanisms the IETFC>> community can use.Hollenbeck Informational [Page 36]
RFC 4089 IAB-IESG AdminRest Rec May 2005Appendix: 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. DaigleO>> VeriSignO>> M. WassermanO>> ThingMagicO>> September 20, 2004O>>O>> AdminRest Scenario O: An IETF-Directed Activity Housed Under theO>> Internet Society (ISOC) Legal UmbrellaO>>O>> AbstractO>>O>> This document defines an alternative proposal for the structureO>> of the IETF's administrative support activity (IASA) -- an IETF-O>> defined and directed activity that operates within the ISOC legalO>> umbrella. It proposes the creation of an IETF AdministrativeO>> Oversight Committee (IAOC) that is selected by and accountable toO>> the IETF community. This committee would provide oversight forO>> the IETF administrative support activity, which would be housedO>> within the ISOC legal umbrella. In order to allow the communityO>> to properly evaluate this scenario, some draft BCP wording isO>> included.O>>O>> 1. Overview of Scenario OO>>O>> IETF community discussions of the scenarios for administrativeO>> restructuring presented in Carl Malamud's consultant report [I-O>> D.malamud-consultant-report] have led to the identification of aO>> potentially viable alternative that is not included in thatO>> report -- an IETF-defined and directed administrative supportO>> function housed under the ISOC legal umbrella (called "IASA"O>> hereafter). This new scenario retains some properties of theO>> original ISOC-based scenarios, Scenarios A and B. However, thisO>> new scenario aims to provide:O>>O>> o continued close relationship with ISOCO>>O>> o a clear basis from which the IETF can define (and, over time,O>> refine) the administrative activity in terms of IETF communityO>> needs, using existing IETF/ISOC processesO>>Hollenbeck Informational [Page 37]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> o an operational oversight board that is accountable to the IETFO>> communityO>>O>> o continued separation between the IETF standards activity andO>> any fund-raising for standards work (within ISOC)O>>O>> o appropriate ISOC oversight of its standards activities fundsO>>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 beO>> defined in a BCP that would be created via the IETF standardsO>> process [RFC2026] and approved by the ISOC Board of Trustees.O>> This BCP would describe the scope of an IETF AdministrativeO>> Support Activity (IASA) and would define the structure andO>> responsibilities of the IETF Administrative Oversight CommitteeO>> (IAOC), an IETF-selected body responsible for overseeing theO>> IASA. Like the Internet Architecture Board (IAB), the IASA wouldO>> be housed within the ISOC legal umbrella. The BCP would alsoO>> describe ISOC's responsibilities within this scenario, includingO>> requirements for financial accounting and transparency. A draftO>> of this BCP is included in the next section of this document.O>>O>> Scenario O allows us to establish IETF control over ourO>> administrative support functions in terms of determining thatO>> they meet the community's needs, and adjusting them from time toO>> time using IETF processes. At the same time, it does not requireO>> that the IETF community determine, create and undertake the risksO>> associated with an appropriate corporate structure (with similarO>> financial infrastructure and tax-exempt status to ISOC's) inO>> order to solve the pressing administrative issues outlined inO>> [RFC3716]. This proposal also defines the boundaries of the IASAO>> so that it could be encapsulated and moved elsewhere at someO>> future date, should that ever be desirable.O>>O>> 2. Draft of Administrative Support BCPO>>O>> This section proposes draft text for a BCP that would define theO>> scope and structure of the IASA. Although this text wouldO>> require further refinement within the IETF community, thisO>> section is intended to be clear and complete enough to allow theO>> community to reach a well-informed opinion regarding thisO>> scenario.O>>Hollenbeck Informational [Page 38]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> 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 aO>> part of the IETF's standards process, and this document does notO>> affect the ISOC-IETF working relationship concerning standardsO>> development or communication of technical advice. The purpose ofO>> this memo is to define an administrative support activity that isO>> responsive to the IETF technical community's needs, as well asO>> consistent with ISOC's operational, financial and fiduciaryO>> requirements while supporting the IETF technical activity.O>>O>> The IETF Administrative Support Activity (IASA) providesO>> administrative support for the technical work of the IETF. ThisO>>O>> includes, as appropriate, undertaking or contracting for theO>> work described in (currently, [RFC3716] but the eventual BCPO>> should include the detail as an appendix), covering IETF documentO>> and data management, IETF meetings, any operational agreements orO>> contracts with the RFC Editor and IANA. This provides theO>> administrative backdrop required to support the IETF standardsO>> process and to support the IETF organized technical activities,O>> including the IESG, IAB and working groups. This includes theO>> financial activities associated with such IETF supportO>> (collecting IETF meeting fees, payment of invoices, appropriateO>> financial management, etc). The IASA is responsible for ensuringO>> that the IETF's administrative activities are done and done well;O>> it is not the expectation that the IASA will undertake the workO>> directly, but rather contract the work from others, and manageO>> the contractual relationships in line with key operatingO>> principles such as efficiency, transparency and costO>> effectiveness.O>>O>> The IASA is distinct from other IETF-related technical functions,O>> such as the RFC editor, the Internet Assigned Numbers AuthorityO>> (IANA), and the IETF standards process itself. The IASA is notO>> intended to have any influence on the technical decisions of theO>> IETF or on the technical contents of IETF work.O>>O>> 2.1.1 Structure of the IASAO>>O>> The IASA will be structured to allow accountability to the IETFO>> community. It will determine the ongoing success of the activityO>> in meeting IETF community needs laid out in this BCP, as well asO>> ISOC oversight of its financial and resource contributions. TheO>> supervisory body defined for this will be called the IETFO>> Administrative Oversight Committee (IAOC). The IAOC will consistO>> of volunteers, all chosen directly or indirectly by the IETFHollenbeck Informational [Page 39]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> community, as well as appropriate ex officio appointments fromO>> ISOC and IETF leadership. The IAOC will be accountable to theO>> IETF community for the effectiveness, efficiency and transparencyO>> of the IASA.O>>O>> The IASA will initially consist of a single full-time employee ofO>> ISOC, the IETF Administrative Director (IAD). The IAD willO>> require a variety of financial, legal and administrative support,O>> and it is expected that this support will be provided by ISOCO>> support staff following an expense and/or allocation model TBD.O>>O>> Although the IAD will be a full-time ISOC employee, he will workO>> under the direction of the IAOC. The IAD will be selected by aO>> committee of the IAOC, consisting minimally of the ISOC PresidentO>> and the IETF Chair. This same committee will be responsible forO>> periodically reviewing the performance of the IAD and determiningO>> any changes to his employment and compensation. In certain casesO>> (to be defined clearly -- chiefly cases where the ISOC employeeO>> is determined to have contravened basic ISOC policies), the ISOCO>> President may make summary decisions, to be reviewed by theO>> 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 establishingO>> and administering the IASA budget. To perform these activities,O>> the IAD is expected to have signing authority comparable to otherO>> ISOC director-level employees. Generally, expenses or agreementsO>> outside that authority to be approved for financial soundness asO>> determined by ISOC policy. The joint expectation is that ISOC'sO>> policies will be consistent with allowing the IAD to carry outO>> IASA work effectively and efficiently. Should the IAOC haveO>> concerns about that, the IAOC and ISOC commit to working outO>> 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 otherO>> administrative functions will be outsourced via well-definedO>> contracts. The IAD will be responsible for negotiating andO>> maintaining those contracts, as well as providing anyO>> coordination that is necessary to make sure the IETFO>> administrative support functions are properly covered.O>>O>> 2.1.2 IAD ResponsibilitiesO>>O>> The day to day responsibilities of the IAD will focus on managingO>> contracts with the entities providing the work supporting theO>> IETF technical activity.O>>Hollenbeck Informational [Page 40]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> The IAD will provide regular (monthly and quarterly) reports toO>> the IAOC and ISOC.O>>O>> All contracts will be negotiated by the IAD (with input from anyO>> other appropriate bodies), and reviewed by the IAOC. TheO>> contracts will be executed by ISOC, on behalf of the IETF, afterO>> whatever review ISOC requires (e.g., legal, Board of Trustees).O>>O>> The IAD will prepare an annual budget, which will be reviewed andO>> approved by the IAOC. The IAD will be responsible for presentingO>> this budget to the ISOC Board of Trustees, as part of ISOC'sO>> annual financial planning process. The partnering is such thatO>> the IAOC is responsible for ensuring the suitability of theO>> budget for meeting the IETF community's needs, but it does notO>> bear fiduciary responsibility; the ISOC board needs to review andO>>O>> understand the budget and planned activity in have enough detailO>> of the budget and proposed plans to properly carry out itsO>> fiduciary responsibility.O>>O>> 2.1.3 IAOC ResponsibilitiesO>>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 expectedO>> to be regularly engaged in IASA work, but rather to provideO>> 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 ofO>> the IAD's budget proposals in terms of fitness for IETFO>> purposes.O>>O>> o Review IASA functioning with respect to meeting the IETFO>> community's working needs.O>>O>> The IAOC's role is to review, not carry out the work of, the IADO>> and IASA. As such, it is expected the IAOC will have monthlyO>> teleconferences and periodic face to face meetings, probablyO>> coincident with IETF plenary meetings, consistent with ensuringO>> an efficient and effective operation.O>>Hollenbeck Informational [Page 41]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> 2.1.4 IASA FundingO>>O>> The IASA is supported financially in 3 ways:O>>O>> 1. IETF meeting revenues. The IAD, in consultation with theO>> 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 specificO>> fund raising activities; this maintains separation betweenO>> fundraising and standards activities. Any organizationO>> interested in supporting the IETF activity will continue toO>> be directed to ISOC, and any funds ISOC receives specificallyO>> for IETF activities (as part of an ISOC program that allowsO>> for specific designation) will be put in the IASA bankO>> 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 theO>> IASA budget (where the meeting revenues and specificO>>O>> donations do not cover the budget). These funds may comeO>> from member fees or from other revenue streams ISOC mayO>> create.O>>O>> Note that the goal is to achieve and maintain a viable IETFO>> support function based on meeting fees and specified donations,O>> and the IAOC and ISOC are expected to work together to attainO>> that goal. (I.e., dropping the meeting fees to $0 and expectingO>> ISOC to pick up the slack is not desirable; nor is raising theO>> meeting fees to prohibitive levels to fund all non-meeting-O>> related activities!).O>>O>> Also, in normal operating circumstances, the IASA would look toO>> have a 6 month operating reserve for its activities. Rather thanO>> having the IASA attempt to accrue that in its bank account, theO>> IASA looks to ISOC to build and provide that operational reserveO>> (through whatever mechanism instrument ISOC deems appropriate --O>> line of credit, financial reserves, etc). Such reserves do notO>> appear instantaneously; the goal is to reach that level ofO>> reserve by 3 years after the creation of the IASA. It is notO>> expected that any funds associated with such reserve will be heldO>> in the IASA bank account.O>>Hollenbeck Informational [Page 42]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> 2.2 IAOC Membership, Selection and AccountabilityO>>O>> Note: This section is particularly subject to change as we workO>> to find the best way to achieve the key principles. The keyO>> principles being adhered to are that while this should beO>> reasonably separate from IETF Standards process management:O>>O>> o the IETF and IAB Chairs need to be involved to a level thatO>> permits them to be involved in and oversee the aspectsO>> 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 gettingO>> decisions to and through the IASA.O>>O>> The current draft, below, therefore makes the IETF Chair exO>> officio voting member of the IAOC, and the IAB Chair a non-votingO>> liaison. Future versions may change either or both, depending onO>> what makes sense to the IETF community in its deliberations.O>>O>> The IAOC will consist of seven voting members who will beO>> selected as follows:O>>O>> o 2 members chosen by the IETF Nominations Committee (NomCom)O>>O>> o 1 member chosen by the IESGO>>O>> o 1 member chosen by the IABO>>O>> o 1 member chosen by the ISOC Board of TrusteesO>>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 ChairO>>O>> o The IETF Administrative DirectorO>>O>> The voting members of the IAOC will choose their own chair eachO>> year using a consensus mechanism of its choosing. Any appointedO>> voting member of the IAOC may serve as the IAOC Chair (i.e., notO>> the IETF Chair or the ISOC President/CEO). The role of the IAOCO>> Chair is to organize the IAOC. The IAOC Chair has no formalO>> duties for representing the IAOC, except as directed by IAOCO>> consensus.Hollenbeck Informational [Page 43]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>>O>> The members of the IAOC will typically serve two year terms.O>> Initially, the IESG and ISOC Board will make one-yearO>> appointments, the IAB will make a two-year appointment, and theO>> Nomcom will make one one-year appointment and one two-yearO>> appointment to establish a pattern where approximately half ofO>> the IAOC is selected each term.O>>O>> The two NomCom selected members will be selected using theO>> procedures described inRFC 3777. For the initial selection, theO>> IESG will provide the list of desired qualifications for theseO>> positions. In later years, this list will be provided by theO>> IAOC.O>>O>> While there are no hard rules regarding how the IAB and the IESGO>> should select members of the IAOC, it is not expected that theyO>> will typically choose current IAB or IESG members, if only toO>> avoid overloading existing leadership. However, they shouldO>> choose people who are familiar with the administrative supportO>> needs of the IAB, the IESG and/or the IETF standards process. ItO>> is suggested that a fairly open process be followed for theseO>> selections, perhaps with an open call for nominations and/or aO>> period of public comment on the candidates. The IAB and IESG areO>> encouraged to look at the procedure for IAB selection of ISOCO>> 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 choseO>> them. All members of the IAOC are accountable directly to theO>> IETF community. To receive direct feedback from the community,O>> the IAOC will hold an open meeting at least once per year at anO>> IETF meeting. This may take the form of an open IAOC plenary orO>> a working meeting held during an IETF meeting slot. The form andO>> contents of this meeting are left to the discretion of the IAOCO>> Chair.O>>O>> Decisions of IAOC members or the entire IAOC are subject toO>> appeal using the procedures described inRFC 2026. The initialO>> appeal of an individual decision will go to the full IAOC.O>> Appeals of IAOC decisions will go to the IESG and continue up theO>> chain as necessary (to the IAB and the ISOC Board). The IAOCO>> will play no role (aside from possible administrative support) inO>> appeals of WG Chair, IESG or IAB decisions.O>>Hollenbeck Informational [Page 44]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> In the event that an IAOC member abrogates his duties or actsO>> against the bests interests of the IETF community, IAOC membersO>> are subject to recall using the recall procedure defined in RFCO>> 3777. IAB and IESG-appointed members of the IAOC are not subjectO>> to recall by their appointing bodies.O>>O>> 2.3 IASA Budget ProcessO>>O>> While the IASA sets a budget for the IETF's administrative needs,O>> its budget process clearly needs to be closely coordinated withO>> ISOC's. The specific timeline will be established each year,O>> before the second IETF meeting. A general annual timeline forO>> budgeting will be:O>>O>> July 1 The IAD presents a budget proposal (for the followingO>> 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 isO>> part of the IAOC, the IAOC should have a preliminaryO>> indication of how the budget will fit with ISOC's ownO>> budgetary expectations. The budget proposal is passed to theO>> ISOC Board of Trustees for review in accordance with theirO>> fiduciary duty.O>>O>> September 1 The ISOC Board of Trustees approves the budgetO>> proposal provisionally. During the next 2 months, the budgetO>> may be revised to be integrated in ISOC's overall budgetingO>> 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 willO>> update forecasts of expenditures quarterly. This may necessitateO>> the adjustment of the IASA budget. The revised budget will needO>> to be approved by the IAOC and ISOC Board of Trustees.O>>O>> 2.4 Relationship of the IAOC to Existing IETF LeadershipO>>O>> The IAOC will be directly accountable to the IETF Community.O>> However, the nature of the IAOC's work will involve treating theO>> IESG and IAB as internal customers. The IAOC should not considerO>> its work successful unless the IESG and IAB are satisfied withO>> the administrative support that they are receiving.O>>Hollenbeck Informational [Page 45]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> 2.5 ISOC Responsibilities for IASAO>>O>> Within ISOC, support for the IASA should be structured to meetO>> the following goals:O>>O>> Transparency: The IETF community should have complete visibilityO>> into the financial and legal structure of the ISOC standardsO>> activity. In particular, the IETF community should have accessO>> to a detailed budget for the entire standards activity,O>> quarterly financial reports and audited annual financials. InO>> addition, key contract material and MOUs should be publiclyO>> available. Most of these goals are already met by ISOC today.O>> The IAOC will be responsible for providing the IETF communityO>> with regular overviews of the state of affairs.O>>O>> Unification: As part of this arrangement, ISOC's sponsorship ofO>> the RFC Editor, IAB and IESG, as well as insurance coverageO>> for the IETF will be managed as part of the IASA under theO>> IAOC.O>>O>> Independence: The IASA should be financially and legally distinctO>> from other ISOC activities. IETF meeting fees should beO>> deposited in a separate IETF-specific bank account and used toO>> fund the IASA under the direction and oversight of the IAOC.O>> Any fees or payments collected from IETF meeting sponsorsO>> should also be deposited into this account. This account willO>> be administered by the IAD and used to fund the IASA inO>> accordance with a budget and policies that are developed asO>> described above.O>>O>> Support: ISOC may, from time to time, choose to transfer otherO>> funds into this account to fund IETF administrative projectsO>> or to cover IETF meeting revenue shortfalls. There may alsoO>>O>> be cases where ISOC chooses to loan money to the IASA to helpO>> with temporary cash flow issues. These cases should beO>> carefully documented and tracked on both sides. ISOC willO>> work to provide the 6 month operational reserve for IASAO>> functioning described above.O>>O>> Removability: While there is no current plan to transfer theO>> legal and financial home of the IASA to another corporation,O>> the IASA should be structured to enable a clean transition inO>> the event that the IETF community decides, through BCPO>> publication, that such a transition is required. In thatO>> case, the IAOC will give ISOC a minimum six months noticeO>> before the transition formally occurs. During that period,O>> the IAOC and ISOC will work together to create a smoothHollenbeck Informational [Page 46]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> transition that does not result in any significant serviceO>> outages or missed IETF meetings. All contracts that areO>> executed by ISOC as part of the IASA should either include aO>> clause allowing termination or transfer by ISOC with sixO>> months notice, or should be transferrable to anotherO>> corporation in the event that the IASA is transitioned awayO>> from ISOC in the future. Any accrued funds, and IETF-specificO>> intellectual property rights (concerning administrative dataO>> and/ or tools) would also be expected to be transitioned toO>> any new entity, as well.O>>O>> Within the constraints outlined above, all other details of howO>> to structure this activity within ISOC (as a cost center, aO>> department or a formal subsidiary) should be determined by ISOCO>> in consultation with the IAOC.O>>O>> 3. Workplan for Formalizing the IETF Administrative SupportO>> ActivityO>>O>> This section proposes a workplan and schedule for formalizing theO>> IETF administrative support activity (IASA) for the remainder ofO>> 2004 and 2005.O>>O>> 3.1 Workplan GoalsO>>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 ofO>> substantial disruption to the IETF standards process.O>>O>> o Establish IETF community consensus and ISOC approval of a BCPO>> formalizing the IASA as described in this scenario before anyO>> 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 hiringO>> the IAD and establishing contracts for administrative support,O>> are made by people chosen for that purpose who will beO>> responsible to the community for the effectiveness of thisO>> effort (the IAD and members of the IAOC) -- not by our alreadyO>> overloaded technical leadership.O>>O>> o Within the above constraints, move as quickly as possibleO>> towards a well-defined administrative support structure thatO>> is transparent and accountable to the IETF community.O>>Hollenbeck Informational [Page 47]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> 3.2 Workplan OverviewO>>O>> There are three major elements to this workplan which can, toO>> some degree, take place in parallel after we establish IETFO>> community consensus to pursue Scenario O:O>>O>> o Finalizing the BCP text and getting it approved by the IETFO>> community and ISOC.O>>O>> o Selecting IASA leadership. This includes appointing anO>> interim IAOC, recruiting the IAD, and eventually appointingO>> the full IAOC.O>>O>> o Negotiating agreements with service providers. This includesO>> determining the structure and work flow of the IASA, decidingO>> which portions of the IASA should be staffed via an openO>> request for proposals (RFP) process, and issuing a RFP forO>> those portions, as well as establishing sole source contractsO>> or MOUs for other portions of the IASA.O>>O>> Each of the three items listed above is described in more detailO>> in the following sections.O>>O>> 3.3 Approval by the IETF Community and ISOCO>>O>> In scenario O, the IASA is formalized in a BCP that is approvedO>> 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 shouldO>> pursue Scenario O as defined in a joint IAB/IESGO>> recommendation based on this proposal. This consensus willO>> be established through community discussion and a formal two-O>> week consensus call issued by the IETF chair on the IETFO>> mailing list.O>>O>> 2. Establishment of IETF community consensus on a BCP thatO>> formalizes the IASA as described. This consensus would beO>> established through public discussion, a four week IETF LastO>> Call and IESG review and approval.O>>O>> 3. ISOC approval of the BCP and acceptance of ISOC'sO>> responsibilities as described therein. This approval andO>> acceptance would be signified by an ISOC Board resolution.O>>O>> The timeline for these three stages is rather long, but there isO>> significant progress that can be made in other areas once we haveO>> established IETF community consensus to pursue this scenario.Hollenbeck Informational [Page 48]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>>O>> 3.4 Selecting IASA LeadershipO>>O>> Once we have IETF consensus to pursue this scenario, we canO>> 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, determiningO>> the structure of the IASA work, issuing RFPs and negotiatingO>> potential agreements with service providers. The interim IAOCO>> would not be empowered to make binding agreements, but could workO>> appropriate consultants and advisors to make a lot of progressO>> towards determining the initial structure and work flow of theO>> IASA.O>>O>> Because the IETF Nominations Commitee (NomCom) process for newO>> positions will consume a lot of resources and take a long time toO>> complete, we propose that the interim IAOC consist of:O>>O>> o 1 IESG selected memberO>>O>> o 1 IAB selected memberO>>O>> o 1 ISOC selected memberO>>O>> o The IETF ChairO>>O>> o The ISOC President/CEOO>>O>> The IAB chair will serve as a liaison, as described above.O>>O>> The IESG and ISOC Board appointments will be expected to serveO>> until the first IETF meeting of 2006, and the IAB appointmentO>> will be expected to serve until the first IETF meeting of 2007,O>> assuming that the BCP is approved and the IAOC continues to haveO>> appointed members from these bodies.O>>O>>O>> After all of the interim IAOC members are selected, they willO>> choose an interim IAOC chair from among the appointed members.O>>O>> When the BCP is approved, if the BCP indicates that there will beO>> NomCom selected IAOC members they will be chosen at that time.O>> Any adjustments to appointed members based on the BCP contentsO>> will also be made at that time. The IAOC will transition fromO>> interim to non-interim status when all non-interim members areO>> seated. A new, non-interim chair selection process will thenO>> commence.O>>Hollenbeck Informational [Page 49]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> 3.5 Recruiting the IETF Administrative DirectorO>>O>> The interim IAOC should appoint an IAD selection committee toO>> recruit and select the IETF Administrative Director. ThisO>> committee will consist entirely of IAOC members or liaisons, andO>> will, at minimum, include the IETF chair and the ISOC President.O>> If the IAOC chooses, this committee could include the entireO>> IAOC.O>>O>> The IAD selection committee should determine a job descriptionO>> for the IAD, in consultation with other IETF leaders and the IETFO>> community. Once the job description is established, the IADO>> selection committee should recruiting candidates for theO>> position.O>>O>> Although the interim IAOC is not empowered to hire the IAD as aO>> full-time employee, it might be possible for the IAOC to ask ISOCO>> to engage the potential IAD as a consultant to help with otherO>> tasks during the interim period.O>>O>> 3.6 Establishing Agreement with Service ProvidersO>>O>> The most important activity of the IAOC during late 2004 andO>> early 2005 will be to determine the structure and work flow ofO>> the IASA and to establish contracts or other agreements withO>> service providers to do the required work. This work includesO>> the following functions as defined in the consultant's report:O>>O>> o Technical infrastructureO>>O>> o Meeting managementO>>O>> o Clerk's officeO>>O>> o RFC Editor services to support IETF standards publicationO>>O>> o IANA services to support IETF standards publicationO>>O>> The interim IAOC should work with IETF leaders and otherO>> knowledgeable members of the community to determine the structureO>> and work flow required for the IASA activity and makeO>> corresponding adjustments to the above list, if necessary. TheO>> interim IAOC can also identify which areas of IASA work shouldO>> continue to be provided by existing IETF service providers, andO>> work with those providers to establish proposed contracts orO>> agreements for later approval by the non-interim IAOC. The IAOCO>> can also choose to start an RFP process for any services thatO>> they believe should be filled through an open RFP process.Hollenbeck Informational [Page 50]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>>O>> 3.7 Establishing a 2005 Operating BudgetO>>O>> Because the ISOC 2005 budgeting process will be finalized beforeO>> the non-interim IAOC is seated, the interim IAOC should work withO>> the ISOC staff and President to establish a proposed 2005O>> operating budget for the IASA. Since this will happen in advanceO>> of full knowledge regarding the costs of 2005 operations, it mayO>> be subject to significant adjustment later.O>>O>> 3.8 Proposed Schedule for IASA TransitionO>>O>> As described above, the three stages of the IETF community andO>> ISOC approval process will take some time. If the communityO>> 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 throughO>> 1-Oct-2005. IAB/IESG discusses this proposal with ISOCO>> Board.O>>O>> 2. IAB/IESG joint recommendation issued on 8-Oct-04, includingO>> full BCP proposal.O>>O>> 3. Community discussion of the joint IAB/IESG recommendationO>> through 22-Oct-04.O>>O>> 4. Two-week community consensus call issued on the IETF list onO>> 23-Oct-04 regarding rough community consensus to pursue thisO>> direction and appoint an interim IAOC -- extends throughO>> IETF 61. IAOC selecting bodies begin search, based onO>> expected community consensus.O>>O>> 5. Rough community consensus declared on 8-Nov-04 to pursueO>> Scenario O and appoint the interim IAOC.O>>O>> 6. Interim IAOC seated on 15-Nov-04. Interim IAOC beginsO>> interim work outlined above, including establishment ofO>>O>> estimated 2005 budget and IAD recruitment.O>>O>> 7. BCP text discussed by community, IETF leadership and ISOCO>> Board until we have something that represents roughO>> community consensus that is acceptable to all. We hope thatO>> 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 2005O>>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, movingO>> the IAOC from interim to non-interim status.O>>O>> 12. Formal agreements with all service providers in-place byO>> June 2005.O>>O>> 4. Security ConsiderationsO>>O>> This document describes a scenario for the structure of theO>> IETF's administrative support activities. It introduces noO>> security considerations for the Internet.O>>O>> 5. IANA ConsiderationsO>>O>> This document has no IANA considerations in the traditionalO>> sense. As part of the extended IETF family, though, IANA may beO>> interested in the contents.O>>O>> 6. AcknowledgementsO>>O>> Most of the ideas in this document are not new, and many of themO>> did not originate with the authors. This scenario represents aO>> combination of ideas discussed within the IAB, the IESG and theO>> IETF Community.O>>O>> This document was written using the xml2rfc tool described in RFCO>> 2629 [RFC2629].O>>O>> 7. ReferencesO>>O>> 7.1 Normative ReferencesO>>O>> [I-D.malamud-consultant-report] Malamud, C., "IETF AdministrativeO>> Support Functions",draft-malamud-consultant-report-01O>>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: AdministrationO>> and Execution",RFC 3716, March 2004.O>>Hollenbeck Informational [Page 52]
RFC 4089 IAB-IESG AdminRest Rec May 2005O>> 7.2 Informative ReferencesO>>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 IETFO>> Technology",BCP 79,RFC 3668, February 2004.O>>O>> Authors' AddressesO>>O>> Leslie DaigleO>> VeriSignO>> EMail: leslie at verisignlabs.com, leslie at thinkingcat.comO>>O>> Margaret WassermanO>> ThingMagicO>> One Broadway, 14th FloorO>> Cambridge, MA 02142 USAO>>O>> Phone: +1 617 758-4177O>> EMail: margaret at thingmagic.comO>> URI:http://www.thingmagic.comHollenbeck Informational [Page 53]
RFC 4089 IAB-IESG AdminRest Rec May 2005Informative 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.netHollenbeck Informational [Page 54]
RFC 4089 IAB-IESG AdminRest Rec May 2005Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained inBCP 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 inBCP 78 andBCP 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 athttp://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]
[8]ページ先頭