idnits 2.17.1 draft-malamud-consultant-report-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3874. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3683], [RFC3184], [RFC3005]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 61: '...rent Status--YOU MUST READ THIS SECTIO...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2106 has weird spacing: '... format speci...' == Line 2524 has weird spacing: '... Nomcom and t...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 8, 2004) is 7169 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1958' is defined on line 2152, but no explicit reference was found in the text == Unused Reference: 'RFC3233' is defined on line 2196, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 2199, but no explicit reference was found in the text == Unused Reference: 'Eastlake' is defined on line 2277, but no explicit reference was found in the text == Unused Reference: 'Huxley' is defined on line 2293, but no explicit reference was found in the text == Unused Reference: 'RFC2134' is defined on line 2496, but no explicit reference was found in the text == Unused Reference: 'RFC3844' is defined on line 2415, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1958 ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 2031 (Obsoleted by RFC 8712) ** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2555 ** Downref: Normative reference to an Informational RFC: RFC 2860 ** Obsolete normative reference: RFC 3005 (Obsoleted by RFC 9245) ** Obsolete normative reference: RFC 3184 (Obsoleted by RFC 7154) ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) ** Downref: Normative reference to an Informational RFC: RFC 3710 ** Downref: Normative reference to an Historic RFC: RFC 3716 ** Downref: Normative reference to an Informational RFC: RFC 3774 ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) == Outdated reference: A later version (-09) exists of draft-narten-iana-considerations-rfc2434bis-00 -- Duplicate reference: RFC2135, mentioned in 'RFC2135', was also mentioned in 'RFC2134'. -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 22 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Malamud, Ed. 3 Internet-Draft Memory Palace Press 4 Expires: March 9, 2005 September 8, 2004 6 IETF Administrative Support Functions 7 draft-malamud-consultant-report-01 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 9, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This Internet-Draft discusses the restructuring of administrative 43 support functions for the IETF. The draft begins with a discussion 44 of prior steps in the process that led up to this report and 45 discusses the process going forward. The draft then examines the 46 current functioning of administrative support functions, analyzes 47 options for restructuring operational functions, and analyzes options 48 available to provide an institutional framework for such support. 50 The provision of such administrative support functions is limited in 51 scope with responsibility only for the administrative, fiscal, and 52 legal infrastructure needed to support the IETF community. In 53 particular, issues such as defining and managing the standards-making 54 process and the governance of that process are explicitly out of 55 scope for this restructuring. 57 This Internet-Draft is an independent consultant's report and should 58 not be regarded as a consensus view or a policy statement. The 59 report contains only the author's views. 61 Current Status--YOU MUST READ THIS SECTION 63 This is a FIRST DRAFT and DOES NOT represent a position or a 64 consensus. It should be regarded as a starting point for community 65 discussion, followed by eventual decision making by the leadership 66 based on a community consensus. 68 In particular, the key word "we" in this document is to be 69 interpreted as meaning "I, the author". This document does not 70 represent a consensus, policies, or opinions that are to be 71 attributed to anything but the personal views of the author. 73 Intended Status and Mailing List 75 This document is intended for publication as an Internet-Draft and is 76 expected to undergo numerous revisions. It is intended that this 77 document be submitted for publication as an Informational RFC. 79 The forum for discussion of this draft is the IETF Discussion list 80 (ietf@ietf.org). The IETF Discussion List is defined in [RFC3005] 81 and further defined in [RFC3184] and [RFC3683]. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 1.1 Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 5 87 1.1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 88 1.1.2 IETF Standards Process Out of Scope . . . . . . . . . 5 89 1.1.3 ISOC Role in Standards Process Out of Scope . . . . . 6 90 1.2 Previous Steps in This Process . . . . . . . . . . . . . . 7 91 1.3 Decision Process . . . . . . . . . . . . . . . . . . . . . 7 92 1.4 Criteria for Judging an Administrative Restructuring . . . 8 93 1.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . 8 94 2. Analysis of Current Administrative Framework . . . . . . . . . 10 95 2.1 Providers and Functions . . . . . . . . . . . . . . . . . 10 96 2.2 Function 1: Administration . . . . . . . . . . . . . . . . 11 97 2.3 Function 2: Meetings . . . . . . . . . . . . . . . . . . . 13 98 2.4 Function 3: Core Information Technology . . . . . . . . . 16 99 2.5 Function 4: Document and Information Flow . . . . . . . . 17 100 3. Recommendations for Restructuring the Administrative 101 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 3.1 Recommendation 1: Hire An Administrative Director . . . . 20 103 3.2 Recommendation 2: Establish Contracts for Core Services . 21 104 3.2.1 Details of Potential RFP Components . . . . . . . . . 24 105 3.3 Recommendation 3: Provide Timely and Uniform Financial 106 Reporting . . . . . . . . . . . . . . . . . . . . . . . . 28 107 3.4 Recommendation 4: More Focus on Archives . . . . . . . . . 28 108 4. Options for an Institutional Basis for Administrative 109 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 30 110 4.1 Discussion of Organizational Form and Legal Domicile . . . 30 111 4.2 Scenario A: ISOC Operating Unit . . . . . . . . . . . . . 31 112 4.2.1 Division of the Internet Society . . . . . . . . . . . 31 113 4.2.2 Intended benefits . . . . . . . . . . . . . . . . . . 32 114 4.2.3 Additional Considerations . . . . . . . . . . . . . . 32 115 4.3 Scenario B: More Formalized ISOC Operating Unit . . . . . 33 116 4.4 Scenario C: Well-Defined Entity With Close Ties to ISOC . 35 117 4.4.1 How Scenario C Might Work In Practice . . . . . . . . 35 118 4.5 Scenario D: Autonomous Entity . . . . . . . . . . . . . . 41 119 4.6 Discussion of Unincorporated Associations . . . . . . . . 41 120 5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 45 121 5.1 Short-Term . . . . . . . . . . . . . . . . . . . . . . . . 45 122 5.2 Long-Term . . . . . . . . . . . . . . . . . . . . . . . . 45 123 6. Acknowledgment of CNRI Contribution to the IETF Community . . 47 124 7. Acknowledgment of Contributions and Reviews . . . . . . . . . 48 125 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 126 9. Security Considerations . . . . . . . . . . . . . . . . . . . 50 127 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 128 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 51 129 10.2 Informative References . . . . . . . . . . . . . . . . . . . 52 130 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 60 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 60 132 A. Consulting Contract . . . . . . . . . . . . . . . . . . . . . 61 133 B. IETF Financial Information . . . . . . . . . . . . . . . . . . 65 134 B.1 Consolidated 3-Year Historical Income Statement . . . . . 65 135 B.2 Internet Society 2004 Budget Summary . . . . . . . . . . . 67 136 C. 10-Year Meeting Attendance Summary . . . . . . . . . . . . . . 70 137 C.1 Analysis of Meeting-Based Expense and Revenue Drivers . . 72 138 D. Sample Draft Incorporating Documents for a Hypothetical 139 IETF Foundation . . . . . . . . . . . . . . . . . . . . . . . 74 140 D.1 Sample Draft Articles of Incorporation . . . . . . . . . . 74 141 D.2 Sample Draft Bylaws of the IETF Foundation . . . . . . . . 74 142 D.2.1 Article I: Organization . . . . . . . . . . . . . . . 74 143 D.2.2 Article II: Purpose . . . . . . . . . . . . . . . . . 74 144 D.2.3 Article III: Members . . . . . . . . . . . . . . . . . 75 145 D.2.4 Article IV: Offices . . . . . . . . . . . . . . . . . 75 146 D.2.5 Article V: Board of Trustees . . . . . . . . . . . . . 75 147 D.2.6 Article VI: Officers . . . . . . . . . . . . . . . . . 79 148 D.2.7 Article VII: Amendments . . . . . . . . . . . . . . . 80 149 D.2.8 Article VIII: Dissolution . . . . . . . . . . . . . . 81 150 D.2.9 Article IX: Miscellaneous Provisions . . . . . . . . . 81 151 E. Sample Draft Call for Applications -- IETF Administrative 152 Director . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 153 F. Sample Draft Request for Proposals . . . . . . . . . . . . . . 85 154 F.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 85 155 F.2 General Provisions . . . . . . . . . . . . . . . . . . . . 86 156 F.3 Requirement 1: Core Network Infrastructure . . . . . . . . 87 157 F.4 Requirement 2: Systems Administration Services . . . . . . 87 158 F.5 Requirement 3: Postmaster of the IETF Administrative 159 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 87 160 F.6 Requirement 4: Webmaster of the IETF Administrative 161 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 88 162 F.7 Requirement 5: Meetings . . . . . . . . . . . . . . . . . 88 163 F.8 Requirement 6: Clerk of the IETF Administrative Entity . . 89 164 F.9 Selection Criteria and Evaluation Process . . . . . . . . 89 165 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 166 Intellectual Property and Copyright Statements . . . . . . . . 92 168 1. Introduction 170 1.1 Goals and Non-Goals 172 1.1.1 Goals 174 Any plan for restructuring the administrative support functions of 175 the IETF and for establishing an institutional foundation for those 176 administrative functions must meet three goals: 177 1. The IETF process must continue to work. The smooth and stable 178 operation of the IETF is paramount. Any changes that are made 179 should be made with the goal of making that process work better. 180 This means that the continuation of the current operation, the 181 transition, and the future steady-state must all be carefully 182 thought out and executed. 183 2. The administrative, fiscal, and legal processes--including those 184 that effect this restructuring--must be transparent to the IETF 185 community. Any potential IETF administrative support 186 organization must be accountable to the community. Both the 187 transition and the future steady state will require the support 188 of the community, which requires that we observe the IETF 189 processes for decision making and that all necessary information 190 for making those decisions be made publicly available. 191 Transparency of financial transactions and in the decision making 192 process are of particular importance. 193 3. Any organization that provides administrative support functions 194 for the IETF must be subservient to and support the existing IETF 195 structures and decision-making processes. 197 1.1.2 IETF Standards Process Out of Scope 199 This restructuring exercise is limited in scope to IETF 200 administrative functions. In particular, it does not cover areas 201 including (but not limited to) the following: 202 1. The IETF technical standards-making process. 203 2. Selection of the IETF leadership and operation of the nominating 204 committee. 205 3. Any other topics already covered in our existing procedure Best 206 Current Practices documents unless called out specifically here. 208 As will be seen in subsequent sections, we explicitly reference our 209 existing purpose, governance, process, and core values as they now 210 exist and as they may be changed in the future. A new institutional 211 home for the IETF administrative functions will not supplant the IETF 212 technical processes, it will support them. 214 1.1.3 ISOC Role in Standards Process Out of Scope 216 The Internet Society and the IETF both have the good of the Internet 217 as a primary mission goal. The Internet Society has a broader 218 mandate than the IETF. Those mandates are organized as the "Pillars" 219 of the Internet Society, and include the following activities: 220 o Pillar 1: Education & Training 221 o Pillar 2: Public Policy 222 o Pillar 3: Standards & Protocols 224 In support of these pillars, the Internet Society conducts global 225 conferences including INET and NDSS, and conducts or participates in 226 regional meetings either directly or through its chapters. 228 The IETF is focused exclusively on the standards and protocol 229 activity. The Internet Society plays a complementary and vital role 230 with an active education and policy effort that allows the IETF to 231 maintain a focus on protocols and standards. 233 The Internet Society is an international membership organization, 234 open to all organizations and individuals. ISOC supports the IETF 235 and IAB in a number of ways (as detailed below), historically raising 236 funds through Organization and Individual member dues. ISOC conducts 237 and/or participates in global conferences including INET and NDSS, 238 network training workshops for developing countries, topical 239 tutorials, and various policy forums. ISOC participates in many 240 regional meetings either directly or through its chapters. 242 While a variety of administrative functions provided by the Internet 243 Society will be considered in this document, it is important to state 244 at the outset that the Internet Society currently provides two 245 important functions to the IETF: 246 1. *Administration Functions.* As discussed in subsequent sections, 247 the Internet Society provides administrative and financial 248 functions, managing the contract with the RFC Editor, providing 249 insurance for selected IETF participants, and administering a 250 discretionary fund for use by the IAB and the IETF Chairs. 251 2. *Standards Process Functions* The Internet Society plays a 252 fundamental role in the IETF Standards Process, including 253 appointment of the Nominating Committee chair, confirmation of 254 IAB members, confirmation of documents that describe the 255 standards processes, and acting as the last resort in the appeals 256 process. These Standards Process Functions are defined in 257 [RFC2026], [RFC2028], [RFC2031], and [RFC3677] and are out of 258 scope for this analysis. No changes are proposed to these 259 Standards Process Functions. 261 Any changes to the *Standards Process Functions* would use the 262 existing procedures, which require a draft to progress through the 263 process, ultimately being subject to a Last Call and a declaration of 264 consensus. In the case of modifications to existing process BCP 265 RFCs, this is a high bar to cross. 267 1.2 Previous Steps in This Process 269 A process for restructuring IETF administrative support functions as 270 well as other more general IETF issues was started in 2002. This 271 process has resulted in a number of documents that have defined the 272 goals of the IETF and basic principles for restructuring (see, e.g., 273 [I-D.alvestrand-ietf-mission]). The basic outline of the 274 administrative restructuring process was defined by an Advisory 275 Committee to the IAB, the results of which are published in 276 [RFC3716]. 278 This document carries out the requirements of [RFC3716] in discussing 279 various options for administrative restructuring and the definition 280 of relationships with institutions which support the activities of 281 the IETF community. 283 The specific goals of the administrative restructuring effort, as 284 outlined in [I-D.daigle-adminrest], are to recognize and preserve the 285 community-driven nature of the IETF technical work, and to continue 286 to support that work through the formalization of a single 287 administrative umbrella organization that will be openly accountable 288 to that same community. 290 1.3 Decision Process 292 Restructuring of IETF administrative support functions is a 293 fundamental activity that must have the support of the IETF 294 community. This document attempts to present an "omnibus" plan, 295 addressing the full scope of the requirements stated in [RFC3716]. 296 This document has already undergone numerous revisions, and will 297 undergo subsequent revisions based on input from the IETF community. 298 The first stage in reaching consensus around proposed changes include 299 the following steps: 300 1. Publication of [RFC3716]. 301 2. Continued deliberation and issuance of Internet-Drafts on the 302 Administrative Restructuring. 303 3. A decision to "move forward" including a request for funding by 304 the IETF and IAB Chairs to the Internet Society Board of 305 Trustees, allocation of those funds, and the engagement of a 306 consultant. 307 4. Drafting of this draft. 308 5. Initial reviews of this draft, including reviews by the IAB, 309 IESG, ISOC Board, and legal counsel, and others. 311 6. Briefings to the community via the IETF discussion list and at 312 IETF60 about what to expect. 313 7. Publication as an Internet-Draft. 314 8. Discussion of the Internet-Draft in the IETF community. *<---- 315 You Are Here.* 316 9. Reconsideration of the draft by the IAB, IESG, ISOC board, and 317 IETF legal counsel and issuance of a set of specific 318 recommendations by the IAB and/or IESG. 319 10. Issuance of a Last Call on this document and on the subsequent 320 memorandum published by the IESG and IAB. 321 11. Determination of community consensus on the updated plan. 322 12. Publication of this draft, as revised, as an Informational RFC. 323 13. Implementation, with periodic reporting back to the community. 324 At each stage, the draft will be revised as appropriate. 326 In addition, portions of this document are intended to form the basis 327 for one or more drafts containing new procedures or Memoranda of 328 Understanding related to the IETF administrative practices; these 329 would eventually be published as Best Current Practices (BCP) RFCs. 330 That process would begin after the initial community consensus. 332 1.4 Criteria for Judging an Administrative Restructuring 334 The guiding principles in the analysis of the administrative 335 restructuring are the criteria specified in [RFC3716], Section 3. 336 These criteria are worth restating: 337 1. Better resource management: 338 1.1 Uniform budgetary responsibility. 339 1.2 A uniform view of revenue sources 340 1.3 Clarity in the relationship with supporting organizations. 341 1.4 Flexibility to provision and reprovision services. 342 1.5 Administrative efficiency. 343 2. Stewardship: 344 2.1 Accountability for change. 345 2.2 Persistence and accessibility of records. 346 3. A better working environment: 347 3.1 More service automation where appropriate. 348 3.2 Better tools. 350 1.5 Methodology 352 Preparation of this report began on June 18, 2004 as part of a 353 consulting engagement to support the IETF and IAB chairs in the 354 restructuring effort, based on their request for funding 355 restructuring activities which was approved by the Internet Society 356 Board of Trustees. The contract is attached as Appendix A. 358 The following steps were used to gather input to this report: 360 o Initial briefings and continued close coordination with the Chairs 361 of the IAB and the IETF. 362 o A series of consultations with members of the IAB and IESG through 363 teleconferences, one-on-one email and phone conversations, and 364 face-to-face discussions at IETF60. 365 o A series of consultations with staff, officers, and board members 366 of the Internet Society. 367 o Discussions, by phone, email, and in person, with the staff of 368 Foretec Seminars, the Internet Society, the RFC Editor, and the 369 IANA, as well as a series of discussions with management at host 370 institutions including CNRI, ISI, and ICANN. 371 o A large number (over 100) of discussions by phone, email, and in 372 person with members of the community, including former members of 373 the leadership, and individuals known to represent a wide variety 374 of views. 375 o A detailed examination of relevant finances, including the 376 financial reports and tax returns of organizations providing 377 various support functions to the IETF. 378 o A detailed examination of operational issues, including the 379 functioning of key applications such as the Internet-Draft 380 Tracker, the operational and planning aspects of meetings, and the 381 functioning of the core IETF network presence. 382 o A detailed review of relevant documents, including electronic mail 383 archives, plenary transcripts, and RFCs, particularly the process 384 BCP RFCs. 385 o In cooperation with legal counsel, a detailed examination of the 386 current contractual framework and options available for 387 incorporation or otherwise providing more formalization of the 388 existing administrative structures, as well as a detailed 389 assessment of potential risks and liabilities of such a 390 transition. 392 2. Analysis of Current Administrative Framework 394 2.1 Providers and Functions 396 The IETF is an "open global community of network designers, 397 operators, vendors, and researchers producing technical 398 specifications for the evolution of the Internet architecture and the 399 smooth operation of the Internet."[RFC3233] A variety of institutions 400 provide administrative support to the IETF community: 401 o The Internet Society is "the organizational home of the Internet 402 Engineering Task Force (IETF), the Internet Architecture Board 403 (IAB), the Internet Engineering Steering Group (IESG), and the 404 Internet Research Task Force." [www.isoc.org] [1] The Internet 405 Society is a 501(c)(3) corporation with total 2002 revenues of 406 $1,695,833 and expenses of $1,681,064, of which $763,423 was 407 allocated as program expense to support the Standards Pillar of 408 the Internet Society [ISOC-2002]. The 2004 budget for the 409 Internet Society is attached in Appendix B.2. The Internet 410 Society and the IETF cooperate closely in a number of areas, as 411 defined in [RFC2026], [RFC2028], [RFC2031], and [RFC3677]. 412 o Foretec Seminars, Inc., a for-profit subsidiary of the non-profit 413 Corporation for National Research Initiatives (CNRI), provides a 414 variety of support services, including the planning of meetings 415 three times per year, a network presence for IETF activities, and 416 secretariat services such as coordination of the flow of documents 417 through the IESG. CNRI is a non-profit corporation registered 418 under section 501(c)(3) of the US tax code [IRS] and has been 419 providing service to the IETF since 1986 (see Section 6 for more 420 details on these long-term contributions to the community). CNRI 421 owns approximately 96% of the shares of the Delaware-chartered 422 Foretec Seminars, Inc [CNRI-2002]. 423 o Since 1969, the Requests for Comments (RFC) document series and 424 the office of the RFC Editor has been hosted at the Information 425 Sciences Institute (ISI). The RFC Editor's office and submission 426 process is further defined in [RFC2223], 427 [I-D.rfc-editor-rfc2223bis], and [RFC2555]. 428 o The IETF has delegated the parameter registration function to the 429 IANA, which is hosted at ICANN. The relationship is defined in 430 [RFC2860]. IANA instructions for RFC authors are defined in 431 [RFC2434] and in [I-D.narten-iana-considerations-rfc2434bis]. 433 For purposes of this analysis, we will examine these institutions 434 using a 4-part taxonomy of functions: 435 o *Function 1: Administration.* This function includes program 436 management tasks such as contract administration. It also 437 includes any legal matters and issues of financial reporting and 438 transparency. 440 o *Function 2: Meeting Planning.* This function includes the 441 planning and management of large events such as the IETF meetings 442 held three times per year, as well as more specialized activities 443 such as retreats and interim Working Group meetings. 444 o *Function 3: Core Information Technology.* This function includes 445 most of the network presence of the IETF, including the basic 446 provisioning of computing resources (e.g., colocation, name 447 service, routing, transit), and core services such as mail, web 448 site, rsync, and FTP. 449 o *Function 4: Document and Information Flow.* This function 450 includes the flow of information through the IETF process. While 451 Function 3, Core Information Technology, provides the basic 452 platform, Function 4 uses that platform. For example, basic 453 configuration of Apache or a mail server is a core IT function, 454 while what goes on the web site and in particular email messages 455 is part of the document flow. Likewise, booking an appropriate 456 venue is a meeting planning function, but deciding the specific 457 agenda for a meeting is part of Function 4. 459 2.2 Function 1: Administration 461 A prime requirement of [RFC3716] was "clarity in the relationship 462 with supporting organizations." The IETF sits on, to paraphrase the 463 words of Brian Carpenter, a "four-legged" stool for administrative 464 support functions. Unfortunately, not all of the legs are fully 465 defined. 467 The most serious undefined area is the on-going relationship with 468 CNRI, which in turn subcontracts to Foretec Seminars, Inc., a 469 for-profit subsidiary. CNRI has provided secretariat services for 18 470 years, but there is no contract or memorandum of understanding with 471 the IETF that defines the relationship. When the arrangement was 472 first started, a few dozen people attended IETF meetings. Over time, 473 that grew to over a hundred attendees, then several hundred, and 474 today well over 1,000 people attend each meeting. The gentleman's 475 agreement was perfectly appropriate 18 years ago. But, [RFC3716] was 476 quite clear that today it is not a sufficient basis for managing 477 close to US$2 million in annual meeting fees collected on behalf of 478 the IETF community. 480 The lack of a specific contract between the IETF community and 481 CNRI/Foretec is one of the items noted in [RFC3716], however that 482 analysis also pointed to broader problems throughout the IETF 483 community. In general, the administrative and support relationships 484 have not been defined or kept up to date. That has led to a variety 485 of issues observed in interviews conducted for drafting this report: 486 o A lack of financial information. 488 o Confusion over intellectual property. 489 o Vague definition of the lines of authority in the contracting 490 relationship. 492 *Financial Information.* There is no systematic, comprehensive, or 493 timely reporting of financial information to the IETF leadership by 494 support organizations, nor from the IETF leadership to the IETF 495 community. 496 o Budgets are prepared at a very high level, are not based on 497 program goals prepared by the IETF leadership, and are not based 498 on historical information, such as actual versus budgeted results 499 in previous periods. This reduces the ability of the leadership 500 to participate in a meaningful budget-setting process. 501 o Financial reporting is also minimal: financial results are not 502 available during the course of the year, and have been typically 503 reported as late as 6 months after the close of the year. The 504 reports furnished to the IETF community are non-standard in 505 format, lack sufficient detail for evaluation, and are not 506 furnished to the IETF with an auditor's or accountant's statement. 508 *Intellectual Property.* In conducting research for this report, the 509 author noted a lack of clear definition of community intellectual 510 property. Because relationships with support organizations are 511 poorly defined, there is no clear, unambiguous paper trail that shows 512 that resources are held in trust for the IETF community and must be 513 managed in the public interest and in a manner that is responsive to 514 the IETF community. The IETF is a public standards-making 515 organization and a fundamental defining characteristic of the IETF is 516 the openness of the process [RFC3668]. All data, including 517 databases, correspondence, minutes, and other documentation of the 518 IETF operations or deliberations are an integral part of that 519 process. 521 *Definition of the Relationship* The third effect of a lack of a 522 concrete understanding has been an apparent deterioration in the 523 working relationship between the IETF leadership and support 524 organizations. In particular, a review of correspondence shows 525 numerous instances where requests for specific functions have led to 526 discussions over who has the right to request what. 528 While the lack of a formal relationship with CNRI and/or Foretec 529 Seminars is the most pressing issue in the Administration Function, 530 the [RFC3716] goals of "uniform budget responsibility" and "a uniform 531 view of revenue sources" are not being attained. In particular: 532 o The Internet Society provides a number of administrative functions 533 that go beyond the matters specified in [RFC2031]. While that 534 memorandum of understanding does cover the provision of insurance, 535 in addition to that task the Internet Society also provides 536 discretionary funds to the IETF and IAB Chairs, and funds the 537 operation of the IAB. These expenditures are reported the IETF 538 community based on totals with no detail. In addition, the RFC 539 Editor contract is not published, although the statement of work 540 and total expenditures are [RFC-SOW]. 541 o The IANA provides parameter registry services to the IETF. While 542 the substance of that relationship is defined in [RFC2860], the 543 host institution (ICANN) does not provide financial reporting at 544 sufficient granularity for an analyst to understand how much that 545 function costs and thus understand the level of resources being 546 used to perform that function. In addition, no public tracking of 547 requests or announcements of new registrations are provided, 548 making it difficult to estimate the workload. 549 o The IETF has no uniform reporting of overall financial results. 550 While the IETF Chair has posted financial reports as they are made 551 available, there is no single location where an interested member 552 of the community can get a fiscal picture of the operation of the 553 IETF over time, or examine a standards-compliant financial report 554 for a particular time period [FASB-117]. 556 2.3 Function 2: Meetings 558 IETF meetings revenues have traditionally funded a wide variety of 559 non-meeting support functions, such as the document tracking, 560 submission, and distribution systems. Meeting revenues make up the 561 largest single revenue stream for IETF support (see Appendix B.1 for 562 a summary of IETF financial information over the last 3 years). 564 The cost per attendee per meeting has stayed at roughly $200 and 565 average revenue per attendee has been roughly $450 over the last 3 566 years, though recent gross fees have been as high as $545 including 567 late fees. Note that the $200/attendee cost is only direct costs 568 incurred on-site, and does not include additional personnel, travel, 569 and other expenses from support organizations to plan and staff the 570 meeting. Appendix C contains a summary of meeting attendance, as 571 well as a summary analysis of revenue and expense figures. 573 Although the number of participants in the IETF process as a whole 574 appears to have been growing, the number of attendees at IETF 575 meetings has been steadily dropping from a previous peak. From 2000 576 to 2003 the drop was fairly dramatic, though the figures appear to 577 have stabilized recently. The drop in attendees from the previous 578 peak means a smaller number of attendees have been funding a largely 579 fixed cost of non-meeting expenses. 581 The meeting business is based on several cost factors. An 582 organization will contract with a primary hotel with a guaranteed 583 rental of a certain number of guest rooms. This is known as a "hard" 584 contract and requires an advance deposit of a negotiable amount of 585 the expected room revenue. 587 These amounts can be substantial. For example, a typical contract 588 where an organization is doing a one-time event might require 50% of 589 expected revenue deposited as far ahead as 90 days before the event. 590 In the case of a typical IETF meeting, this might be 1,000 rooms at 591 $150/night for 5 nights, or a 90-day deposit of $375,000. Proper 592 negotiation of long-term relationships can reduce these cash flow 593 requirements by an order of magnitude. 595 In addition, the IETF requires certain facilities provided by the 596 hotel, such as audio visual equipment, electrical services, and food. 597 In the U.S., meeting rooms are often provided at no charge, but only 598 after matters such as food have been negotiated. In non-U.S. 599 venues, the cost for meeting rooms can be as high as $125,000. 601 The planning and execution of an event such as this, particularly 602 three times per year, requires experienced professionals. There are 603 a number of companies and free lance professionals that specialize in 604 organizing meetings for professional groups. Many of these companies 605 have become quite adept at computer networking, and if properly 606 assisted in areas such as routing and the DNS, could do a very 607 credible job for the IETF. It is important to note that IETF 608 meetings have been organized quite skillfully over a number of years 609 and attendees have become accustomed to this level of 610 professionalism. It is important that the IETF maintain those 611 standards. 613 Assistance from members of the community is an important part of 614 staging an IETF meeting. In addition to formal secretariat 615 activities, at least three teams of volunteers have been active 616 recently: 617 o For all unhosted meetings, and for most hosted meetings, a NOC 618 team of volunteers has helped establish a wireless infrastructure, 619 provisioned external lines and transit, managed DNS, and provided 620 a wide variety of other core services. At IETF60, the lead 621 engineer for this activity was Jim Martin. 622 o A team of volunteers organized by the University of Oregon's Video 623 Lab produces audio and video streams from IETF meetings (as well 624 as NANOG and a variety of other events). 625 o A team of volunteers organized by xmpp.org [2] manages a series of 626 XMPP[I-D.ietf-xmpp-core] servers which are used for general 627 commentary by participants, creation of informal transcriptions 628 which are archived, and for a variety of personal productivity 629 enhancements [Bingo]. 631 Over the years, a variety of other efforts have sprung up and 632 disbanded aimed at deploying leading-edge technologies in the meeting 633 network for interoperability testing or to familiarize attendees with 634 new protocols. Some of these activities, such as PGP key signing 635 parties, are ongoing. Others have been organized as one-time events. 636 These ad hoc activities are an important part of IETF meetings. 638 These self-organized, volunteer efforts, benefit from coordination 639 with formal meeting planning functions. For example, the core 640 network group requires facilities and coordination with the hotel's 641 telecommunications service, while the audio/video effort requires 642 coordination with the hotel's audio-visual contractors. Currently, 643 none of these volunteer efforts is linked to from meeting web pages 644 which are maintained by CNRI/Foretec, and there is no IETF leadership 645 policy on this subject. 647 While the day-to-day operational aspects of meetings are extremely 648 well coordinated, long-range planning for IETF meetings is almost 649 non-existent. For example, by IETF60 in August, 2004, planning for 650 2005 meetings had not reached any apparent degree of closure. The 651 IETF leadership were unaware of any firm plans for Spring or Fall of 652 2005, and while some progress had been made in identifying a general 653 location for the Summer 2005 meeting, specific venues were still 654 being evaluated. 656 Long-range planning is absolutely essential in the meeting business. 657 Booking well in advance and using techniques such as repeat visits to 658 properties that are allied through common ownership or marketing 659 arrangements can lead to dramatic reductions in guest room rates, 660 deposit requirements, and hotel charges. Long-range planning also 661 helps IETF meeting attendees plan their own schedules. For many 662 people, the commitment to go to an IETF is a major one, requiring the 663 use of vacation time, personal funds, and other resources. 665 Often in the past, a "host" has volunteered to assist in a meeting, a 666 task that traditionally consisted of organizing the terminal room 667 effort. The concept of a single host has, for recent meetings, been 668 supplanted by a series of sponsors who furnish specific resources, 669 such as bandwidth or equipment. Terminal room efforts have become 670 significantly easier as the IETF has shifted from importing hundreds 671 of bulky computers and terminals for attendees (see [RFC0015] for 672 more information on the concept of "terminals") to a wireless network 673 for laptops. The concept of "host" (or "primary sponsor") is 674 certainly a useful one, however instead of focusing on terminal room, 675 the device could be used as a way of defraying meeting room charges, 676 food, or other major expenses. 678 One final issue should be noted that has become apparent during the 679 course of research for this report. There appears to be no clear 680 guidelines on some issues related to the conduct of meetings, which 681 has led to disagreements between the contractor and the IETF 682 leadership. Two situations in particular are apparent: 683 1. Signage. In most association meetings, signage is strictly 684 controlled so that all sponsors and contractors (and in the case 685 of the IETF, volunteers) receive appropriate billing. There is 686 no IETF policy on this topic. The IETF leadership should 687 formulate such a policy. 688 2. Corollary activities. There have been several attempts to defray 689 meeting costs or increase profits through the use of trade 690 exhibitions, user groups, engineering task forces, and various 691 other activities affiliated loosely or closely with an IETF 692 meeting. Any policy on colocation of related events at an IETF 693 meeting is a policy matter that should be under the direction of 694 the IAB and IESG and ultimately the IETF community. The IETF 695 leadership should formulate such a policy. 697 2.4 Function 3: Core Information Technology 699 While meetings provide an important part of the IETF process, it has 700 always been a basic policy of the community that participation in 701 meetings is not required to participate in the IETF. Mailing lists, 702 document submissions, and other aspects of a continuing network 703 presence are a core part of the IETF. 705 As noted above, this analysis divides that network presence between a 706 core information technology function, which is discussed here, and 707 the uses of that network, which is described in the next section. 709 Unfortunately, the IETF does not do a very good job of providing a 710 network presence for its own activities. 712 There are many opinions about how "good" or "standards-compliant" or 713 "well-provisioned" a network infrastructure should be for any 714 particular activity. However, by most standards, it is hard to argue 715 that the IETF is using the technology effectively. A comprehensive 716 analysis of network performance is impossible simply because 717 statistics and logs or any other reporting is not available. 718 However, a few anecdotes will serve to illustrate the point. 720 There are six Web sites that contain information important for IETF 721 participants. None of these Web sites, as of August 13, 2004, were 722 compliant with the W3C Validation Service and with published HTML 723 standards: 724 o http://www.iana.org/ [3] 725 o http://www.rfc-editor.org/ [4] 726 o http://www.isoc.org/ [5] 727 o http://www.ietf.org/ [6] 728 o http://www.iab.org/ [7] 729 o http://www.irtf.org [8] 731 Likewise, none of these sites is reachable using IPv6. Search 732 engines on all four sites are primitive at best, and are not 733 operational in the case of www.iana.org and www.isoc.org. Few 734 attempts are made at authentication of information, domain names, or 735 applications. And, a comparison of the IETF home page from January 736 7, 1997 and from February 15, 2004 shows that it has remained 737 virtually unchanged during that period [Wayback]. 739 These are all anecdotal examples, but they certainly reinforce the 740 findings of [RFC3716] that the IETF does not use technology as 741 effectively as it could. 743 One function that appears sorely lacking on any of these systems is 744 the provisioning of shared environments for use by working groups, 745 directorates, the IAB, the IESG, and other groups. Working groups, 746 as part of the management of chartering activity, are able to specify 747 a web site and a mailing list, but there appears to be no mechanism 748 that allows a portion of the web, FTP, or other core operational 749 servers to be delegated for use by a particular group. 751 The result has been that working groups, teams and areas create a 752 diverse plethora of unconnected sites for handling IETF functions, 753 such as rtg.ietf.org, ops.ietf.org, edu.ietf.org, various issue 754 trackers, WG web sites and other tools hosted at diverse private web 755 sites, the availability of which is critically dependent on 756 volunteers - which are usually drawn from the WG. This is not 757 necessarily a bad thing, but as will be seen in Section 3.4, some 758 additional support might help meet goals such as the goal stated in 759 [RFC3716] of "persistence and accessibility of records." For example, 760 a systematic archiving facility can assist decentralized efforts, 761 unified search facilities might prove useful to those searching for 762 information, and one could certainly find many ways to improve the 763 navigation, presentation, and timeliness of the current IETF network 764 presence. 766 2.5 Function 4: Document and Information Flow 768 Function 4, Document and Information Flow, is the part that directly 769 supports the day-to-day functioning of the IETF. While core 770 information technology provides a web server or a mail server, this 771 function populates those servers with information based on the rules 772 defined in process BCP RFCs as well as various unwritten procedures 773 and customs. 775 A demanding part of the current IETF Secretariat is the process of 776 supporting the numerous bodies that proliferate through the 777 community. The IESG, of course, requires a great deal of support, 778 given their bi-weekly teleconferences, and the tremendous workload of 779 documents to consider, working groups to charter, and other functions 780 the group performs. The high workload of IESG members has been noted 781 repeatedly. 783 Many of the functions required to support a deliberative body such as 784 the IESG are ideally suited for a capable administrative office, a 785 task often labeled as "Clerk." In the U.S., for example, the "Clerk 786 of the Court" or "County Clerk" are key tasks in their respective 787 organizations. These officers and offices facilitate the flow and 788 archiving of information, providing both a human and a procedural 789 interface for disseminating information among participants in a 790 process. 792 The tasks that are encompassed in this function include: 793 o Supporting the working group charter process, which includes 794 processing the initial charter, rechartering, milestone 795 management, and closing of the working group. 796 o Publication of Internet-Drafts. It is assumed that current 797 efforts to automate the submission process will be successful, 798 alleviating much of the manual effort that this function currently 799 has. 800 o Document tracking, including a ticket-system-based response to 801 document and working group management problems, announcements of 802 last calls, and a variety of other functions. 803 o Managing IESG meetings, including scheduling, creation of the 804 agenda, and collecting the minutes, as well as the creation and 805 long-term archiving of IETF meeting proceedings. 806 o Handling the Intellectual Property Rights disclosure process (a 807 process which is presently undergoing automation). 808 o Publication of official actions, such as document approvals, 809 including communication of such status to groups such as the RFC 810 Editor. 811 o Registration and publication of liaison statements from other 812 standards bodies and publication of liaison statements, responses 813 and other communications by the IETF to Standards Development 814 Organizations (SDOs). 815 o Support of the Nominating Committee. 816 o Assisting the Meeting Planners in crafting an appropriate agenda 817 for the IETF meetings, a complex task that requires a fairly 818 detailed knowledge of the IETF operation. 820 A great deal of progress has been made in this area over the last 821 year, and more can be expected in the future with the active 822 participation of a new Tools group and of IESG members. However, 823 there is still substantial work to make the flow of information 824 smoother and more predictable. For example, even though the 825 Internet-Draft, RFC, and IANA processes are all closely linked in 826 theory, in practice each organization currently maintains their own 827 tracking system. In the case of the IANA, that tracking system is 828 not visible outside of the organization. Thus, interaction among 829 these three bodies often relies on personal communications, and there 830 are fairly frequent issues of tokens being lost, or "customers" 831 (e.g., the author of a particular draft) being unclear where in the 832 process they are. 834 3. Recommendations for Restructuring the Administrative Framework 836 This section contains recommendations for changing how the day-to-day 837 support functions are provided. Issues such as how to contract for 838 services and whether or not a full-time staff member should be hired 839 are dealt with in this section. Section 4 discusses the 840 institutional framework in which these activities can be housed, 841 including issues such as whether to incorporate the administrative 842 entity. 844 3.1 Recommendation 1: Hire An Administrative Director 846 The deliberations of the Problem Statement Working Group made it 847 clear that the IESG and IAB are both overworked with an increasingly 848 large flow of technical issues. The group also made it clear that 849 the IETF Chair and the IAB Chair should continue to be picked for 850 their ability to lead the IETF technical activities, not solely on 851 their ability to create a conformant income statement [RFC3774]. 853 One key cause of the current ambiguous management structure is the 854 lack of even one full-time staff member who reports directly to the 855 IETF leadership. For example, the IETF Chair and IAB Chair attempt 856 to prepare an annual budget and do financial reporting, but they do 857 so without any professional help. Among leading standards 858 organizations, the IETF is alone in failing to provide any staff to 859 assist the leadership in such activities. 861 While zero staff is a non-standard way to run a standards body, a 862 large staff would run counter to a long-established feeling 863 throughout the community that the creation of a large bureaucracy 864 would go against the fundamental tenets of how the IETF operates. 866 In the IETF, there thus appears to be a philosophy that strongly 867 favors outsourcing services whenever possible. A first step would be 868 to hire a single staff member, an Administrative Director. This 869 position would be responsible for tasks such as hiring and working 870 with contractors, managing finances, and working with other 871 professionals such as lawyers and auditors. A decision on whether or 872 not the ultimate size of the support staff remains at 1 or grows very 873 modestly thereafter can be deferred. 875 This is a fairly demanding position, as it requires a firm knowledge 876 of business fundamentals, such as budgeting, contracting, logistics, 877 and MIS operations. The successful applicant for such a position 878 would also have to either be already familiar with the IETF or be 879 able to quickly assimilate the culture. Prior knowledge of IETF 880 politics should not be prerequisite for this position, but since an 881 Administrative Director would have to work on a day-to-day basis with 882 a decentralized, consensus-based community, the position will require 883 a certain level of political sensitivity. The position will also 884 require a certain technical cluefulness, though again, such skills 885 could be acquired on the job in certain cases. 887 Creation of this position should be fairly straightforward. First, a 888 job description should be created. The position can be advertised 889 using a variety of media, ranging from the IETF mailing lists to more 890 formal mechanisms such as advertisements in publications such as the 891 International Herald Tribune, the New York Times, the Economist, or 892 the Wall Street Journal. A yet more formal strategy would be to 893 engage a professional search firm. 895 Evaluation of applicants might consist of a search committee 896 appointed by the IETF Chair. The committee would conduct an initial 897 review of applications, possibly solicit additional applications, and 898 present a short-list for further consideration. This short list of 899 applicants could be reviewed by the IESG and IAB, possibly with 900 further interviews. The IESG and/or IAB should specify this 901 procedure more fully before beginning the search. 903 As part of the drafting of a call for applicants, the IETF leadership 904 may want to consider what the IETF leadership groups need in the way 905 of support and how they can structure the position in a way that 906 attracts the best applicants. For example, procedural mechanisms 907 such as explicitly allowing the staff to be present on mailing lists, 908 teleconferences, and meetings may be necessary before applicants will 909 consider the position one which is doable. 911 A sample draft Call for Applications is attached as Appendix E. 913 3.2 Recommendation 2: Establish Contracts for Core Services 915 The lack of a contractual basis for present services is, as discussed 916 earlier, a historical artifact of the dramatic growth of the IETF 917 from a few to a few hundred to several thousand participants. 919 Establishing a formal basis for such services by the close of this 920 calendar year is a fundamental recommendation of this report. A 921 formal understanding for support services can take several forms, 922 including contracts or memoranda of understandings. Since the IETF 923 is based on an open process, it is important that all significant 924 contracts be published so they have formal standing within the 925 context of the IETF community. Such publication can be on a web 926 site, or can be a republication of the contract in the RFC series. 928 Just as a contract should be published as an RFC so they have formal 929 standing in the community, it is important that any Memoranda of 930 Understandings published as an RFC have similar standing in the legal 931 world. It is important that such contracts or memoranda have 932 adequate legal review to insure that the key elements required in 933 contract law are present. 935 For organizations providing support services who are not presently 936 under contract, there are two broad strategies that can be used to 937 move from the present administrative framework to the more formal one 938 proposed here: sole source procurement or a Request for Information 939 (RFI) or Request for Proposals (RFP) to solicit a variety of bids 940 from multiple vendors, including the present providers. 942 It is important to note that with the present granularity of 943 historical financial information, an RFP will be an essential part of 944 understanding the various expense models associated with different 945 services levels and provisioning strategies. 947 A decision also has to made whether the current services are 948 monolithic or can be decomposed into separate pieces. A case can be 949 made that a single vendor for most services can provide the most 950 responsive service. Alternatively, one could argue that some 951 services are specialized, such as meeting planning, and might be 952 better carried out by a specialist. 954 A final factor comes into play, which is the risk to continuity of 955 operations caused by any transition. There is also a financial cost 956 to any transition, including capital costs (e.g., acquiring 957 sufficient assets to do the job), cash flow requirements (e.g., hotel 958 deposits for meetings can be substantial), and professional help 959 (e.g., lawyers, accountants, and a variety of other services). 961 There are thus a spectrum of options available within the extremes of 962 RFP and sole source procurement. This report recommends one of the 963 following three strategies: 964 o *Strategy 1.* Issue an RFP for all core secretariat services. 965 This would allow the current provider to bid and thus establish 966 contract terms upon a successful bid, but would also allow other 967 vendors to compete. 968 o *Strategy 2.* Attempt to negotiate a sole source procurement on 969 all of the functions, but after a designated time-out period 970 (e.g., 30 days), if the negotiation is not successful, issue an 971 RFP. The term of the sole source procurement could be a subject 972 of the negotiation, or a fixed term (e.g., 1 year) could be 973 established a priori. The intention would be to issue an RFP for 974 the subsequent contractual period. 975 o *Strategy 3.* Some combination of the two above options. For 976 example, attempt a sole source procurement on two of the three 977 functions, and issue an RFP for the third. 979 Based on research conducted for this report, the author is of the 980 opinion that meetings and the core "Clerk" functions would be the 981 most difficult to transition to a new provider. Meetings are 982 difficult because of long lead times (and an RFP process would 983 further delay 2005 planning unless an interim planning process can be 984 established). The "Clerk" functions have a great deal of 985 institutional knowledge, much of which is not properly documented. 987 Thus, the author of this report recommends that, if a hybrid strategy 988 of attempting a sole source contract on two functions and an RFP is 989 used for the third function, that core network services is a good 990 candidate for an RFP and meeting planning and "Clerk" functions would 991 be a good candidate for sole source procurement negotiations. 993 Providing a computing infrastructure is an area with many qualified 994 professionals and some well-established industry norms. This 995 strategy would also allow the IETF to move core archives that are 996 presently decentralized into a common infrastructure, would provide 997 more flexibility to provide resources to workgroups, and would allow 998 non-contractor developed tools to coexist with existing resources. 1000 If an RFP is not issued a particular function, then a sole-source 1001 contract negotiation would be used. There should be a clear 1002 understanding on intellectual property ownership, in particular a 1003 clear statement about all information flowing through the IETF 1004 process belonging to the IETF community, including the following: 1005 1. Domain names, including iab.org, ietf.org, iesg.org, and 1006 irtf.org. 1007 2. Content of Internet-Draft directories. 1008 3. Content of Web sites. 1009 4. Subscriber lists for all mailing lists (public and private). 1010 5. Mailing list archives for all archived mailing lists (public and 1011 private). 1012 6. Working group database content including charters. 1013 7. Internet-Draft history database content. 1014 8. Internet-Draft tracker database content. 1015 9. Meeting minutes. 1016 10. Meeting attendance records, including "blue sheets". 1017 11. Archive of expired Internet-Drafts. 1018 12. Documents relating to the creation and reporting of working 1019 group status. 1020 13. Copies of any other IETF information including correspondence 1021 and historical records. 1023 In addition to intellectual property considerations, any contract 1024 negotiation should be bounded by two other parameters: 1025 1. A transition clause is essential to allow for an orderly 1026 transition to other vendors in the future. For example, if 1027 meetings are provided on a one-year support contract, but meeting 1028 venues are being booked on a longer time scale, a clause in the 1029 contract would allow the transfer of venue to a new contractor. 1030 In addition, a fairly standard clause in many such contracts 1031 would allow the ability for a new contractor to issue employment 1032 offers to non-managerial employees of the old contractor as a 1033 transition mechanism. 1034 2. A negotiating period time-out clause is essential in such a 1035 process. This report recommends that a small team be assembled 1036 to negotiate such contracts under the direction of the IETF and 1037 IAB chairs, reporting back for the advice and consent of the IAB 1038 and IESG, and that any resulting contract be published. If 30 1039 days lapse and no agreement is reached, the IAB and IESG should 1040 have the option, after reporting back to the community, of either 1041 extending the negotiating period for an additional 30 days, or 1042 issuing an RFP. 1044 While establishing a contract for uncontracted services is absolutely 1045 essential, some attention should also be paid to services provided by 1046 the IANA or the RFC Editor. For example, returning to a multi-year 1047 contract with the RFC Editor instead of the current one-year 1048 extensions might provide for a larger investment in the function by 1049 the host institution. Likewise, agreements with the Internet Society 1050 and ICANN should be kept current. 1052 3.2.1 Details of Potential RFP Components 1054 3.2.1.1 Structure of the RFP 1056 Part of the philosophy of the IETF support process is to not make 1057 large organizations whose sole purpose is to support the IETF. This 1058 is still a valid approach. 1060 In recent years, the support for the IETF has been carried out by a 1061 small number of organizations working on fairly unconnected tasks 1062 (RFC Editor at ISI, IANA at ICANN and secretariat and meeting 1063 services both handled at Foretec). 1065 Each organization has provided its own facilities for storage, 1066 publication, information distribution and list maintenance, as they 1067 saw it required for their tasks. This is not necessarily an optimum 1068 distribution of resources. One could imagine multiple models, 1069 including: 1070 o The IETF controlling a distributed compute platform and storage 1071 facility, with multiple organizations using that to perform work 1072 under contract, and using each others' services when appropriate 1073 (management of the platform being of course one such contract). 1075 o A distribution much like the present, where suppliers bring their 1076 own resources, but with tasks distributed differently, with (for 1077 instance) meeting planning and Web presence maintenance being 1078 separate tasks, but with increased emphasis on information sharing 1079 and open access to information. 1080 o An even larger concentration of roles, where one service 1081 organization takes on tasks that are distinct today. 1083 There is not sufficient information on price, performance or benefits 1084 of the various approaches today. A Request for Proposals process, 1085 however, would generate the necessary information. An RFP process 1086 where the components of the work are separated out to the largest 1087 extent practical will encourage the people who offer proposals in 1088 response to tell explain which parts of the RFP they would be willing 1089 to take on, how they would get synergy out of combining them, and 1090 what services they would be capable of using from other providers. 1092 The RFP is an information gathering tool, and will be followed by 1093 extensive negotiations and planning on how the services the IETF 1094 needs can be supplied. This needs time, and because of this, sending 1095 out an RFP earlier rather than later in the decision process will 1096 provide important input used to structure the work to be performed. 1098 A draft RFP is contained in Appendix F and picks the following 1099 decomposition: 1100 1. Provision of the Core Network and Systems 1101 2. Systems Administration 1102 3. Mailing list management 1103 4. The Web presence 1104 5. Meeting planning 1105 6. The Clerk of the IETF 1107 The RFP is structured so proposals may be received for one or more of 1108 the above requirements. A single bidder may elect to provide all 1109 functions, one function, or some combination. The RFP is structured 1110 to include a review process, and the selection criteria are based on 1111 what is best for the IETF as a whole, as opposed to a single formula 1112 such as lowest price. 1114 One important factor in all bids for supporting service will be the 1115 degree of continuity and accountability. A "key person" principle is 1116 proposed where an individual contact is identified as responsible 1117 manager for the function. It is this person who will give guarantees 1118 to the IETF for the services being available to the IETF with 1119 adequate availability and response times, and who will take charge of 1120 the organization that supplies the services. 1122 The terms "Request for Proposals" (RFP) and "Request for Information" 1123 (RFI) bear a brief explanation. A wide variety of organizations use 1124 formal and open procurement processes. Some of the better known 1125 entities, particularly government agencies, have an extremely 1126 rigorous process defined in the RFP announcement, including metrics 1127 for decision, such as a formula for calculating a final score based 1128 on price and a metric such as average panel rankings on subjective 1129 criteria such as "quality" or "responsiveness". A process this 1130 rigorous would probably not give the IETF administrative entity much 1131 flexibility in crafting an appropriate solution. 1133 A "Request for Information" often suggests that a final decision will 1134 not be based on the initial information submitted in the call for 1135 proposals. Rather, the RFI is used to put together a short list of 1136 potential candidates, and engage in negotiation and reformulation of 1137 the proposals. 1139 In either case, the term used really does not matter nearly much as 1140 the terms specified in the call for proposals. The label is fairly 1141 irrelevant and the real meaning is specified in the details. A call 1142 for proposals could easily bear either label. 1144 3.2.1.2 Core Network 1146 Currently, the IETF does not own any computers, colocation space, or 1147 transit capacity. Indeed, the IETF does not even run a web site. 1148 All of these functions are contracted out, and the contracts include 1149 full provisioning of the underlying infrastructure. As mentioned 1150 above, this is only one possible arrangement. We do not have data 1151 that will allow us to know what to choose between the alternatives 1152 here. 1154 If adequate resources can be obtained at the right price, including 1155 servers, colocation space, and bandwidth, and if those resources meet 1156 the high standards needed to sustain IETF operations, the best thing 1157 for the IETF may be to operate on such an infrastructure. Having an 1158 adequate in-house infrastructure controlled by the IETF also provides 1159 substantial flexibility in the case of future transitions of key 1160 contractors, but it also burdens the IETF with the requirement to 1161 maintain and replace equipment. 1163 An organization able to provide highly competent systems 1164 administration would be needed to support a solid computing platform. 1165 If purchased at commercial rates, this would probably be a 1166 significant part of the cost of this way of supporting services. The 1167 RFP process will tell us what we can depend on. 1169 In terms of volunteer contributions for specialized areas such as 1170 nameservice or routing, the IETF may be able to draw upon volunteer 1171 help from participants. It would make sense to have the relationship 1172 with the volunteer be slightly formalized, including a public 1173 appointment to the named task. This impresses upon all that such a 1174 task is one of trust and makes the community aware that the 1175 individual or organization has assumed this particular 1176 responsibility. 1178 3.2.1.3 Mail 1180 The IETF is a mail-intensive operation, with mailing lists for 1181 working groups, directorates, the IESG, the IAB, and a raft of other 1182 lists, not to mention the core IETF and announcement lists. 1184 Certain specialties in computing are considered an art unto 1185 themselves. Mail is one of those areas. The IETF Administrative 1186 Entity should simply contract the postmaster function to a vendor 1187 experienced in running environments characterized by high-volume mail 1188 servers, large numbers of lists with various access and moderation 1189 policies, a stringent archive requirement, and an ability to 1190 implement appropriate filtering policies (where the policy, of 1191 course, is ultimately set by the community). 1193 This task is as much a public service position as it is a contract. 1194 The task of postmaster to the IETF Administrative Entity should be 1195 sufficiently attractive that it will attract highly capable bids. 1197 Since a variety of provisioning options are available for this 1198 service, the evaluation process should carefully consider each 1199 proposal for criteria such as stability of service and infrastructure 1200 redundancy. 1202 3.2.1.4 Community Workspace Support and the IETF Network Presence 1204 The IETF needs far better support for our various groups that wish to 1205 maintain a network presence. While the core document submission 1206 process is highly structured, currently the operation of individual 1207 working groups, directorates, or other groups all have very different 1208 styles. A variety of styles is a Good Thing and should be supported. 1210 Systems administration can provide core tools such as web servers, 1211 FTP servers, and can allocate space to groups. However, an effective 1212 network presence for the IETF involves many issues about how we 1213 archive our information, how we make it easy for new groups to form 1214 workspaces, and how we interface to our data through search and 1215 navigation facilities. 1217 Core systems administration is on a different layer of the stack than 1218 the applications support that is needed to help maintain a 1219 productive, happy community with a clueful Internet presence. 1221 It is proposed that the IETF Administrative Entity needs a webmaster 1222 to supplement the resources of the systems administrators. The 1223 sysadmin can install Apache with appropriate modules, but building a 1224 core web site for the IETF involves other skills, including knowledge 1225 of CSS, HTML, XML, and a variety of scripting skills in languages 1226 such as PHP or PERL or TCL (pick your poison). 1228 At first glance, this may seem to be a development effort, not an 1229 ongoing operations effort. However, we believe a more sustainable 1230 system can be built with a webmaster task which combines on-going 1231 responsibility for access to the core IETF information along with a 1232 support role for the broader community of working group chairs, 1233 directorates, and the like. 1235 3.3 Recommendation 3: Provide Timely and Uniform Financial Reporting 1237 This report recommends that all available historical financial 1238 information be posted in a single public location, and that an 1239 immediate commitment to post more complete and timely financial 1240 information in the future be made. 1242 In addition, the IETF leadership should begin formalizing the budget 1243 process in anticipation of any administrative restructuring efforts. 1244 Once issues of an institutional home for administrative functions 1245 have been decided, a full budget with program goals, including any 1246 relevant transition expenses and a cash flow analysis, will be 1247 required by any potential groups helping finance the IETF 1248 Administrative Entity as part of the funding group's annual budget 1249 planning processes. 1251 These functions are all envisioned to be the primary responsibility 1252 of the Administrative Director, with some contractor assistance for 1253 accounting and auditing tasks. 1255 3.4 Recommendation 4: More Focus on Archives 1257 [RFC3716] stressed the importance of proper attention to the 1258 persistence and accessibility of records, including the requirement 1259 that "the IETF needs to maintain and support the archiving of all of 1260 its working documents in a way that continues to be accessible, for 1261 all current and future IETF workers." The IETF does not currently 1262 meet that requirement. In particular: 1263 o Although the RFC Editor maintains an "RFC-Online Project", over 1264 200 RFCs have yet to be put online. 1265 o Archives of IETF working group mailing lists are spotty and 1266 sometimes unreliable. 1268 o The ietf.org Web site does not include a comprehensive archive of 1269 all Internet-Drafts, though several volunteers in the community do 1270 maintain such sites on an informal basis. It should be noted that 1271 this lack of a public comprehensive archive is a policy decision 1272 of the IESG. A private comprehensive archive is a legal 1273 requirement, as the IETF is the original publisher of 1274 Internet-Drafts and is sometimes asked for old drafts in cases 1275 such as patent disputes. Even if the archive is not available on 1276 a public site, regular audits of the completeness of the archive 1277 are necessary. 1278 o On a short-term basis, there is no adequate backup for the 1279 www.ietf.org web site, which has led to periodic accessibility 1280 issues. 1281 o Although videolab.uoregon.edu has an archive of past meeting audio 1282 and video feeds, that archive only dates back to IETF49. 1284 More attention to this important area is recommended as a key 2005 1285 goal. 1287 4. Options for an Institutional Basis for Administrative Activities 1289 4.1 Discussion of Organizational Form and Legal Domicile 1291 This report frames the question of organizational form as follows: 1292 o Should the IETF administrative support organization be 1293 incorporated? 1294 o If so, should it be now or later? 1295 o If so, what domicile and specific form should be chosen? 1296 o If so, what would be the specific nature of the relationship 1297 between any potential new organization and the Internet Society? 1299 As seen above, there is a close relationship between ISOC and the 1300 IETF that is independent of the administrative restructuring of IETF 1301 support. 1303 The requirements for the relationship between the IETF Administrative 1304 Entity and the IETF Community are: 1305 o The process must generate the support that the IETF needs. 1306 o The process must be transparent; people and organizations who 1307 donate money to the standards process must be able to verify that 1308 the funds have been spent on effective support of the standards 1309 process. 1310 o The process must be efficient; the overhead of a large bureaucracy 1311 is not in the best interest of the IETF. 1312 o The process must be flexible enough to allow the IETF support 1313 structure to adapt to changing IETF community requirements. 1314 o The administrative entity must be responsible to the IETF. 1316 As an aide for discussion purposes, this report proposes four 1317 scenarios: 1318 o *Scenario A.* The Internet Society role as legal home of the IETF 1319 is augmented to include the new administrative function. As 1320 issues arise in the future, appropriate memoranda of understanding 1321 or other formal checks and balances can be developed. 1322 o *Scenario B.* As in Scenario A, the Internet Society's role is 1323 augmented to include administration of IETF support functions. 1324 However, instead of waiting to understand what the issues are, the 1325 IETF takes proactive steps to take a more fundamental role in the 1326 Internet Society as its administrative home. Thus, the difference 1327 is that in Scenario B, more time is spent up-front on formal 1328 definition of the relationship. Needless to say, more up-front 1329 definition is sometimes a good thing, but can also lead to a great 1330 deal of time solving problems that don't exist. 1331 o *Scenario C.* This scenario says that the IETF community is ready 1332 and willing to undertake the responsibilities for managing its 1333 administrative efforts. A new incorporated body is formed to 1334 house those functions. That body would be closely tied to the 1335 Internet Society through a variety of mechanisms that show that 1336 the two entities are part of a "symbiotic whole." 1337 o *Scenario D.* As in Scenario C, a new incorporated body is formed 1338 to house the administrative support functions. But, instead of 1339 being as closely linked to the Internet Society, the entity bears 1340 much more of the burden of setting up an infrastructure. In this 1341 scenario, the IETF community is now completely responsible for 1342 ensuring all aspects of its continued, long-term financial 1343 viability. 1345 4.2 Scenario A: ISOC Operating Unit 1347 Presently, the Internet Society administers the RFC Editor contract 1348 under the direction of the IAB, provides the IAB and IETF 1349 discretionary funds, and purchases insurance to cover some people 1350 involved in IETF decision making. The Internet Society also raises 1351 all funds need in excess of those provided by IETF meeting revenue. 1352 In this scenario, the Internet Society simply augments their current 1353 provision of services with appropriate contracts and program 1354 management services to manage the core IETF support contracts, 1355 including a significant number of large and small meetings, a fairly 1356 complex Clerk's Office, and a significant Internet presence. 1358 In this scenario, the Internet Society would employ the 1359 Administrative Director proposed in Section 3.1. The job search 1360 would be conducted in consultation with the IAB and IESG. That 1361 employee would in turn, again in consultation with the IAB and IESG, 1362 manage any sole source procurements or RFP processes that are 1363 approved by the Internet Society in consultation with the IAB and 1364 IESG. The IETF activities would appear as line items in the Internet 1365 Society budget, with revenue and expenses clearly allocated by 1366 program area (as they currently are on ISOC financials). 1368 4.2.1 Division of the Internet Society 1370 In this scenario, the IETF administrative activities would be 1371 undertaken as a Division of ISOC. It would have as its day-to-day 1372 operational head a senior Administrative Director who would have 1373 operational responsibility for all the IETF administrative activities 1374 on behalf of the IETF community. This individual would be an 1375 employee of ISOC, but management oversight would be structured to 1376 include direct IETF involvement including the IETF and IAB Chairs, 1377 and/or an Oversight Committee appointed by some IETF-specified 1378 process. 1380 Budgets would be established each year in consultation with the IAB 1381 and IESG, and approved by the ISOC Board as well as the IETF 1382 leadership. The IETF Division would have its own bank account and 1383 the Administrative Director would collect and manage all receipts 1384 (including revenues from ISOC destined for the IETF) and 1385 disbursements. Operationally, this reserves for the IETF Division 1386 the ability to prioritize and re-allocate funds within the 1387 constraints of the approved budget as seems best and will provide 1388 maximum flexibility in service provisioning. Once the budget has 1389 been agreed upon it would be the responsibility of the IETF 1390 Administrative Director to manage it. All IETF finances would be 1391 separately accounted for and fully transparent. 1393 In particular, 1394 o The IETF Administrative Director would have ISOC signatory 1395 authority for IETF contracts and would be responsible for managing 1396 all contractors/vendors to the IETF. 1397 o The responsibilities that the IETF Administrative Director would 1398 have with respect to IETF activities would be determined by 1399 standard IETF processes (BCPs, RFCs, etc.) 1400 o The Administrative Director would be hired (and removed) jointly 1401 by the IETF Chair, IAB Chair and the ISOC CEO according to a job 1402 description established by the IETF community. Performance would 1403 be evaluated by those same individuals, and the personnel home for 1404 the Administrative Director would be in ISOC (benefits, pension, 1405 medical, etc.). 1406 o The IETF Administrative Director could draw upon the other 1407 resources (accounting, technical infrastructure, reception, legal, 1408 etc.) of ISOC. 1410 4.2.2 Intended benefits 1412 By hosting the IETF administrative activity within an existing 1413 organization, there is the possibility of cost reduction by sharing 1414 resources. This proposal would give closer and more flexible access 1415 to a broad range of skills and competencies (e.g., sharing portions 1416 of employees time as needed). Note: IT facilities is one area where 1417 the IETF may need separate support/facilities. 1419 Under this model, the IETF could continue to expect ISOC to take a 1420 significant fallback responsibility for any liabilities, whether 1421 financial or legal, that might be incurred by the IETF. 1423 This model also provides an unambiguous fund-raising model, in which 1424 the possibility of confusion between ISOC and IETF efforts is 1425 minimized. 1427 4.2.3 Additional Considerations 1429 One of the considerations from which the IETF has long benefited is 1430 the current separation between corporate donations and IETF actions. 1432 Instantiating this scenario would require continued care to ensure 1433 that the IETF maintains a reasonable distance from the funding 1434 streams (apart from meeting fees) and minimizes the potential of 1435 conflicts of interest with funding sources and other perceptions of 1436 excessive influence by particular participants or their 1437 organizations. 1439 While standards have always been an important component of ISOC's 1440 activities, ISOC as a whole does have a broader mandate, and its 1441 Board must be selected and empowered to meet that broader mandate, 1442 not just the IETF's needs. Nevertheless, from ISOC's perspective, it 1443 is by design and in the governance structure, very complementary and 1444 ISOC has always seen its core responsibility as being to the IETF. 1445 The dedicated IETF Administrative Director and separated budget are 1446 seen as a means of ensuring continuous and adequate attention to IETF 1447 activities, and 3 IETF appointed seats on the Internet Society Board 1448 provides representation within the governing body. 1450 Under this model, the IETF administrative activity is naturally 1451 responsive to and part of the overall ISOC management structure and 1452 its evolution. That is, the scenario described here is modeled on 1453 ISOC's current management and mission structure, assuming that it 1454 will be largely static over time. ISOC has demonstrated several 1455 times in the past that it was willing and able to change its own 1456 governance structure in ways that benefited the IETF activity, and 1457 this specific proposal assumes that will continue to be the case, 1458 without making specific provision for ensuring it. 1460 As the Internet Society, and the Internet Society Board, would bear 1461 responsibility for making sure the continued IETF support function is 1462 carried out in a fashion that is responsible to and responsive to the 1463 IETF community, this scenario is potentially a large undertaking and 1464 should take careful consideration of the financial and logistical 1465 implications of undertaking such an operation and of the requirements 1466 of [RFC3716]. 1468 (Note that careful consideration of the responsibilities and the size 1469 of the undertaking applies to all actors in all scenarios, and 1470 applies equally to the Internet Society, the IETF community, and to 1471 any other support organizations.) 1473 4.3 Scenario B: More Formalized ISOC Operating Unit 1475 The philosophy in Scenario A is understand the basic parameters of 1476 how the relationship would work, but instead of spending considerable 1477 time defining all possible parameters, get to work quickly on 1478 pressing problems and deal with longer-term institutional issues as 1479 they come up or after experience is gained. Another strategy, 1480 outlined here as Scenario B, is to lay down more of those basic 1481 parameters about how the relationship would work, enshrining those 1482 parameters in a process BCP RFC. 1484 Scenario B leverages the benefits of Scenario A, while providing for 1485 additional mechanism further define the relationship of the Internet 1486 Society to the IETF community and what the provision of 1487 administrative support functions means. Scenario B is identical to 1488 Scenario A, but more up-front work is put into defining the 1489 relationship. 1491 These mechanisms are simply suggested directions to explore based on 1492 suggestions from early reviewers of this draft, and further 1493 discussions may add or remove mechanisms from this list: 1494 o Mechanism 1: Modify the Internet Society bylaws and articles of 1495 incorporation to explicitly recognize this expanded role and to 1496 explicitly refer to process BCP RFCs such as [RFC2026], [RFC3777], 1497 [RFC2418], and their successors as the governing mechanism for the 1498 standards process. [anchor24] 1499 o Mechanism 2: Re-task the three IETF appointees to the Internet 1500 Society Board of Trustees so that they are representatives of the 1501 IETF and can receive instructions from the IETF leadership on 1502 particular issues. [anchor25] 1503 o Mechanism 3: Give the IETF and IAB Chairs ex-officio, non-voting 1504 seats on the Internet Society Board of Trustees. 1505 o Mechanism 4: Grant the Administrative Director observer rights at 1506 Internet Society Board of Trustee and Executive Committee 1507 meetings. 1508 o Mechanism 5: Create a Memorandum of Understanding between the IETF 1509 and the Internet Society outlining operational parameters, such as 1510 how contract services get managed, how financial results are 1511 reported, and how other services such as insurance shall function. 1512 [anchor26] 1513 o Mechanism 6: Require that Internet Society meeting notices also 1514 include notice of consideration of issues affecting the IETF. 1515 This mechanism allows for community feedback on those issues prior 1516 to any decisions. A variant of this mechanism would allow the IAB 1517 and IESG to assert that a particular issue is critical to the 1518 functioning of the IETF, thus requiring a supra-majority of the 1519 Board to approve the action. 1520 o Mechanism 7: Hold an open ISOC annual Board of Trustees meeting at 1521 an IETF plenary meeting to facilitate more community 1522 participation.[anchor27] 1523 o Mechanism 8: Insert a sunset review clause in any operating 1524 agreement. A sunset review clause stipulates that after a period 1525 of time (e.g., 3 years), a review of operations is conducted. 1526 Often, this review consists of public input, a staff report, and a 1527 formal decision to renew or not renew the charter for an activity 1529 [Texas]. [anchor28] 1531 As noted above, these mechanisms are simply "straw-men" proposed by 1532 members of the community. Any decision to pursue this Scenario, as 1533 with all other Scenarios, will require a careful look at the specific 1534 language and provisions needed to meet the overall goals set by the 1535 community. As noted in Section 1.3, this would likely be in the form 1536 of a process BCP RFC. 1538 The intended benefits of this Scenario are as in Scenario A, with the 1539 additional intended benefit of bringing the IETF community and ISOC 1540 community more closely together to manage their futures. 1542 4.4 Scenario C: Well-Defined Entity With Close Ties to ISOC 1544 In this scenario, administrative support functions for the IETF are 1545 legally housed in a focused, incorporated institution (although the 1546 Administrative Directory might be physically housed within the 1547 Internet Society). This scenario, as well as Scenario D, raises a 1548 series of issues as to the form and legal domicile of such an 1549 organization. 1551 Scenario C envisions a number of concrete linkages with the Internet 1552 Society, which supplement the current close interconnection of the 1553 IETF community with ISOC. For example, under this scenario, primary 1554 fund raising responsibility would be invested in the Internet 1555 Society, allowing ISOC to create a unified fund raising voice 1556 (thought the proposed IETF Foundation would still be in a position to 1557 accept in-kind contributions). In addition to the fund-raising 1558 agreements, this Scenario envisions a variety of other linkages, such 1559 as continued cooperation on education and policy. 1561 4.4.1 How Scenario C Might Work In Practice 1563 There are a variety of legal forms that a formal IETF administrative 1564 support organization could take, but the public, non-commercial 1565 nature of the IETF standards process points fairly clearly to the 1566 formation of a non-profit organization of some sort. A non-profit 1567 organization, if formally recognized, has substantial benefits, such 1568 as exemption from income tax, relief from VAT and sales taxes when 1569 procuring services, and the ability for certain contributors to 1570 deduct donations made to the organization. 1572 It also seems important symbolically that any legal underpinning that 1573 creates an organization for administrative support functions should 1574 reflect the non-profit nature of the IETF as well as reflect the 1575 basic nature of the IETF, which has participants and not members. 1576 While there are numerous organizational structures available, the 1577 most straightforward form for the providing IETF administrative 1578 support is likely to be a non-profit corporation with no members and 1579 no stockholders. 1581 In addition, any formal organization for administrative support needs 1582 to take into account some of the unique characteristics of the IETF: 1583 o It is possible that none of the members of the board of the 1584 administrative support organization will come from the country 1585 that the organization is incorporated in. 1586 o The IETF already has a decision making process for a large number 1587 of our important decisions. The incorporating law should allow us 1588 to subordinate the administrative support organization to these 1589 already-existing processes, as they exist now and as they may 1590 change in the future. 1592 4.4.1.1 Where Might the Administrative Support Organization Be 1593 Domiciled? 1595 Perhaps the most difficult question to consider is which country the 1596 IETF support organization should incorporate in. A characteristic of 1597 the IETF is that we are individual participants. Unlike many 1598 standards bodies, the participants do not represent employers and, 1599 unlike the most formal standards bodies, participants do not 1600 represent countries. 1602 There is a predisposition to strongly consider countries other than 1603 the United States, simply because the IETF is an international group 1604 and a large number of key Internet institutions are already in the 1605 United States. Incorporation of the IETF administrative support 1606 organization is an important milestone, and a predisposition is to 1607 try to show diversity. 1609 Nonprofit incorporation in a number of countries with significant 1610 nonprofit sectors as well as a significant number of IETF 1611 participants was considered. These countries include France, Japan, 1612 the Netherlands, Switzerland, the United Kingdom, and the United 1613 States. 1615 Several countries were initially ruled out because their nonprofit 1616 laws do not permit entities that are not member-based, or have local 1617 requirements such as conducting business in a certain language. In 1618 other cases, there are difficult to meet local requirements for 1619 non-profits. For example, in order for an organization to qualify 1620 for tax exemption in the United Kingdom, an organization has to fall 1621 under one of four "heads" of charity. Three of these are 1622 general-purpose heads, including the relief of poverty, advancement 1623 of education, and the advancement of religion. However, none of 1624 these three are the intended direct focus of the IETF administrative 1625 support organization. The fourth category is "purposes beneficial to 1626 the community" and it appears that our local nexus to the country is 1627 somewhat slim and might be viewed somewhat skeptically by the Charity 1628 Commissioners. 1630 As part of this analysis, a "flag of convenience" approach, such as 1631 the Bahamas, was considered and ruled out. It does not seem that an 1632 off-shore registration poses substantial benefits and would certainly 1633 make it appear that the IETF administrative support organization 1634 perhaps had something to hide. This is clearly not appropriate. 1636 Incorporating simultaneously in several jurisdictions to make the 1637 point that the IETF is not part of any one country was also 1638 considered. As appealing as this is in theory, in practice it 1639 substantially increases the cost of incorporation, the complexity of 1640 on-going operations, and exposes the IETF administrative support 1641 organization to liability in multiple legal jurisdictions. 1643 After weighing a number of issues, it appears that the Netherlands, 1644 Switzerland, and the United States make the most sense. 1646 Either of these three jurisdictions would work. The IETF has strong 1647 participation from the Netherlands, and a number of nonprofit 1648 Internet groups have thrived in this environment. By contrast, we 1649 have far fewer participants from Switzerland. However, because 1650 Switzerland is not part of the European Union, it does not suffer 1651 from the potential risks of the more activist governmental presence 1652 in the EU and in the US. 1654 A U.S. non-profit, non-member corporation is being recommended under 1655 Scenario C, but with an important proviso. This recommendation is 1656 based on simple considerations of expediency and pragmatism: a 1657 transition will be simplest and least risky (in the short term). 1658 Since there are enough issues on the table, it seems easiest to 1659 simplify the equation by taking this variable out. The reasoning is 1660 as follows: 1661 o Administrative support for the IETF is currently enmeshed in a 1662 series of relationships with other institutions, most of which are 1663 also U.S.-chartered non-profit organizations. Any change in the 1664 institutional status of administrative support functions will 1665 require familiarity with U.S. nonprofit law. Incorporation in 1666 another country would require familiarity with those laws as well. 1667 Thus, the incorporation expenses would be higher and the process 1668 would take longer. 1669 o U.S. law has a strong concept of "nexus," which is a 1670 determination of when a foreign organization has enough 1671 relationship to U.S. law to fall under the jurisdiction of a U.S. 1672 court. Because of a long history of operating in the U.S., 1673 numerous meetings in the U.S., and the large number of U.S. 1674 residents who are participants and leaders, we feel it is likely 1675 that U.S. courts would find nexus in relation to our US-based 1676 activities, even if the IETF administrative support organization 1677 was incorporated in another country. In other words, 1678 incorporating in a country besides the U.S. does not necessarily 1679 free the support organization from any perceived vagaries of U.S. 1680 law. 1681 o Incorporating in a country other than the US may have tax 1682 implications if the Internet Society is providing funding support. 1683 o U.S. corporations have traditionally been large contributors to 1684 the development of public aspects of the Internet, a category into 1685 which IETF activities fall (and consequently, the activities of an 1686 IETF administrative support organization fall). U.S. 1687 corporations are somewhat chauvinistic, and it is our experience 1688 in raising funds that it is easier to get a donation if the 1689 recipient is a duly-chartered U.S. tax-exempt organization. Not 1690 surprisingly, non-U.S. corporations have shown more flexibility 1691 in this regard. Note that under this scenario, the Internet 1692 Society would take primary responsibility for fund-raising, 1693 however deductibility of donated resources such as computers and 1694 bandwidth is still useful. 1695 o It is very likely that an IETF administrative support organization 1696 would be deemed to clearly fall under the "scientific" and 1697 "educational" grounds for classification as a tax-exempt charity 1698 under section 501(c)(3) of the IRS code, so a tax-exempt 1699 application should be quite straight-forward. 1700 o The incorporation laws of the U.S. states being considered do not 1701 require that any members of the Board of Trustees be of a certain 1702 nationality or state residency (e.g., there are no "local 1703 director" requirements). The U.S. Dept. of Commerce 1704 foreign-controlled organization reporting requirements apply only 1705 to "business enterprises", and do not apply to non-profit entities 1706 such as an IETF administrative support organization. 1708 That said, it should be stated very clearly that any of the three 1709 incorporation domiciles (Switzerland, Netherlands, and U.S.) could 1710 probably be made to work. If the community feels a further in-depth 1711 examination of alternative domiciles is in order, and is willing to 1712 bear the increased costs of time and money, alternative domiciles 1713 could be more carefully examined. 1715 If incorporating in the U.S., Virginia seems a logical pick as the 1716 state of domicile to allow the IETF administrative support 1717 organization to make use of ISOC headquarters to house its single 1718 employee (though the employee might be able to be housed at the 1719 Internet Society even if the incorporation were elsewhere, for 1720 example the ISOC Geneva office). A variety of other options were 1721 examined as states of incorporation, including [Delaware] and 1722 [California], but there appeared to be no significant advantages. In 1723 particular, there are no significant differences in issues such as 1724 director liability that would make incorporating outside the place of 1725 actual domicile attractive. 1727 4.4.1.2 Sample Draft Core Principles 1729 [Ed.: This section intends to state basic principles of establishment 1730 and governance, suitable for publication, after considerable 1731 discussion, as a procedural Best Current Practice document.] 1733 4.4.1.2.1 Sample Draft Principles of Establishment and Governance 1735 The following principles are proposed for the establishment and 1736 governance of an administrative support organization in support of 1737 the IETF under Scenario C, and are based on the Sample Draft Articles 1738 of Incorporation attached in Appendix D.1 and the Sample Draft Bylaws 1739 attached in Appendix D.2: 1740 1. The name of the organization shall be the IETF Foundation. 1741 2. The IETF Foundation shall be incorporated under the laws of the 1742 State of the Virginia in the United States as a non-stock 1743 corporation with a domicile in the State of Virginia and shall 1744 apply for exemption from U.S. taxation under section 501(c)(3) 1745 of the Internal Revenue Code of the United States. 1746 3. The IETF Foundation shall have no members or shareholders. 1747 4. The IETF Foundation shall be governed by a Board of Trustees, who 1748 shall be responsible for the fiscal, legal, and administrative 1749 infrastructure that support the activities of the IETF. The 1750 governance of the IETF, the standards process, and all other 1751 aspects of how we make our standards are defined in the 1752 procedural Best Current Practice RFC series, which will be 1753 explicitly referenced in the organization documents of the IETF 1754 Foundation. 1755 5. The Board of Trustees shall consist of a fixed, odd number of 1756 members, initially set at 7 members. 1757 6. The annual meeting of the Board of Trustees of the IETF 1758 Foundation shall be announced on the IETF mailing list at least 1759 30 days before it occurs and must be held at a regular IETF 1760 meeting. This meeting shall be open to IETF attendees and 1761 minutes shall be promptly published. 1762 7. The Board of Trustees shall appoint a Secretary and a Treasurer, 1763 who need not be members of the Board of Trustees. The 1764 Administrative Director of the IETF Foundation shall provide 1765 staff support to the Board of Trustees. 1766 8. The Board of Trustees shall be composed to strike a balance 1767 between outside and "inside" directors. It is proposed that the 1768 IETF and IAB chairs hold voting, ex-officio seats, and that 1769 mechanisms such as the Nominating Committee and the appointment 1770 of certain seats by the Internet Society fulfill the outside 1771 director obligations. 1773 The Board of Trustees would have strong governance over a limited 1774 scope of activities (e.g., the fiscal, legal, and administrative 1775 infrastructure that are the charter of the IETF Foundation) but would 1776 have no authority over the IETF standards process. In this board 1777 composition, the ISOC and Nomcom appointments insure that outside 1778 directors with no perceived conflicts of interest are on the board. 1780 All nominating bodies should make strong fiscal, legal, and 1781 administrative acumen essential selection criteria for this position. 1782 However, we should note strongly that the Chairs of the IAB and IETF 1783 are ex-officio members (e.g., they are full voting members who hold 1784 the position based on their official roles as chairs of these two 1785 bodies), and that it is not expected that the current criteria for 1786 selection of these two positions should be changed. 1788 For position-based appointments such as the IETF Chair, the Trustee 1789 would serve concurrent with their normal appointment. For non 1790 position-based appointments, a term proposed for the nominated 1791 positions is three years with staggered appointments. However, the 1792 nominating body might have the power to change their appointee during 1793 their term. 1795 All members of the Board of Trustees IETF Foundation are subject to 1796 the same recall procedures in effect for the IETF leadership such as 1797 members of the IAB and IESG. [anchor34] 1799 4.4.1.2.2 Sample Draft Principles of Operation of a Potential IETF 1800 Foundation 1802 [Ed.: This section intends to state basic principles of establishment 1803 and governance, suitable for publication, after considerable 1804 discussion, as a procedural Best Current Practice document. This 1805 section is very tentative and contains principles that are used to 1806 draft bylaws and articles of corporation, samples of which are shown 1807 in Appendix D.1 and Appendix D.2.] 1809 The following are some general principles for the operation of the 1810 IETF Foundation: 1811 1. The IETF Foundation shall employ a Administrative Director of the 1812 IETF Foundation, who shall be hired by the Board of Trustees with 1813 the the advice and consent of the IESG and IAB. 1814 2. All support services shall be contracted in an open and 1815 transparent manner. 1817 3. The Administrative Director shall submit a proposed annual budget 1818 to the Board of Trustees at least 90 days before the beginning of 1819 the fiscal year. Such budget shall be developed with the advice 1820 and consent of the IAB and IESG. 1821 4. The Administrative Director shall serve on the Board of Trustees 1822 as a non-voting, ex-officio member. 1823 5. The Board of Trustees shall select a professional audit firm and 1824 shall commission an audit immediately upon the close of each 1825 fiscal year. 1826 6. The IETF Foundation will conduct financial reporting in a fully 1827 transparent fashion. Audits shall be conducted promptly and 1828 published. Tax returns shall be published. Detailed financial 1829 statements will be published on a regular basis, including timely 1830 reports on the financial results of IETF meetings. 1832 4.5 Scenario D: Autonomous Entity 1834 Scenario D has much of the same analysis as for Scenario C. However, 1835 in this scenario, instead of a mutually-beneficial symbiotic whole, 1836 the IETF Foundation sets out to ensure its own viability independent 1837 of the Internet Society. For instance, the foundation might pursue 1838 direct contributions from industry instead of relying on a unified, 1839 ISOC-based fund raising effort as outlined in Scenario C. 1841 Needless to say, direct solicitation of funds would require great 1842 care to isolate the IETF standards process from funding agencies so 1843 that there can be no question of undue influence. In Scenarios A 1844 through C, this isolation of process from funding is provided by the 1845 Internet Society. 1847 4.6 Discussion of Unincorporated Associations 1849 While many non-profit organizations choose to incorporate, this is 1850 not the only institutional structure available. In the U.S., as in 1851 several other countries, there is a concept of an unincorporated 1852 association, a legal structure that allows groups of individuals to 1853 form an association that has certain powers under the law, including 1854 in some cases limitations of liability and the ability to hold real 1855 property and make agreements. [anchor38] 1857 The concept of the unincorporated association is important for two 1858 reasons: 1859 1. "The IETF" is a nebulous concept since the community has chosen 1860 not to incorporated, define membership, or perform other actions 1861 that give the community "standing" in the legal world. But, to 1862 the extent that "the IETF" does exist, it is an unincorporated 1863 association. For example, [RFC2860] creates a Memorandum of 1864 Understanding between ICANN and "the Internet Engineering Task 1865 Force, the unincorporated association operating under such name 1866 that creates Internet Standards and related documents." 1867 2. In addition, a formal registration of an unincorporated 1868 association, as discussed in this section, is a legal mechanism 1869 that could be used to create an IETF Administrative Entity and is 1870 thus relevant to the discussion of Scenarios A through D. 1872 The concept of unincorporated association has sprung up in case law 1873 over many years, as groups of people formed social clubs, veterans 1874 groups, and other communities of interest. Inevitably, these 1875 communities ran into conflicts and the courts were forced to face 1876 questions such as whether these communities could be sued, hold 1877 property, or make contracts. 1879 This section does not attempt to discuss the standing of "the IETF" 1880 or "the IETF community" as it presently stands under case law 1881 governing unincorporated associations. Instead, this section 1882 describes a series of fairly recent developments in United States 1883 case law that are relevant to the discussion of the legal form that 1884 an IETF Administrative Entity might take. 1886 In the United States, a Uniform Unincorporated Nonprofit Association 1887 Act was passed in 1996 by the Uniform Law Commissioners [UUNAA]. The 1888 uniform law has since been enacted by Delaware and 9 other states, as 1889 well as the District of Columbia [ULC]. Unincorporated nonprofit 1890 associations can be granted federal exemption from taxes under 1891 section 501(c)(3) of the IRS Code if they meet two tests: 1892 1. *The Organizational Test.* The basic chartering document must 1893 state that the organization is "organized and operated 1894 exclusively" for an exempt purpose and that "no part of the net 1895 income of which inures to the benefit of any private shareholder 1896 or individual." In addition, upon dissolution, any assets must 1897 be distributed only for one or more exempt purposes (or to the 1898 federal government). [IRS-Org] 1899 2. *The Operational Test.* The actual operation of the organization 1900 must meet the requirements of the Internal Revenue Service and 1901 must fall within the limits and purposes set out in the 1902 chartering document. 1903 The organization test is thus theory, the operational test practice, 1904 and the two must achieve the same purposes. 1906 The unincorporated association structure is also available in other 1907 countries, such as the United Kingdom[Charity], but this analysis is 1908 confined to the U.S. structure. 1910 Some examples of unincorporated associations include: 1911 o For 180 years, from the founding until 1971, the New York Stock 1912 Exchange was an unincorporated association. In 1971, the Exchange 1913 shifted to a nonprofit corporate structure as part of a governance 1914 reform that gave greater voice to non-owners, such as listed 1915 companies and investors. The incorporation was concurrent with 1916 other changes, such as an increased role for professional 1917 management and other mechanisms suited to the "unique role and 1918 governance structure" of the Exchange [NYSE]. 1919 o Founded in 1878, the American Bar Association functioned 1920 exclusively as an unincorporated association until 1972, at which 1921 time a parallel incorporated entity was chartered under Illinois 1922 law, also called the American Bar Association [ABA]. 1923 o The World Science Fiction Society (WSFS) has "for over 50 years 1924 ... annually franchised local groups to run the World Science 1925 Fiction Convention (typical attendance over 5000) and oversee the 1926 selection of the Hugo Award winners."[Eastlake] 1927 o Many labor unions are organized as unincorporated associations 1928 (see [Busby]) as well as church groups, homeowner associations, 1929 scouting troops, parent teacher associations, and many others. 1931 An association is defined in a chartering document, typically labeled 1932 a "Constitution" or "Articles of Association." The association must 1933 have two or more members who are "joined by mutual consent for a 1934 common purpose." Members are defined as persons (which includes 1935 individuals, but also any other legal entity such as a corporation or 1936 government department) who "may participate in the selection of 1937 persons authorized to manage the affairs of the nonprofit association 1938 or in the development of policy of the nonprofit association." 1939 Mechanisms such as randomly selected nominating committees appear to 1940 adequately satisfy the "may participate in the selection" 1941 requirement. 1943 The unincorporated association is not as broad as other forms, such 1944 as an incorporated association. However, the unincorporated 1945 association does have several rights, such as: 1946 1. The ability to hold property which is separate from its members. 1947 This includes the ability to have a bank account 1948 2. A nonprofit association is a legal entity separate from its 1949 members for the purposes of determining and enforcing rights, 1950 duties, and liabilities in contract and tort. This also results 1951 in the ability to contract for insurance coverage, such as 1952 general liability, general commercial liability, errors & 1953 omissions (E&O), or directors and officers (D&O) policies. 1954 3. The ability to employ staff. 1956 The limitations on liability are important changes over older common 1957 law, which held individual members liable for the actions of the 1958 association. Needless to say, individual members can still be held 1959 liable for their own actions, but under the uniform law, they cannot 1960 be held liable for the actions of the association merely by being a 1961 member. Likewise, under the uniform law, the association has 1962 standing in court and can sue or be sued. 1964 The unincorporated association, under the uniform law, thus provides 1965 many of the benefits of the corporate form. It can be considered, to 1966 some extent, as a sort of "corporation-lite" [CLRC]. 1968 5. Future Work 1970 5.1 Short-Term 1972 This report outlines some fundamental decisions facing the IETF 1973 community about how administrative support functions should be 1974 procured and what institutional framework they should be housed in. 1975 If a consensus is reached on a direction to move on these key 1976 decisions, a number of short-term tasks will be required: 1977 1. Formulation of a budget for 2005, including a cash flow analysis. 1978 2. If formal incorporation is chosen, drafting and filing of bylaws 1979 and articles. If an operating unit is chosen, drafting of any 1980 memoranda of understanding. 1981 3. If a decision is made to negotiate a sole source contract for one 1982 or more functions, a negotiating team would need to be appointed. 1983 4. If a decision is made to issue a Request for Proposal for one or 1984 more functions, a drafting team would need to be appointed and a 1985 process for evaluation described. 1986 5. If a decision is made to appoint an Administrative Director, a 1987 call for applicants would need to be issued. 1989 5.2 Long-Term 1991 While [RFC3716] set out principles for administrative restructuring, 1992 it should be remembered that administrative restructuring is just one 1993 of the tasks facing the IETF. [RFC3774] set out a number of 1994 fundamental issues facing the community. Any administrative 1995 restructuring should be performed quickly and efficiently, allowing a 1996 renewed focus on more important issues, such as how the IETF can 1997 remain and become "an open global community of network designers, 1998 operators, vendors, and researchers producing technical 1999 specifications for the evolution of the Internet architecture and the 2000 smooth operation of the Internet."[RFC3233] 2002 Much of that focus on "more important issues" is already present in 2003 the IETF today. Working Groups such as [NEWTRK] and [ICAR] are 2004 looking hard at the basic IETF processes and how they can be made 2005 better. 2007 In considering the future, it is often worth looking at the past. 2008 Edwin T. Layton, Jr., in his 1986 study of the rise (and fall) of 2009 standards bodies in 1900's, tells of an interesting group, the 2010 Institute of Radio Engineers (IRA). Founded in 1912, the IRA was 2011 different from other professional bodies of the time, with a focus on 2012 individual instead of corporate membership, an adherence to 2013 engineering excellence, and, despite being a predominantly American 2014 body, insisting that the word "American" not be added to the IRE's 2015 name as a way of emphasizing the international nature of their 2016 pursuits [Layton]. The IRA was founded in reaction to 2017 dissatisfaction with a more formal body of the time, the American 2018 Institute of Electrical Engineers (AIEE). The IRA became known for 2019 pioneering work in standards area such as FM and commercial 2020 black-and-white and color television. Although the IRA was one of 2021 the smaller standards bodies, it was one of the most effective 2022 [Hoffman]. In 1963, the IRA merged with the AIEE to become the IEEE. 2024 Layton's study of professional societies and standards bodies in the 2025 engineering profession from early the 1900 to the 1960s is highly 2026 instructive, particularly the way different groups dealt with the 2027 tensions between the role of participants as individuals engineers 2028 versus their other roles as corporate employees or representatives of 2029 countries. The long-term relevance of the IETF is directly tied to 2030 the ability of the community to focus on core values such as "rough 2031 consensus and running code"[RFC1958] and an avoidance of 2032 entanglements at layers 8-10 of the OSI Reference Model [OSI]. 2034 As Thomas Huxley once commented in describing the conduct of the 2035 affairs of the Royal Society, "our business was (precluding matters 2036 of theology and state affairs) to discourse and consider of 2037 philosophical enquiries, and such as related thereunto."[Huxley] The 2038 IETF can certainly learn much from an examination of it's own guiding 2039 principles and by examining the history of other SDOs such as the 2040 Royal Society and the Institute of Radio Engineers. 2042 6. Acknowledgment of CNRI Contribution to the IETF Community 2044 As this plan proposes a transition from the past to the future, the 2045 author feel it is essential to acknowledge the enormous contributions 2046 made to the IETF and the Internet by the Corporation for National 2047 Research Initiatives (CNRI) and their Chairman, CEO, and President, 2048 Dr. Robert E. Kahn. 2050 Dr. Kahn's pioneering early leadership in the evolution of the 2051 Internet is well-known, including the seminal paper on the 2052 Transmission Control Protocol,[Cerf_Kahn] his key operational role in 2053 engineering the early Internet (see, e.g., [RFC0371]), and his 2054 leadership of the vastly influential DARPA Information Processing 2055 Techniques Office (IPTO), where he initiated a billion-dollar 2056 Strategic Computing Program which was responsible for funding, 2057 guiding, and encouraging technology that makes up much of today's 2058 infrastructure. 2060 Perhaps less well-known or appreciated is the contribution that Dr. 2061 Kahn and CNRI have made to the evolution of the IETF. Since 1987, 2062 CNRI has housed the IETF Secretariat, supporting 56 IETF meetings 2063 with over 55,000 total attendees, not to mention over 30,000 2064 Internet-Drafts processed, several thousand teleconferences hosted, 2065 and a theoretically finite but practically uncountable number of 2066 cookies consumed. 2068 CNRI's support allowed the IETF community to evolve in the way it 2069 has. Many of the values we have created as a community were possible 2070 only possible because we had a professional secretariat to provide 2071 support. For example, the IETF takes very seriously the idea that 2072 individuals, not institutions or countries, are the participants (not 2073 members) in the process. A stable secretariat has allowed us to 2074 preserve those values without worrying about pesky issues such as 2075 corporate sponsorship or membership fees. 2077 A number of CNRI and Foretec staff have formed the secretariat over 2078 the years. These people have all worked long and hard and, for many 2079 IETF participants, these staff have been instrumental in making the 2080 IETF an effective forum for the development of Internet standards and 2081 technology. They deserve our sincere and continuing thanks. 2083 As the IETF has scaled, we have continued to rely on CNRI to provide 2084 a base of stability. As the IETF passes the age of 18, it is time 2085 for the IETF to take responsibility for its own affairs. 2087 7. Acknowledgment of Contributions and Reviews 2089 A number of people contributed their time in telephone interviews, 2090 email exchanges, and reviews of the draft. These exchanges resulted 2091 in many useful suggestions. Needless to say, our acknowledgment of 2092 their contribution should not in any way be used to necessarily infer 2093 support for anything contained herein. These individuals include: 2094 Bernard Aboba, Harald Alvestrand, Rob Austein, Fred Baker, Bob 2095 Braden, Scott Bradner, Brian Carpenter, David Clark, Jorge Contreras, 2096 Dave Crocker, Steve Crocker, Joao Damas, Leslie Daigle, Lynn DuVal, 2097 Patrik Falstrom, Bill Fenner, Ted Hardie, Bob Hinden, Paul Hoffman, 2098 Geoff Huston, David Kessens, Robert Kahn, Daniel Karrenberg, John 2099 Klensin, Rebecca Malamud, Allison Mankin, Jordi Palet Martinez, 2100 Thomas Narten, Jun Murai, Thomas Narten, Eric Rescorla, Pete Resnick, 2101 Joyce Reynolds, Lynn St. Amour, Mike St. Johns, Paul Vixie, 2102 Margaret Wasserman, and Bert Wijnen. The author apologizes for any 2103 names inadvertently omitted. 2105 This document was created with "xml2rfc" 2106 using the format specified in [RFC2629]. PDF renditions of the 2107 document were created with Julian Reschke's XSLT style sheets 2108 and diffs from 2109 prior draft were produced using Henrik Levkowetz's "rfcdiff" tool 2110 . 2112 8. IANA Considerations 2114 [RFC2434] states each Internet-Draft should contain an "IANA 2115 Considerations" section. [RFC3716] noted that a frequent problem for 2116 the IANA is documents that do not contain such a section, thus 2117 requiring a full scan of the document. 2119 This submission contains no specific modifications to existing 2120 registries or creation of new registries. However, the submission 2121 contains a number of sections that may impact the overall operation 2122 of the IANA. A full scan of the document is thus recommended. 2124 9. Security Considerations 2126 Improper formulation of the legal framework underlying the IETF may 2127 expose the institution and individuals in leadership positions to 2128 potential legal risks. Any such risk under this plan appears to be 2129 equivalent to the risk faced by the community under the current legal 2130 framework. This risk is further mitigated by a thorough review by 2131 legal counsel, and by use of insurance coverage. 2133 The legal exposure is best minimized by a careful adherence to our 2134 procedures and processes, as defined by the Best Current Practice 2135 Series. A carefully stated process, such as the BCP documents that 2136 govern the selection of leadership positions and define the standards 2137 process are the best insurance against legal exposure, provided care 2138 is taken to stick to the process standards that have been set. 2139 Adherence to a public rule book and a fully open process are the most 2140 effective mechanisms the IETF community can use. 2142 Improper management controls and procedures or other imprudent fiscal 2143 or administrative practices could expose the IETF to a risk of 2144 insolvency. Careful selection of trustees, a process of budget 2145 approval, and a methodical system of fiscal controls are necessary to 2146 minimize this risk. 2148 10. References 2150 10.1 Normative References 2152 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 2153 RFC 1958, June 1996. 2155 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 2156 and Procedures", BCP 8, RFC 2014, October 1996. 2158 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2159 3", BCP 9, RFC 2026, October 1996. 2161 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 2162 the IETF Standards Process", BCP 11, RFC 2028, October 2163 1996. 2165 [RFC2031] Huizer, E., "IETF-ISOC relationship", RFC 2031, October 2166 1996. 2168 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 2169 RFC 2223, October 1997. 2171 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 2172 Procedures", BCP 25, RFC 2418, September 1998. 2174 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2175 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2176 October 1998. 2178 [RFC2555] Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler, 2179 J. and C. Anderson, "30 Years of RFCs", RFC 2555, April 2180 1999. 2182 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 2183 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 2184 May 2000. 2186 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 2187 Understanding Concerning the Technical Work of the 2188 Internet Assigned Numbers Authority", RFC 2860, June 2000. 2190 [RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 2191 3005, November 2000. 2193 [RFC3184] Harris, S., "IETF Guidelines for Conduct", BCP 54, RFC 2194 3184, October 2001. 2196 [RFC3233] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, 2197 RFC 3233, February 2002. 2199 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 2200 3667, February 2004. 2202 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 2203 Technology", BCP 79, RFC 3668, February 2004. 2205 [RFC3677] Daigle, L. and Internet Architecture Board, "IETF ISOC 2206 Board of Trustee Appointment Procedures", BCP 77, RFC 2207 3677, December 2003. 2209 [RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF 2210 mailing lists", BCP 83, RFC 3683, February 2004. 2212 [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February 2213 2004. 2215 [RFC3716] Advisory, IAB., "The IETF in the Large: Administration and 2216 Execution", RFC 3716, March 2004. 2218 [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. 2220 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 2221 Recall Process: Operation of the Nominating and Recall 2222 Committees", BCP 10, RFC 3777, June 2004. 2224 10.2 Informative References 2226 [.] Malamud, C., Ed., "IETF Administrative Support Functions", 2227 draft-malamud-consultant-report-01 (work in progress), 2228 September 2004, . 2230 [ABA] American Bar Association, "Constitution and Bylaws of the 2231 American Bar Association and Rules of Procedure of the 2232 House of Delegates", August 1994, 2233 . 2236 [Bingo] Anonymous, "Buzzword Bingo", 1996, 2237 . 2239 [Busby] U.S. Supreme Court, "Busby v. Electric Utilities Employees 2240 Union", 323 U.S. 72, December 1944, 2241 . 2244 [CLRC] California Law Revision Commission, "Uniform 2245 Unincorporated Nonprofit Association Act: Governance 2246 Issues", Staff Memorandum 2002-59, Study B-501, October 2247 2002, . 2249 [CNRI-2002] 2250 CNRI, "Form 990 - Return of Organization Exempt from 2251 Income Tax - 2002", EIN 52-1447747, November 2003. 2253 [California] 2254 State of California, "California Corporations Code", 2255 Undated, 2256 . 2259 [Cerf_Kahn] 2260 Cerf, V. and R. Kahn, "A Protocol for Packet Network 2261 Intercommunication", IEEE Trans. on Comm., Vol. COM-23, 2262 pp. 637-648, May 1974. 2264 [Charity] Charity Commission for England and Wales, "GD3 - Model 2265 Constitution for a Charitable Unincorporated Association", 2266 July 2004, 2267 . 2270 [Delaware] 2271 State of Delaware, "Title 8. Corporations -- Chapter 1. 2272 General Corporation Law -- Subchapter 1. Formation", 2273 Undated, 2274 . 2277 [Eastlake] 2278 Eastlake, D., "ISOC etc. (ignore if you don't like lengthy 2279 legal flames)", IETF Mailing List, February 1995, 2280 . 2282 [FASB-117] 2283 Financial Accounting Standards Board (FASB), "Financial 2284 Statements of Not-For-Profit Organizations", FASB 117, 2285 June 1993, 2286 . 2288 [Hoffman] IEEE Center for the History of Electrical Engineering, 2289 "The Origins of the IEEE", 1984, 2290 . 2293 [Huxley] Huxley, T., "On the Advisableness of Improving Natural 2294 Knowledge (A Lay Sermon Delivered in St. Martin's Hall)", 2295 Project Gutenberg THX1410, Fortnightly Review 3 (1866): 2296 626-37, January 1866, 2297 . 2300 [I-D.alvestrand-ietf-mission] 2301 Alvestrand, H., "A Mission Statement for the IETF", 2302 draft-alvestrand-ietf-mission-02 (work in progress), June 2303 2004. 2305 [I-D.daigle-adminrest] 2306 Daigle, L., "A Proposal for IETF Administrative 2307 Restructuring", draft-daigle-adminrest-00 (work in 2308 progress), February 2004. 2310 [I-D.ietf-xmpp-core] 2311 Saint-Andre, P., "Extensible Messaging and Presence 2312 Protocol (XMPP): Core", draft-ietf-xmpp-core-24 (work in 2313 progress), May 2004. 2315 [I-D.narten-iana-considerations-rfc2434bis] 2316 Narten, T. and H. Alvestrand, "Guidelines for Writing an 2317 IANA Considerations Section in RFCs", 2318 draft-narten-iana-considerations-rfc2434bis-00 (work in 2319 progress), August 2004. 2321 [I-D.rfc-editor-rfc2223bis] 2322 Reynolds, J. and R. Braden, "Instructions to Request for 2323 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08 2324 (work in progress - do not cite as a normative reference), 2325 July 2004, 2326 . 2329 [ICAR] The IETF, "Charter of the Improved Cross-Area Review 2330 (icar) Working Group", June 2004, 2331 . 2333 [IETF-2001] 2334 Alvestrand, H., "The Financials of the IETF -- 2001", 2335 February 2003, 2336 . 2338 [IETF-2002] 2339 Alvestrand, H., "The Financials of the IETF -- 2002", July 2340 2003, 2341 2342 . 2344 [IETF-2003] 2345 Alvestrand, H., "The Financials of the IETF -- 2003", May 2346 2004, 2347 2348 . 2350 [IETF-2004] 2351 Alvestrand, H., "The IETF Budget -- 2004", May 2004, 2352 . 2354 [IRS] U.S. Code, "Title 26, Sec. 501: Exemption from tax on 2355 corporations, certain trusts, etc.", Undated, 2356 . 2358 [IRS-Org] Internal Revenue Service, "The Organizational Test for 2359 Under IRC 501(c)(3)", August 2003, 2360 . 2362 [ISOC-2002] 2363 Internet Society, "Form 990 - Return of Organization 2364 Exempt from Income Tax - 2002", EIN 52-1650477, October 2365 2003. 2367 [ISOC-2004] 2368 Internet Society, "37th Board of Trustees meeting of the 2369 Internet Society", Resolution 3-20, December 2003, 2370 . 2372 [ISOC-Gov] 2373 Internet Society, "Procedures for selecting Trustees", 2374 Board Resolution 02-2, 2002. 2376 [ISOC-Gov2] 2377 Internet Society, "Resolution 01-10 Procedures for 2378 Nomination and Election of Trustees by Individual 2379 Members", Board Resolution 01-10, 2001. 2381 [Layton] Layton, E., "The Revolt of the Engineers", The John 2382 Hopkins University Press, ISBN 0-8018-3287-X, 1986. 2384 [NEWTRK] The IETF, "Charter of the New IETF Standards Track 2385 Discussion (newtrk) Working Group", June 2004, 2386 . 2388 [NYSE] Governance Committee of the NYSE Board, "Governance of the 2389 New York Stock Exchange", May 2003, 2390 . 2392 [OSI] Wikepedia, "Open Systems Interconnection Reference Model", 2393 ISO/IEC 7498-1, August 2004, 2394 . 2396 [RFC-SOW] Internet Society, "Statement of Work--RFC Editor", 2397 Undated, 2398 . 2400 [RFC0015] Carr, C., "Network subsystem for time sharing hosts", RFC 2401 15, September 1969. 2403 [RFC0371] Kahn, R., "Demonstration at International Computer 2404 Communications Conference", RFC 371, July 1972. 2406 [RFC2134] ISOC Board of Trustees, "ARTICLES OF INCORPORATION OF 2407 INTERNET SOCIETY", RFC 2134, April 1997. 2409 [RFC2135] ISOC Board of Trustees, "Internet Society By-Laws", RFC 2410 2135, April 1997. 2412 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 2413 June 1999. 2415 [RFC3844] Davies, E. and J. Hofmann, "IETF Problem Resolution 2416 Process", RFC 3844, August 2004. 2418 [Texas] Texas Sunset Advisory Commission, "Guide to the Texas 2419 Sunset Process", December 2003, 2420 . 2422 [ULC] Uniform Law Commissioners, "UUNAA Legislative Fact Sheet", 2423 2004, 2424 . 2427 [UUNAA] Uniform Law Commissioners, "Uniform Unincorporated 2428 Nonprofit Association Act (1996)", National Conference of 2429 Commissioners on Uniform State Laws, 1996, 2430 . 2433 [Virginia] 2434 State of Virginia, "Title 13.1: Corporations, Limited 2435 Liability Companies, Business Trusts", Undated, 2436 . 2439 [Wayback] Internet Archive, "Wayback Machine: Comparison of 2440 www.ietf.org for Jan. 7, 1997 and Feb. 15, 2004", 2441 September 2004, 2442 . 2448 URIs 2450 [1] 2452 [2] 2454 [3] 2458 [4] 2462 [5] 2466 [6] 2470 [7] 2472 [8] 2476 [12] 2478 [13] 2480 [14] 2482 [15] 2484 [16] 2486 [17] 2489 Editorial Comments 2491 [anchor24] Editor: It has been noted that any such action would, of 2492 course, require the full approval and cooperation of the 2493 Internet Society Board. The fundamental chartering 2494 document for ISOC are the articles of incorporation, 2495 which require 4/5 approval of the board for changes 2496 [RFC2134]. The bylaws, as published in [RFC2135] and 2497 periodically amended through board resolutions, requires 2498 a 2/3 vote for certain changes to the bylaws. Governance 2499 is specified in general terms in [RFC2135] and further 2500 specified in a series of board resolutions. Composition 2501 of and the procedures for selection of members of the 2502 board is specified in Board Resolution 02-2 [ISOC-Gov] 2503 which is "generally harmonious" with [ISOC-Gov2], which 2504 is currently suspended. 2506 [anchor25] Editor: Several reviewers have pointed out drawbacks of 2507 this mechanism, particularly the loss of independence of 2508 those director seats. These reviewers have pointed out 2509 that if the IETF and IAB Chairs have seats on the board 2510 as ex-officio members, sufficient representation of IETF 2511 interests is present. 2513 [anchor26] Editor: Reviewers have noted that this mechanism would be 2514 necessary under Scenario A as well. 2516 [anchor27] Editor: Several reviewers have noted that the ISOC board 2517 does in fact already conduct open meetings. This 2518 mechanism simply suggests more IETF participation in 2519 those meetings as a way of drawing the community 2520 together. 2522 [anchor28] Editor: This suggestion came from Marshall T. Rose. 2524 [anchor34] Mike St. Johns: Use of the Nomcom and the recall 2525 procedure are both inappropriate as they are tailored 2526 towards selection of and recall of technical leadership, 2527 which is not necessarily appropriate for the fiscal, 2528 legal, and administrative skill sets needed in a board 2529 for the Foundation. 2531 [anchor38] Editor: Several members of the community, including Rob 2532 Austein, Brian Carpenter, Donald Eastlake, Robert Kahn, 2533 and Patrice Lyons suggested an analysis of the 2534 "unincorporated association" mechanism as an alternative 2535 to formal incorporation. 2537 Author's Address 2539 Carl Malamud (editor) 2540 Memory Palace Press 2541 PO Box 300 2542 Sixes, OR 97476 2543 US 2545 EMail: carl@media.org 2546 URI: http://infinite.simians.net/ 2548 Appendix A. Consulting Contract 2550 AGREEMENT FOR CONSULTING SERVICES 2551 Contract between CARL MALAMUD AND THE INTERNET SOCIETY 2553 *Contract:* 2555 Carl Malamud (hereafter known as the Consultant) agrees to provide 2556 consulting services to the Internet Engineering Task Force (IETF), 2557 the Internet Architecture Board (IAB) and the Internet Society (ISOC) 2558 subject to the terms and conditions specified below. Under this 2559 agreement, the Consultant is acting as an independent contractor and 2560 assumes all responsibilities for federal and state income taxes, 2561 social security and medicare tax, medical insurance, and other 2562 applicable filings associated with his status. 2564 *Scope:* 2566 The Consultant will provide the following services outlined in 2567 Appendix I. It is anticipated that the responsibilities will require 2568 20 days per month to accomplish the objectives for which said 2569 Consultant was engaged. 2571 Consultant understands and agrees that this Contract is being 2572 executed with a view to supporting the IETF/IAB as it considers 2573 whether, and if so, how, it might wish to restructure for purposes of 2574 future IETF/IAB endeavors. In the performance of this Contract, 2575 Consultant agrees to exercise fair and professional judgment for the 2576 benefit of the IETF/IAB and to treat all existing and/or potential 2577 partners of the IETF/IAB in a fair manner while protecting any 2578 business confidences that each might have. 2580 *Contract Term:* 2582 The contract will begin on 21 June 2004 and end on 21 December 2004. 2583 For services rendered under this contract the Consultant will be paid 2584 a fee of $16,000 per month due and payable at the end of each month 2585 upon receipt of an invoice. Consultant will be required to submit a 2586 monthly accounting of days worked. Should the days worked in any 2587 month exceed 20, no additional fees are due. The contract may only 2588 be extended by written agreement specifying new services, terms, and 2589 conditions as mutually agreed to by both parties. 2591 *Expenses:* 2593 All expenses incurred on behalf of the IETF/IAB or ISOC shall be 2594 billed to ISOC in addition to charges for services provided above. 2595 Such expenses shall include travel, long distance telephone, business 2596 meals, and other customary expenses as appropriate. Such expenses 2597 should be authorized by ISOC, after consultation with the IETF and 2598 the IAB Chairs, and in advance of the expenditure. 2600 *Invoicing:* 2602 Consultant shall submit invoices at the end of each month (pro-rated 2603 for June and December). The Internet Society will make best efforts 2604 to make payment within one week of receipt. If consultant worked 2605 less than 20 days, then ISOC may reduce the monthly fee due by 1/20th 2606 of such fee for each day less than 20. Invoices may be submitted 2607 electronically or by mail. The invoices should be addressed to the 2608 Internet Society's Finance Director, Lynn DuVal at the Reston office 2609 (1775 Wiehle Avenue, Suite 102, Reston, VA 20190) or by e-mail at 2610 duval@isoc.org. 2612 *Termination:* 2614 Either party may terminate this Contract by providing ten (10) days 2615 prior written notice sent by e-mail to the addresses noted below. 2617 In addition, should the subject matter addressed in this Contract 2618 become, in whole or in part, the subject matter of any filed or 2619 threatened litigation then either party may terminate this Contract 2620 by providing five (5) days prior written notice sent as per the above 2621 paragraph. 2623 The days of prior written notice above shall be measured from the 2624 date sent. 2626 The Internet Society will be responsible for all fees properly 2627 incurred under this Contract prior to the effective date of 2628 termination. 2630 If such a termination should occur other than at a month-end, then 2631 payment for services shall be paid pro rata, up to 100% of the 2632 monthly rate, at the rate of 1/20th of the monthly services fee per 2633 day worked to termination 2635 *Miscellaneous:* 2637 ISOC does not wish for itself or others to receive any confidential, 2638 proprietary information of any other party without proper permission. 2639 Consequently, Consultant agrees not to use or divulge, in his efforts 2640 relating to this contract, any information in any form, tangible or 2641 intangible, that is the confidential information of any third party, 2642 whether IETF/IAB, any contractor or partner of IETF/IAB, or any other 2643 party, to ISOC or any other party without the express written 2644 permission of the party or parties who own or control such 2645 confidential material and without first disclosing such written 2646 permission to ISOC. 2648 Consultant agrees that any tangible or intangible work product that 2649 results from Consultant's efforts under this Contract (whether by 2650 Consultant or a contractor to Consultant) shall be the exclusive 2651 property of ISOC or the IETF/IAB, as appropriate, and this includes, 2652 without limitation, any invention, product, business process, code or 2653 other device or discovery that might now or hereafter be entitled to 2654 protection, registration or ownership under intellectual property 2655 rights regimens such as, but not only, trade secret, patent, 2656 copyright, and trademark. 2658 ISOC may disclose the terms of this Contract to the IETF/IAB or any 2659 other party having an interest in the subject matter hereof that ISOC 2660 deems reasonable. 2662 *Warranties and Indemnities:* 2664 This written agreement constitutes the full agreement between the 2665 parties. No warranties or indemnities are explicitly included or 2666 implied. 2668 *Amendments:* 2670 Amendments to this agreement must be in writing and executed by both 2671 parties. 2673 +---------------------------------+---------------------------------+ 2674 | Executed on behalf of The | Executed on behalf of the | 2675 | Internet Society | Consultant | 2676 +---------------------------------+---------------------------------+ 2677 | Lynn St. Amour | Carl Malamud | 2678 | | | 2679 | President & CEO | | 2680 | | | 2681 | st.amour@isoc.org | carl@media.org | 2682 | | | 2683 | Date: | Date: | 2684 +---------------------------------+---------------------------------+ 2686 *Appendix I: Statement of Work* 2688 The IETF/IAB is considering an Administrative restructuring and has 2689 asked ISOC to support their efforts. The contract to which this is 2690 attached is in furtherance of this endeavor. 2692 Consultant shall become familiar with RFC 3716 as the basis for these 2693 efforts and shall use such RFC as a reference point in these efforts 2694 except to the extent that this Contract or any guidance supplied to 2695 Consultant by IETF/IAB or ISOC under this contract supercedes such 2696 RFC. 2698 The types of activities Consultant shall undertake are: 2699 o Assist in researching, recommending and ultimately drafting the 2700 proposed structure/bylaws for the IETF administrative entity; 2701 o Revising proposed structure and/or bylaws based on the public 2702 review, including reviews by counsel; 2703 o Negotiate appropriate contract(s) for RFC Editor and/or other 2704 contractors as a model for eventual use by the IETF administrative 2705 entity; 2706 o Conduct appropriate liaison with the RFC Editor, IANA and 2707 Secretariat to determine the requirements for inter-organizational 2708 document flow matched to overall IETF/IAB process needs. 2709 o Others as reasonably directed by ISOC, IETF and or IAB 2711 Deliverables hereunder shall include: 2712 o Data Flow: a comprehensive set of requirements for implementing 2713 appropriate tracking of IETF/IAB documents and reporting of status 2714 across support organizations. 2715 o Negotiated contracts, per the above, that are acceptable to all 2716 concerned parties and are ready for execution. 2717 o Administrative restructuring: documentation and support, as 2718 appropriate, to the continued evolution of the restructuring 2719 effort, which shall be periodically reviewed by the IAB, IESG and 2720 other appropriate parts of the IETF community of interest. 2722 Appendix B. IETF Financial Information 2724 B.1 Consolidated 3-Year Historical Income Statement 2726 (US$) 2728 +------------------+------------+-----------+-----------+-----------+ 2729 | | 2001 [1] | 2002 [2] | 2003 [3] | 2004 [4] | 2730 +------------------+------------+-----------+-----------+-----------+ 2731 | REVENUE | | | | | 2732 | | | | | | 2733 | CNRI/Foretec | 2,699,239 | 2,350,666 | 2,060,747 | 1,728,125 | 2734 | Meeting Revenue | | | | | 2735 | | | | | | 2736 | Less Bank Fees | 81,365 | 70,309 | 62,826 | 51,844 | 2737 | | | | | | 2738 | Net Meeting | 2,617,874 | 2,280,357 | 1,997,921 | 1,676,281 | 2739 | Revenue | | | | | 2740 | | | | | | 2741 | Contribution By | 535,535 | 550,881 | 614,691 | 663,570 | 2742 | The Internet | | | | | 2743 | Society [5] | | | | | 2744 | | | | | | 2745 | Provision of the | -- | -- | -- | -- | 2746 | IANA function by | | | | | 2747 | ICANN [6] | | | | | 2748 | | | | | | 2749 | Other | -- | -- | -- | 150,000 | 2750 | Contributions | | | | | 2751 | | | | | | 2752 | TOTAL FUNDS | 3,153,409 | 2,831,238 | 2,612,612 | 2,489,851 | 2753 | | | | | | 2754 | | | | | | 2755 | EXPENSE | | | | | 2756 | | | | | | 2757 | ISOC | | | | | 2758 | Expenditures | | | | | 2759 | | | | | | 2760 | RFC Editor | 428,300 | 462,368 | 516,460 | 574,570 | 2761 | | | | | | 2762 | IETF Chair | 73,748 | 52,137 | 51,460 | 48,500 | 2763 | Discretionary | | | | | 2764 | Fund | | | | | 2765 | | | | | | 2766 | IAB Support | 13,287 | 14,446 | 37,270 | 24,500 | 2767 | | | | | | 2768 | Insurance | 20,000 | 21,930 | 13,685 | 16,000 | 2769 | | | | | | 2770 | Total ISOC | 535,535 | 550,881 | 614,691 | 663,570 | 2771 | Expenditures | | | | | 2772 | | | | | | 2773 | | | | | | 2774 | CNRI/Foretec | | | | | 2775 | Expenditures | | | | | 2776 | | | | | | 2777 | Secretariat | 504,584 | 625,124 | 532,936 | 478,000 | 2778 | Labor | | | | | 2779 | | | | | | 2780 | IETF Meeting | | | | | 2781 | Costs | | | | | 2782 | | | | | | 2783 | Food & Beverage | 862,500 | 705,610 | 513,081 | 487,500 | 2784 | | | | | | 2785 | Audio/Visual | 127,337 | 83,239 | 96,902 | 60,000 | 2786 | | | | | | 2787 | Room Rental | 190,265 | 172,907 | 125,187 | 170,000 | 2788 | | | | | | 2789 | Terminal Room | -- | -- | 66,294 | 25,000 | 2790 | | | | | | 2791 | Other Meeting | 1,925 | 8,340 | 13,367 | 6,000 | 2792 | Costs | | | | | 2793 | | | | | | 2794 | Total IETF | 1,182,027 | 970,096 | 814,831 | 748,500 | 2795 | Meeting Costs | | | | | 2796 | | | | | | 2797 | | | | | | 2798 | Non-Meeting | | | | | 2799 | Costs | | | | | 2800 | | | | | | 2801 | Travel | 39,122 | 53,838 | 78,947 | 75,000 | 2802 | | | | | | 2803 | Materials | 7,318 | 11,724 | 9,706 | 10,700 | 2804 | | | | | | 2805 | Printing & | 59,431 | 31,459 | 14,266 | 12,000 | 2806 | Publication | | | | | 2807 | | | | | | 2808 | Professional | 24,581 | 61,105 | 12,288 | 9,000 | 2809 | Services | | | | | 2810 | | | | | | 2811 | Telecommunicatio | 54,400 | 82,210 | 32,582 | 42,000 | 2812 | ns | | | | | 2813 | | | | | | 2814 | Misc. | 12,003 | 577 | -- | 4,000 | 2815 | | | | | | 2816 | Equipment Rental | 4,668 | 736 | 1,630 | 2,500 | 2817 | | | | | | 2818 | Total | 201,523 | 241,650 | 149,419 | 155,200 | 2819 | Non-Meeting | | | | | 2820 | Costs | | | | | 2821 | | | | | | 2822 | | | | | | 2823 | Total | 1,888,134 | 1,836,870 | 1,497,186 | 1,381,700 | 2824 | CNRI/Foretec | | | | | 2825 | "Direct" | | | | | 2826 | Expenses | | | | | 2827 | | | | | | 2828 | | | | | | 2829 | CNRI/Foretec | 604,990 | 608,805 | 641,939 | 504,560 | 2830 | Overhead Charge | | | | | 2831 | | | | | | 2832 | CNRI/Foretec | 30,000 | -- | -- | -- | 2833 | "Performance | | | | | 2834 | Bonus" For Staff | | | | | 2835 | | | | | | 2836 | | | | | | 2837 | Total | 2,523,124 | 2,445,675 | 2,139,125 | 1,886,260 | 2838 | CNRI/Foretec | | | | | 2839 | Expenses | | | | | 2840 | | | | | | 2841 | | | | | | 2842 | TOTAL EXPENSES | 3,058,659 | 2,996,556 | 2,753,816 | 2,549,830 | 2843 | (ISOC and CNRI) | | | | | 2844 | | | | | | 2845 | | | | | | 2846 | SURPLUS/DEFICIT | 94,750 | (165,318) | (141,204) | (59,979) | 2847 +------------------+------------+-----------+-----------+-----------+ 2849 Notes: 2850 [1] Actual results based on unaudited reports. Source: [IETF-2001] 2851 [2] Actual results based on unaudited reports. Source: [IETF-2002] 2852 [3] Actual results based on unaudited reports. Source: [IETF-2003] 2853 [4] Budgeted. Source: [IETF-2004] 2854 [5] ISOC manages expenditures directly. The revenue line here 2855 represents funds allocated by the ISOC Board of Trustees for the 2856 purpose of IETF support. The figures in this line equal their 2857 corresponding cells for Total ISOC Expenditures. 2858 [6] ICANN does not report expenses broken down by functional area, 2859 nor are the direct and indirect costs associated with the IETF 2860 parameter registries available. We thus value this contribution 2861 as "priceless" for purposes of this analysis. 2863 B.2 Internet Society 2004 Budget Summary 2865 The Internet Society 2004 Budget was approved at a Special 2866 Teleconference Meeting of the Internet Society Board of Trustees 2867 [ISOC-2004]. 2869 (US$) 2871 +------------------+------------+-----------+-----------+-----------+ 2872 | | Standards | Education | Public | Total | 2873 | | Pillar | Pillar | Policy | | 2874 | | | | Pillar | | 2875 +------------------+------------+-----------+-----------+-----------+ 2876 | REVENUE | | | | | 2877 | | | | | | 2878 | Organizational | 1,050,000 | 242,000 | 200,000 | 1,492,000 | 2879 | and Platinum | | | | | 2880 | Membership | | | | | 2881 | | | | | | 2882 | Individual | | | 52,500 | 52,500 | 2883 | Membership | | | | | 2884 | | | | | | 2885 | Conferences | | 145,000 | | 145,000 | 2886 | (INET, NDSS) | | | | | 2887 | | | | | | 2888 | .org Program | 900,000 | 450,000 | 550,000 | 1,900,000 | 2889 | Revenue | | | | | 2890 | | | | | | 2891 | Other | 155,000 | | | 155,000 | 2892 | (Contributions | | | | | 2893 | and Security | | | | | 2894 | Expert | | | | | 2895 | Initiative | | | | | 2896 | | | | | | 2897 | TOTAL REVENUE | 2,105,000 | 837,000 | 802,500 | 3,744,500 | 2898 | | | | | | 2899 | | | | | | 2900 | EXPENSE | | | | | 2901 | | | | | | 2902 | ISOC Salaries | 371,337 | 364,623 | 458,128 | 1,194,088 | 2903 | and Related | | | | | 2904 | Costs | | | | | 2905 | | | | | | 2906 | IETF Staff | 10,000 | | | 10,000 | 2907 | Travel | | | | | 2908 | | | | | | 2909 | RFC Editor | 574,570 | | | 574,570 | 2910 | | | | | | 2911 | IETF and IAB | 89,000 | | | 89,000 | 2912 | Support and | | | | | 2913 | Insurance | | | | | 2914 | | | | | | 2915 | IETF | 709,000 | | | 709,000 | 2916 | Restructuring | | | | | 2917 | Project | | | | | 2918 | | | | | | 2919 | Conference | | 100,000 | | 100,000 | 2920 | Expense | | | | | 2921 | | | | | | 2922 | Professional | 12,500 | 20,000 | 4,000 | 36,500 | 2923 | Services, | | | | | 2924 | Travel, Misc. | | | | | 2925 | | | | | | 2926 | External Costs: | 40,000 | 89,400 | 70,000 | 199,400 | 2927 | .org | | | | | 2928 | | | | | | 2929 | External Costs: | 70,000 | 42,181 | | 112,181 | 2930 | SEINIT & Sida | | | | | 2931 | | | | | | 2932 | | | | | | 2933 | TOTAL DIRECT | 1,876,407 | 616,204 | 532,128 | 3,024,739 | 2934 | EXPENSE | | | | | 2935 | | | | | | 2936 | G&A/GOVERNANCE | 192,026 | 188,555 | 236,908 | 617,489 | 2937 | | | | | | 2938 | TOTAL EXPENSE | 2,068,433 | 804,759 | 769,036 | 3,642,228 | 2939 | | | | | | 2940 | | | | | | 2941 | SURPLUS | 36,567 | 32,241 | 33,464 | 102,272 | 2942 +------------------+------------+-----------+-----------+-----------+ 2944 Appendix C. 10-Year Meeting Attendance Summary 2946 +------------+------------+-------------+-------------+-------------+ 2947 | IETF | DATE | Location | Host | Attendees | 2948 +------------+------------+-------------+-------------+-------------+ 2949 | 60th IETF | 01/08/2004 | San Diego, | -- | 1511 | 2950 | [12] | | CA, USA | | | 2951 | | | | | | 2952 | 59th IETF | 29/02/2004 | Seoul, | -- | 1390 | 2953 | [13] | | South Korea | | | 2954 | | | | | | 2955 | 58th IETF | 09/11/2003 | Minneapolis | -- | 1233 | 2956 | [14] | | , MN, USA | | | 2957 | | | | | | 2958 | 57th IETF | 13/07/2003 | Vienna, | -- | 1304 | 2959 | [15] | | Austria | | | 2960 | | | | | | 2961 | 56th IETF | 16/03/2003 | San | -- | 1679 | 2962 | [16] | | Francisco, | | | 2963 | | | California, | | | 2964 | | | USA | | | 2965 | | | | | | 2966 | 55th IETF | 17/11/2002 | Atlanta, | Nokia | 1570 | 2967 | | | Georgia, | | | 2968 | | | USA | | | 2969 | | | | | | 2970 | 54th IETF | 14/07/2002 | Yokohama, | Fujitsu; | 1885 | 2971 | | | Japan | The WIDE | | 2972 | | | | Project | | 2973 | | | | | | 2974 | 53rd IETF | 17/03/2002 | Minneapolis | Cable & | 1656 | 2975 | | | , | Wireless | | 2976 | | | Minnesota, | | | 2977 | | | USA | | | 2978 | | | | | | 2979 | 52nd IETF | 09/12/2001 | Salt Lake | Novell | 1691 | 2980 | | | City, Utah, | | | 2981 | | | USA | | | 2982 | | | | | | 2983 | 51st IETF | 05/08/2001 | London, | BTexact | 2226 | 2984 | | | England | Technologie | | 2985 | | | | s | | 2986 | | | | | | 2987 | 50th IETF | 18/03/2001 | Minneapolis | Lucent | 1822 | 2988 | | | , MN, USA | Technologie | | 2989 | | | | s | | 2990 | | | | | | 2991 | 49th IETF | 10/12/2000 | San Diego, | Cisco | 2810 | 2992 | | | CA, USA | Systems; | | 2993 | | | | Qualcomm | | 2994 | | | | | | 2995 | 48th IETF | 31/07/2000 | Pittsburgh, | Marconi | 2344 | 2996 | | | PA, USA | | | 2997 | | | | | | 2998 | 47th IETF | 26/03/2000 | Adelaide, | connect.com | 1431 | 2999 | | | Australia | .au | | 3000 | | | | | | 3001 | 46th IETF | 07/11/1999 | Washington, | Nortel | 2379 | 3002 | | | DC, USA | Networks, | | 3003 | | | | Inc | | 3004 | | | | | | 3005 | 45th IETF | 11/07/1999 | Oslo, | Uninett | 1710 | 3006 | | | Norway | | | 3007 | | | | | | 3008 | 44th IETF | 14/03/1999 | Minneapolis | Ascend | 1705 | 3009 | | | , MN, USA | Communicati | | 3010 | | | | ons | | 3011 | | | | | | 3012 | 43rd IETF | 07/12/1998 | Orlando, | Microsoft | 2124 | 3013 | | | FL, USA | Corporation | | 3014 | | | | | | 3015 | 42nd IETF | 24/08/1998 | Chicago, | Motorola | 2106 | 3016 | | | IL, USA | | | 3017 | | | | | | 3018 | 41st IETF | 30/03/1998 | Los | -- | 1775 | 3019 | | | Angeles, | | | 3020 | | | CA, USA | | | 3021 | | | | | | 3022 | 40th IETF | 08/12/1997 | Washington, | Newbridge | 1897 | 3023 | | | DC, USA | Networks, | | 3024 | | | | Inc | | 3025 | | | | | | 3026 | 39th IETF | 11/08/1997 | Munich, | ISOC-German | 1308 | 3027 | | | Germany | y Chapter | | 3028 | | | | | | 3029 | 38th IETF | 07/04/1997 | Memphis, | Federal | 1321 | 3030 | | | Tennessee, | Express | | 3031 | | | USA | | | 3032 | | | | | | 3033 | 37th IETF | 09/12/1996 | San Jose, | Cisco | 1993 | 3034 | | | California, | Systems | | 3035 | | | USA | | | 3036 | | | | | | 3037 | 36th IETF | 24/06/1996 | Montreal, | -- | 1283 | 3038 | | | Quebec, | | | 3039 | | | CANADA | | | 3040 | | | | | | 3041 | 35th IETF | 04/03/1996 | Los | -- | 1038 | 3042 | | | Angeles, | | | 3043 | | | California, | | | 3044 | | | USA | | | 3045 | | | | | | 3046 | 34th IETF | 04/12/1995 | Dallas, | MCI | 1007 | 3047 | | | Texas, USA | | | 3048 | | | | | | 3049 | 33rd IETF | 17/07/1995 | Stockholm, | the Royal | 617 | 3050 | | | Sweden | Institute | | 3051 | | | | of | | 3052 | | | | Technology; | | 3053 | | | | NORDUnet | | 3054 | | | | | | 3055 | 32nd IETF | 03/04/1995 | Danvers, | FTP | 983 | 3056 | | | Massachuset | Software; | | 3057 | | | ts, USA | NEARnet | | 3058 | | | | | | 3059 | 31st IETF | 05/12/1994 | San Jose, | Sun | 1079 | 3060 | | | California, | Microsystem | | 3061 | | | USA | s | | 3062 | | | | | | 3063 | 30th IETF | 25/07/1994 | Toronto, | University | 710 | 3064 | | | Ontario, | of Toronto | | 3065 | | | CANADA | | | 3066 | | | | | | 3067 | 29th IETF | 28/03/1994 | Seattle, | NorthWestNe | 785 | 3068 | | | Washington, | t | | 3069 | | | USA | | | 3070 +------------+------------+-------------+-------------+-------------+ 3072 C.1 Analysis of Meeting-Based Expense and Revenue Drivers 3074 +----------------+----------------+----------------+----------------+ 3075 | Category | 2001 | 2002 | 2003 | 3076 +----------------+----------------+----------------+----------------+ 3077 | Total | 5,739 | 5,111 | 4,216 | 3078 | Attendees | | | | 3079 | | | | | 3080 | Net Meeting | $456 | $446 | $489 | 3081 | Revenue Per | | | | 3082 | Attendee | | | | 3083 | | | | | 3084 | Average Food & | $150 | $138 | $122 | 3085 | Beverage Per | | | | 3086 | Attendee | | | | 3087 | | | | | 3088 | Average Total | $206 | $190 | $193 | 3089 | Direct Meeting | | | | 3090 | Cost Per | | | | 3091 | Attendee [1] | | | | 3092 | | | | | 3093 | Total | $440 | $479 | $507 | 3094 | CNRI/Foretec | | | | 3095 | Secretariat | | | | 3096 | Expenses | | | | 3097 | Divided by | | | | 3098 | Number of | | | | 3099 | Meeting | | | | 3100 | Attendees | | | | 3101 +----------------+----------------+----------------+----------------+ 3103 Notes: 3104 [1] Room rental fees are typical for non-U.S. meetings. Average 3105 total direct costs will thus be influenced by the choice of 3106 location of meetings. 3108 Appendix D. Sample Draft Incorporating Documents for a Hypothetical 3109 IETF Foundation 3111 D.1 Sample Draft Articles of Incorporation 3113 This appendix contains standard, pro-forma Articles of Incorporation. 3114 Note well that tax lawyers often make significant alterations to 3115 standard Articles as they consider a 501(c)(3) application. They are 3116 included here merely as a sample for illustrative purposes only. 3118 'Commonwealth of Virginia -- State Corporation Commission'| 'Articles 3119 of Incorporation -- Virginia Nonstock Corporation'| Form SCC819, 3120 07/03 [17] 3121 ------ 3123 The undersigned, pursuant to Chapter 10 of Title 13.1 of the Code of 3124 Virginia, [Virginia] state(s) as follows: 3125 1. The name of the corporation is The IETF Foundation. 3126 2. The corporation shall have no members. 3127 3. The Trustees of the corporation shall be elected or appointed as 3128 specified in Article IV (Appendix D.2.5) of the Bylaws. 3129 4. Name and agent: 3130 A. The name of the corporation's initial registered agent is: 3131 XXX 3132 B. The initial registered agent is a domestic or foreign stock 3133 or nonstock corporation, limited liability company, or 3134 registered limited liability partnership authorized to 3135 transact business in Virginia. 3136 5. The initial Trustees are: XXX 3137 6. The incorporators are: XXX 3139 D.2 Sample Draft Bylaws of the IETF Foundation 3141 As with the Sample Draft Articles, the Sample Draft Bylaws included 3142 here are a pro-forma, standard version. Substantial alteration may 3143 be required as legal counsel reviews the specific nature of an 3144 incorporation. 3146 D.2.1 Article I: Organization 3148 The name of the Corporation shall be The IETF Foundation (which shall 3149 hereinafter be referred to as the "Foundation"). 3151 D.2.2 Article II: Purpose 3153 *Section 1: Purpose.* The IETF Foundation shall be operated 3154 exclusively for nonprofit educational, charitable, and scientific 3155 purposes, including, without limitation, the purposes stated in the 3156 Foundation's Articles of Incorporation. 3158 *Section 2: Restrictions.* No part of the net earnings of the IETF 3159 Foundation shall inure to the benefit of, or be distributable to, 3160 private persons, except that the Foundation shall be authorized and 3161 empowered to pay reasonable compensation for services rendered, and 3162 to make payments and distributions in furtherance of the purposes set 3163 forth in Article II, Section 1 hereof. Any other provision of these 3164 Bylaws to the contrary notwithstanding, the IETF Foundation shall not 3165 carry on any activities not permitted to be carried on by a 3166 corporation exempt from Federal Income Tax under Section 501(a) and 3167 Section 501(c)(3) of the Code. These Bylaws shall not be altered or 3168 amended in derogation of the provisions of this Section. 3170 D.2.3 Article III: Members 3172 The Foundation shall have no members and no stockholders. 3174 D.2.4 Article IV: Offices 3176 The office of the Foundation shall be as determined from time to time 3177 by the Board of Trustees within or outside of the State of Virginia. 3179 D.2.5 Article V: Board of Trustees 3181 *Section 1: Authority and Responsibilities.* The power, authority, 3182 property, and affairs of the Foundation shall at all times be 3183 exclusively exercised, controlled, and conducted by or under the 3184 authority of the Board of Trustees subject to any limitations set 3185 forth in the Articles of Incorporation and in accordance with the 3186 Virginia Nonstock Corporation Act as it now exists or hereafter may 3187 be amended. 3189 *Section 2: Board of Trustees Composition.* The Board of Trustees 3190 shall consist of seven (7) Trustees. 3192 *Section 3: Types.* There shall be two types of Trustees based on the 3193 reason for their selection: Position-Based Trustees, who are trustees 3194 because they hold some other office (for example IETF Chair) and 3195 Selected Trustees, who are not Position-Based Trustees. 3197 *Section 3: Terms.* The term of office of Position-Based Trustees 3198 shall be co-terminious with the term of the office that qualifies the 3199 individual to be a board member. The term of office of Selected 3200 Trustees shall be three (3) years or until their successors have been 3201 selected and assume office. Selected Trustees may be selected to 3202 serve multiple terms. 3204 *Section 4: Selection of the Board of Trustee* 3205 1. *Selection of Position-Based Trustees.* The Chairs of the IETF 3206 and IAB shall be the two Position-Based Trustees. These 3207 individuals are selected by IETF participants using the 3208 procedures set forth in [RFC3777] or its successor. 3209 2. *Selection of Selected Trustees.* Three Selected Trustees shall 3210 be selected by the IETF nominations process (as defined in 3211 [RFC3777] or its successor) and confirmed by the IESG. Two 3212 Selected Trustees shall be selected by the internet Society using 3213 means of their own choosing. 3214 3. *Resignation.* A Selected Trustee may resign by delivering his 3215 resignation in writing to the Foundation at its principal office 3216 or to the Secretary of the Foundation. Such resignation shall be 3217 effective upon its receipt or upon such date (if any) as is 3218 stated in such resignation, unless otherwise determined by the 3219 Board. 3220 4. *Removal.* A Selected Trustee selected by the IETF nominations 3221 process may be removed from office at any time using the 3222 procedures specified in [RFC3777] or its successor. A Selected 3223 Trustee selected by the Internet Society my be removed by the 3224 Internet Society using means of their own choosing. 3225 5. *Vacancies.* Any vacancy in the Board of Trustees shall be filled 3226 using the procedures set forth above on the composition of the 3227 Board of Trustees. The Trustees shall have and may exercise all 3228 of their powers notwithstanding the existence of one or more 3229 vacancies in their number. 3231 *Section 5: Quorum.* A majority of the Trustees shall constitute a 3232 quorum for the transaction of business. Unless otherwise stated in 3233 these Bylaws, decisions of the Board of Trustees shall be made by the 3234 concurrence of a majority of members of the Board of Trustees present 3235 and voting. If at any meeting there is no quorum present, the Board 3236 must not transact business. 3238 *Section 6: Compensation and Reimbursement.* No member of the Board 3239 of Trustees may receive compensation for his or her services as a 3240 Trustee. A Trustee shall, at their request, be reimbursed for 3241 actual, necessary and reasonable travel and subsistence expenses 3242 incurred by them in performance of their duties. 3244 *Section 7: Meetings.* The Board of Trustees shall meet at least 3245 twice annually. 3246 1. *Annual Meeting.* The Board of Trustees shall hold a public 3247 Annual Meeting at a time and place associated with the first IETF 3248 meeting each year. This Annual meeting shall be open to all IETF 3249 attendees except that the parts of the meeting dealing with 3250 personnel issues may be held in executive session. 3252 2. *Meeting Types, Methods, and Notice.* Meetings of the Board may 3253 be held from time to time at such intervals and at such places as 3254 may be fixed by the Board. Meetings of the Board may be held 3255 only in person or via teleconference. Notice of all regular 3256 meetings of the Board shall be delivered to each Trustee by 3257 e-mail or by postal mail and announced on the IETF-Announce list 3258 at least ten (10) calendar days before the meeting. Special 3259 meetings of the Board may be called for any purpose at any time 3260 by the Chairman of the Board or by any three (3) Trustees. 3261 Notice of any special meeting shall state the purpose of the 3262 meeting. A Trustee may waive notice of a meeting of the Board of 3263 Trustees by submitting a signed, written waiver of notice, either 3264 before or after the meeting. A Trustee's attendance at or 3265 participation in a meeting waives any required notice of the 3266 meeting unless at the start of such meeting or promptly upon 3267 arrival the Trustee objects to holding the meeting or transacting 3268 business at the meeting, and does not thereafter vote for or 3269 assent to action taken at the meeting. 3270 3. *Actions Taken By the Board of Trustees Without Meeting.* Any 3271 action required or permitted to be taken at any meeting of the 3272 Board of Trustees may be taken without a meeting if all Trustees 3273 consent in writing to such action. Such action shall be 3274 evidenced by written consents approving the lack of a meeting, 3275 signed by each Trustee. 3277 *Section 8: Board Committees.* The Trustees may elect or appoint one 3278 or more committees (including but not limited to an Executive 3279 Committee) and may delegate to any such committee or committees any 3280 or all of their powers, provided that any committee to which the 3281 powers of the Trustees are delegated shall consist solely of 3282 Trustees. Committees shall conduct their affairs in the same manner 3283 as is provided in these By Laws for the Trustees. The members of any 3284 committee shall remain in office at the pleasure of the Board of 3285 Trustees. 3287 *Section 9: Trustee Member Conflict of Interest.* 3288 1. As set forth in Section 9(3) below, a Trustee of the IETF 3289 Foundation who has a personal interest in a transaction, as 3290 defined below, may not participate in any discussion of that 3291 transaction by the Trustees of The IETF Foundation and may not 3292 vote to determine whether to authorize, approve, or ratify that 3293 transaction except as specifically described below. For purposes 3294 of these Bylaws, a "personal interest" is defined as any act that 3295 will provide, directly or indirectly, a financial benefit or a 3296 disparate benefit individually to the Trustee, or to a company he 3297 or she is employed by, has a significant financial interest in, 3298 or represents in any fashion. However, policies under 3299 consideration by the Foundation are likely to have an impact on 3300 the business of every Trustee. It is expected that most policy 3301 decisions will have a direct or indirect impact on the Trustee's 3302 company, but such a non-individualized interest does not 3303 constitute a "personal interest" as used in these Bylaws. A 3304 "transaction" with The IETF Foundation for purposes of these 3305 Bylaws is a contract or consultancy in which the Trustee has a 3306 direct or indirect financial benefit, or a policy under 3307 consideration that will have a disparate and unusual impact on a 3308 business with which the Trustee is directly or indirectly 3309 associated. 3310 2. The mere existence of a personal interest by a Trustee of The 3311 IETF Foundation in a transaction with The IETF Foundation shall 3312 not invalidate The IETF Foundation's ability to enter that 3313 transaction so long as the following conditions are met: (i) the 3314 material facts of the personal nature of the transaction with The 3315 IETF Foundation and the Trustee's interest in the transaction 3316 with The IETF Foundation are fully disclosed to the Board of 3317 Trustees of The IETF Foundation, either by the Trustee having a 3318 direct or indirect personal interest in the transaction with The 3319 IETF Foundation, or are brought to the attention of the Board by 3320 a third party; or (ii) the Board of Trustees of The IETF 3321 Foundation, by a vote of the disinterested Trustees of The IETF 3322 Foundation vote to authorize, approve, or ratify a transaction 3323 with The IETF Foundation; or (iii) the transaction with The IETF 3324 Foundation in which the direct or indirect personal interest of 3325 an The IETF Foundation Trustee was disclosed to the Board of 3326 Trustees of The IETF Foundation and was determined by the Board 3327 of Trustees of The IETF Foundation entitled to vote on the matter 3328 is determined by the Board of Trustees voting to be in The IETF 3329 Foundation's interests, notwithstanding the personal interest of 3330 the non-voting Trustee. 3331 3. In determining whether a conflict of interest exists, the Board 3332 of Trustees of The IETF Foundation has the prerogative, upon 3333 review of all facts and circumstances, to make its own 3334 determination of whether a conflict of interest exists and how it 3335 is appropriate to proceed. A Trustee who perceives the 3336 possibility of a conflict of interest for him or herself, or for 3337 another Board member, may raise this issue at any point prior to 3338 a vote on any issue. Any Trustee who perceives a possible 3339 conflict of interest may present justification with respect to 3340 whether or not a conflict of interest exists, but the entire 3341 Board, with the exception of the Trustee having the potential 3342 conflict of interest, shall make the final determination to 3343 proceed in such a matter. If the Board of Trustees finds there 3344 is a conflict of interest, the Trustee with the conflict may be 3345 excluded by the Chair of the Board from that portion of any 3346 meeting where a substantive discussion or decision to engage or 3347 not in such a transaction is made, except that he or she may 3348 provide any information that will assist the Trustees in such a 3349 matter before leaving such a meeting. 3351 *Section 10. Approval of Meeting Minutes.* Minutes of the Board of 3352 the IETF Foundation must be approved by a procedure adopted by the 3353 board and published on the IETF Foundation web site. 3355 D.2.6 Article VI: Officers 3357 *Section 1: Number.* The officers of the IETF Foundation shall 3358 consist of a Chairman of the Board, a Treasurer and a Secretary, and 3359 such other inferior officers as the Board of Trustees may determine. 3361 *Section 2: Election Term of Office and Qualifications.* All officers 3362 shall be elected annually by the vote of a majority of the Board of 3363 Trustees present and voting (excluding abstentions) at the Annual 3364 Meeting. The Treasurer and Secretary need not be members of the 3365 Board. The Chair of the IETF nor the chair of the IAB shall be the 3366 Chairman of the Board of the IETF Foundation. 3368 *Section 3: Resignation.* An officer may resign by delivering his 3369 written resignation to the Foundation at its principal office or to 3370 the Chair or Secretary. Such resignation shall be effective upon 3371 receipt or upon such date (if any) as is stated in such resignation, 3372 unless otherwise determined by the Board. 3374 *Section 4: Removal.* The Board of Trustees may remove any officer 3375 with or without cause by a vote of a majority of the entire number of 3376 Trustees then in office, at a meeting of the Board of Trustees called 3377 for that purpose. An officer may be removed for cause only if notice 3378 of such action shall have been given to all of the Trustees prior to 3379 the meeting at which such action is to be taken and if the officer so 3380 to be removed shall have been given reasonable notice and opportunity 3381 to be heard by the Board of Trustees. 3383 *Section 5: Vacancies.* In case any elected officer position of the 3384 IETF Foundation becomes vacant, the majority of the Trustees in 3385 office, although less than a quorum, may elect an officer to fill 3386 such vacancy at the next meeting of the Board of Trustees, and the 3387 officer so elected shall hold office and serve until the next Annual 3388 Meeting. 3390 *Section 6: Chairman of the Board.* The Chairman of the Board shall, 3391 when present, preside at all meetings of the Board of Trustees of 3392 IETF Foundation. If the Chairman is not available to preside over a 3393 meeting, the majority of the Trustees present shall select another 3394 Trustee to preside at that meeting only. 3396 *Section 7: Treasurer.* The Treasurer shall have the custody of all 3397 funds, property, and securities of the IETF Foundation, subject to 3398 such regulations as may be imposed by the Board of Trustees. He or 3399 she may be required to give bond for the faithful performance of his 3400 or her duties, in such sum and with such sureties as the Board of 3401 Trustees may require or as required by law, whichever is greater. 3402 When necessary or proper, he or she may endorse on behalf of the IETF 3403 Foundation for collection, checks, notes and other obligations, and 3404 shall deposit same to the credit of the IETF Foundation at such bank 3405 or banks or depository as the Board of Trustees may designate. He or 3406 she shall make or cause to be made such payments as may be necessary 3407 or proper to be made on behalf of the IETF Foundation. He or she 3408 shall enter or cause to be entered regularly on the books of the IETF 3409 Foundation to be kept by him or her for that purpose, full and 3410 accurate account of all monies and obligations received and paid or 3411 incurred by him or her for or on account of the IETF Foundation, and 3412 shall exhibit such books at all reasonable times to any Trustee on 3413 application at the offices of the IETF Foundation incident to the 3414 Office of Treasurer, subject to the control of the Board of Trustees. 3415 Certain duties of the Treasurer as may be specified by the Board of 3416 Trustees may be delegated by the Treasurer. 3418 *Section 8: Secretary.* The Secretary shall have charge of such 3419 books, records, documents, and papers as the Board of Trustees may 3420 determine, and shall have custody of the corporate seal. The 3421 Secretary shall keep, or cause to be kept the minutes of all meetings 3422 of the Board of Trustees. The Secretary may sign, with the Chairman, 3423 in the name and on behalf of the IETF Foundation, any contracts or 3424 agreements, and he or she may affix the corporate seal of the IETF 3425 Foundation. He or she, in general, performs all the duties incident 3426 to the Office of Secretary, subject to the supervision and control of 3427 the Board of Trustees, and shall do and perform such other duties as 3428 may be assigned to him or her by the Board of Trustees or the 3429 Chairman of the Board of Trustees. Certain duties of the Secretary 3430 as may be specified by the Board of Trustees may be delegated by the 3431 Secretary. 3433 *Section 9: Other Powers and Duties.* Each officer shall have in 3434 addition to the duties and powers specifically set forth in these By 3435 Laws, such duties and powers as are customarily incident to his 3436 office, and such duties and powers as the Trustees may from time to 3437 time designate. 3439 D.2.7 Article VII: Amendments 3441 *Section 1: By Laws.* These By Laws may be amended by an affirmative 3442 vote of a majority of the Trustees then in office (excluding 3443 abstentions) at a regular meeting of the board or a meeting of the 3444 board called for that purpose as long as the proposed changes are 3445 made available to all trustees and posted to the IETF Announce list 3446 at least 30 days before any such meeting. 3448 *Section 2: Articles of Incorporation.* The Articles of Incorporation 3449 of the IETF Foundation may amended by an affirmative vote of 3450 two-thirds vote of the Board of Trustees then in office at a regular 3451 meeting of the board or a meeting of the board called for that 3452 purpose as long as the proposed changes are made available to all 3453 trustees and posted to the IETF Announce list at least 30 days before 3454 any such meeting. 3456 D.2.8 Article VIII: Dissolution 3458 Upon the dissolution of the IETF Foundation, the IETF Foundation 3459 shall, after paying or making provisions for the payment of all of 3460 the liabilities of the Foundation, dispose of all of the assets of 3461 the IETF Foundation exclusively for the exempt purposes of the IETF 3462 Foundation in such manner or to such organization or organizations 3463 operated exclusively for social welfare or charitable purposes. Any 3464 such assets not so disposed of shall be disposed of by a court of 3465 competent jurisdiction of the county in which the principal office of 3466 the organization is then located, exclusively for such purposes. In 3467 the event of a sale or dissolution of the corporation, the surplus 3468 funds of the corporation shall not inure to the benefit of, or be 3469 distributable to, its Trustees, officers, or other private persons. 3471 D.2.9 Article IX: Miscellaneous Provisions 3473 *Section 1: Fiscal Year.* The fiscal year of the IETF Foundation 3474 shall be from January 1 to December 31 of each year. 3476 *Section 2: Execution of Instruments.* All checks, deeds, leases, 3477 transfers, contracts, bonds, notes and other obligations authorized 3478 to be executed by an officer of the Foundation in its behalf shall be 3479 signed by the Chairman of the Board or the Treasurer, or as the 3480 Trustees otherwise determine. A certificate by the Secretary as to 3481 any action taken by the Board of Trustees shall as to all persons who 3482 rely thereon in good faith be conclusive evidence of such action. 3484 *Section 3: Severability.* Any determination that any provision of 3485 these By-Laws is for any reason inapplicable, illegal or ineffective 3486 shall not affect or invalidate any other provision of these By-Laws. 3488 *Section 4: Articles of Incorporation.* All references in these By 3489 Laws to the Articles of Incorporation shall be deemed to refer to the 3490 Articles of Incorporation of the IETF Foundation, as amended and in 3491 effect from time to time. 3493 *Section 5: Gender.* Whenever used herein, the singular number shall 3494 include the plural, the plural shall include the singular, and the 3495 use of any gender shall include all genders. 3497 *Section 6: Successor Provisions.* All references herein: (1) to the 3498 Internal Revenue Code shall be deemed to refer to the Internal 3499 Revenue Code of 1986, as now in force or hereafter amended; (2) to 3500 the Code of the State of Virginia, or any Chapter thereof, shall be 3501 deemed to refer to such Code or Chapter as now in force or hereafter 3502 amended; (3) the particular sections of the Internal Revenue Code or 3503 such Code shall be deemed to refer to similar or successor provisions 3504 hereafter adopted; and (4) to the Request for Comment Series shall be 3505 deemed to refer to the Request for Comment Series as they are now in 3506 force or hereafter amended. 3508 Appendix E. Sample Draft Call for Applications -- IETF Administrative 3509 Director 3511 The IETF Administrative Entity is seeking a highly capable individual 3512 to serve as Administrative Director. You will report to the IETF 3513 Chair and be accountable to IETF community. This is a highly visible 3514 and very demanding job. You will be expected to: 3515 o Serve as the day-to-day chief operating officer of the IETF, 3516 managing a number of contractors and working with a number of 3517 volunteers. 3518 o Provide primary support for budgeting and financial reporting 3519 processes. 3520 o Serve as the primary staff resource for the governing body of the 3521 administrative entity for the IETF. 3522 o Work with your contractors and members of the IETF community to 3523 provide adequate support and planning for 3 IETF meetings 3524 annually, and for frequent meetings and teleconferences of the 3525 IAB, IESG, and other bodies that support the IETF. 3526 o Work with our liaison organizations, such as the RFC Editor and 3527 the IANA. 3528 o Coordinate the standards-making support process, in particular the 3529 periodic meetings of the IESG. 3531 The following characteristics are necessary for this job: 3532 o This job is public service. You should be able to work 3533 successfully with large numbers of people. This requires a high 3534 clock rate, a large stack, and the ability to listen carefully. 3535 o This is an operations job. IETF meetings are large and complex, 3536 and the day-to-day activities of the standards-making process is 3537 demanding. You should be adept at getting real results and 3538 helping large groups work together towards common goals and 3539 deadlines. 3540 o This job requires a financially astute individual. The IETF is a 3541 $2-$3 million/year operation. IETF funds are tight and we expect 3542 you to take leadership in establishing our budgetary procedures, 3543 our procurement standards, and understanding our revenue sources. 3545 In-depth familiarity with the IETF prior to assuming this position is 3546 not required, but you must be able to quickly get up to speed and 3547 learn the unique culture and requirements of the organization. 3548 Likewise, long-term technical experience is not required, but you 3549 must be a quick learner and adept at using the Internet effectively. 3551 You may work out of a home office as a telecommuter, or use the 3552 Internet Society facilities in Virginia. In either case, you should 3553 be prepared to travel to Virginia, IETF meetings, and the locations 3554 where the IETF has contractors. 3556 Applicants should forward a resume, references, and any other 3557 relevant materials, with a cover letter explaining why they feel they 3558 are the right person for this position to: 3559 URL 3561 Applications are due no later than XXX, however the IETF 3562 Administrative Entity reserves the right to make a decision prior to 3563 this date or to extend this date in its sole discretion. 3564 Applications will be reviewed by an evaluation committee consisting 3565 of members of the IAB, IESG, and the community, and a decision shall 3566 be made by the Chairs of the IETF and the IAB with the advice and 3567 consent of the IESG and the IAB. 3569 The list of applicants will not be posted publicly, but will be 3570 reviewed in confidence by members of the evaluation committee, the 3571 IAB, and the IESG. 3573 Appendix F. Sample Draft Request for Proposals 3575 F.1 Introduction 3577 The IETF Administrative Entity is soliciting proposals for the 3578 provision of computing and networking requirements, as detailed in 3579 this Request for Proposals ("Proposals"). Proposals from any 3580 individual person or persons or commercial or non-commercial vendor 3581 ("Vendor") are welcome. 3583 Proposals must be received in written electronic form no later than 3584 [date]. Extensions may be granted solely in the discretion of the 3585 IETF Administrative Entity. Each Proposal, together with all 3586 supporting documentation, should be delivered to the following 3587 address: 3589 [URI/ADDRESS] 3591 Any inquiries regarding this Request must be submitted in written 3592 electronic form to the address listed above. Other than such 3593 inquiries, vendors are prohibited from contacting any person or 3594 institution involved in the selection process concerning this 3595 Request. 3597 Each Proposal must specifically address each of the selection 3598 criteria listed below in a format corresponding to this Request. 3599 Each Proposal should also be accompanied by any technical or product 3600 literature that the Vendor wishes the IETF Administrative Entity to 3601 consider. If additional information is required by the IETF 3602 Administrative Entity to make a determination, such information may 3603 be requested, and shall be submitted in writing in the manner set 3604 forth above. Information other than the written Proposal and any 3605 information submitted in response to a request by the IETF 3606 Administrative Entity will not be considered by the IETF 3607 Administrative Entity. 3609 The IETF Administrative Entity reserves the right to cancel this 3610 Request, in whole or in part, at any time. The IETF Administrative 3611 Entity may reject any or all Proposals received in response to this 3612 Request in its sole discretion. The IETF Administrative Entity makes 3613 no guarantee or commitment to purchase, license or procure any goods 3614 or services resulting from this Request. 3616 Any Proposal which is selected by the IETF Administrative Entity 3617 shall be subject to execution of a binding agreement between the IETF 3618 Administrative Entity and the Vendor, which agreement shall be 3619 prepared by the IETF Administrative Entity and shall reflect the 3620 requirements outlined below and any additional provisions that are 3621 agreed upon in discussions between the IETF Administrative Entity and 3622 the Vendor. Selection may be conditioned upon acceptance of specific 3623 contractual terms and conditions, which may be provided to the Vendor 3624 during the selection process. 3626 Each Vendor is responsible for its own costs and expenses involved in 3627 preparing and submitting its Proposal and any supplemental 3628 information requested by the IETF Administrative Entity. The IETF 3629 Administrative Entity shall not reimburse any such costs or expenses. 3631 All Proposals submitted in accordance with this Request will be 3632 reviewed by a panel of experts drawn from the IETF community. A list 3633 of reviewers will be made available. The IETF Administrative Entity 3634 will notify Vendors of their selection following receipt and 3635 consideration of all Proposals. The IETF Administrative Entity will 3636 attempt to make its selection(s) by [date], but shall have full 3637 discretion to make a decision earlier or later than this date. 3639 F.2 General Provisions 3641 The following provisions apply to all bidders: 3642 1. A response may be submitted for one or more of the 6 listed 3643 support requirements. If response addresses more than one of the 3644 listed support requirements, the proposal should be written to 3645 clearly separate costs by area. The IETF Administrative Entity 3646 reserves the right to accept only a partial proposal. 3647 2. Key Person Principle: Each requirement requires the designation 3648 of one individual as the "Key Person" in your response. That 3649 person will be the individual accountable to the IETF. The IETF 3650 Administrative Entity will require a binding key personnel clause 3651 in the contract. Any change in the Key Person will require prior 3652 approval. The IETF Administrative Entity will also require a 3653 written process that describes procedures for backing up the key 3654 person when that person is not available. The IETF 3655 Administrative Entity will also require that the bidder obtain 3656 and maintain key person insurance for dealing with the 3657 possibility that the designated key person becomes unavailable. 3658 3. The IETF Administrative Entity encourages zero-cost or zero-cost 3659 plus materials bids, but will insist on a binding agreement. 3660 4. The IETF Administrative Entity encourages bids from individuals 3661 as well as public and private institutions as long as the above 3662 conditions are met. You should submit a detailed work history of 3663 each individual, personal references, and a detailed description 3664 of any sub-contractual arrangements you have put in place to 3665 assist you. 3666 5. Appropriate insurance and other mechanisms to minimize the 3667 liability of the IETF Administrative Entity should be discussed 3668 in your proposal. 3670 F.3 Requirement 1: Core Network Infrastructure 3672 [Ed. This section will contain service level specifications. E.g., 3673 core bandwidth requirements, CPU capacity, disk space, and other 3674 variables. It will also contain core specifications, such as 3675 routing, DNS, and other services.] 3677 F.4 Requirement 2: Systems Administration Services 3679 [Ed. This section will contain the description for the Systems 3680 Administration function, including such tasks as keeping key software 3681 subsystems such as Apache installed and up-to-date, support for 3682 users, operating system upgrades, and other similar tasks.] 3684 F.5 Requirement 3: Postmaster of the IETF Administrative Entity 3686 The Postmaster of the IETF Administrative Entity is responsible for 3687 the functioning and archiving of numerous mailing lists maintained by 3688 the IETF and for archiving specific IETF-related mailing lists 3689 maintained by others. Note that the archives of most IETF mailing 3690 lists are public and the bidder must describe how such archives will 3691 be accessed by the public. 3693 The core mailing is described in [RFC3005], and a policy with regards 3694 to posting rights may be found in [RFC3683]. You will find 3695 additional information on IETF mailing lists at: 3696 3698 In addition, the IETF maintains several dozen members-only lists in 3699 support of bodies such as the IAB, the IESG, and certain IRTF task 3700 forces (see [RFC2014], [RFC2850], and [RFC3710] for more details on 3701 these bodies). IETF administrators and chairs of various groups 3702 typically will form ad hoc lists which they administer for various 3703 tasks. 3705 Familiarity and expertise in administering high-volume lists and in 3706 maintaining large numbers of archived lists is necessary. The 3707 ability to provide administrative facilities that allow the IETF to 3708 delegate authority for moderation and creation of lists is also 3709 necessary. Finally, you should be experienced in the very latest 3710 spam fighting technologies. 3712 You may propose to provide service in one of two ways: 3713 o Move the IETF mail handling onto an existing well-provisioned 3714 infrastructure that you are responsible for. 3715 o Provide mail services on machines that are maintained by the IETF. 3717 Your bid should clearly explain what tools you will use, the types of 3718 interfaces you will provide to list maintainers and participants, and 3719 you would handle issues such as spam. You should also be very clear 3720 in your proposal about your understanding of the role and duties of 3721 the postmaster. 3723 F.6 Requirement 4: Webmaster of the IETF Administrative Entity 3725 This task has the responsibility for the look and feel of the IETF 3726 network presence, particularly the web site. A series of support 3727 contracts will be available to help support this function. 3729 In addition, this task has responsibility to provide overall support, 3730 in cooperation with the sysadmin and other contractors, to a variety 3731 of working groups, directorates, and other activities that require a 3732 workspace. 3734 Your proposal must demonstrate that you are experienced at producing 3735 highly standards-conformant and functional network presences and 3736 supporting a large and diverse community of users. This is a highly 3737 hands-on task. 3739 F.7 Requirement 5: Meetings 3741 We are looking for creative proposals from experienced professionals 3742 to organize and support the meetings of the IETF. 3744 You will work with the Administrative Director of the IETF and the 3745 IETF leadership to organize the three annual meetings of the IETF. 3746 Based on current practice, you should expect 1-2 of those meetings to 3747 be in the United States and 1-2 of those meetings to be in other 3748 countries, though this may change based on the requirements of the 3749 IETF. We expect approximately 1500 attendees per meeting, though in 3750 the past this number has approached 3,000 based on the location of 3751 the meeting and the state of the economy. 3753 You should have very strong experience in meeting planning, 3754 particularly working meetings with large numbers of participants. 3755 You should be intimately familiar with the details of booking 3756 appropriate venues, working with hotel and conference center staff, 3757 and providing clear and concise communications with meeting 3758 attendees. 3760 Your proposal should detail the mechanisms you would use to provide a 3761 simple registration and payment procedure for attendees. You will be 3762 able to draw on webmaster and sysadmin support for the IETF, for 3763 example, if you would like to provide a secure payment mechanism on 3764 the IETF web site. Your proposal should also detail how you will 3765 provide additional resources on-site (e.g., staffing a registration 3766 desk and other requirements that require additional people). 3768 As part of this function, you will work with Local Hosts (when 3769 available), who provide a sophisticated network infrastructure to 3770 support the meeting, as well as a team of volunteers who provide 3771 additional terminal room support, real-time audio and video streaming 3772 from the meeting and other functions. 3774 F.8 Requirement 6: Clerk of the IETF Administrative Entity 3776 This requirement is for general high-level administrative support for 3777 the day-to-day functioning of the IETF. You will work with the 3778 Administrative Director of the IETF to help make the organization 3779 function smoothly on a day-to-day basis. 3781 The tasks that are encompassed in this function include: 3782 o Supporting the working group charter process, which includes 3783 processing the initial charter, rechartering, milestone 3784 management, and closing of the working group. 3785 o Publication of Internet-Drafts. It is assumed that current 3786 efforts to automate the submission process will be successful, 3787 alleviating much of the manual effort that this function currently 3788 has. 3789 o Document tracking, including a ticket-system-based response to 3790 document and working group management problems, announcements of 3791 last calls, and a variety of other functions. 3792 o Managing IESG meetings, including scheduling, creation of the 3793 agenda, and collecting the minutes, as well as the creation and 3794 long-term archiving of IETF meeting proceedings. 3795 o Handling the Intellectual Property Rights disclosure process (a 3796 process which is presently undergoing automation). 3797 o Publication of official actions, such as document approvals, 3798 including communication of such status to groups such as the RFC 3799 Editor. 3800 o Registration and publication of liaison statements from other 3801 standards bodies and publication of liaison statements, responses 3802 and other communications by the IETF to Standards Development 3803 Organizations (SDOs). 3804 o Support of the Nominating Committee. 3805 o Assisting the Meeting Planners in crafting an appropriate agenda 3806 for the IETF meetings, a complex task that requires a fairly 3807 detailed knowledge of the IETF operation. 3809 [Ed. More detail to be filled in here by a transition team.] 3811 F.9 Selection Criteria and Evaluation Process 3813 All proposals will be evaluated using a process that consists of the 3814 following steps: 3815 1. An evaluation committee will be formed by the IETF and IAB 3816 Chairs, and will include the Administrative Director of the IETF 3817 Administrative Entity. 3818 2. The evaluation committee will perform an initial evaluation of 3819 submitted responses. 3820 3. A dialogue will be started with selected responses. 3821 4. The IETF will decide on the initial best candidate. 3822 5. The A further dialogue will ensue with that candidate. 3823 6. A contract may be signed or the discussion may continue with 3824 other candidates. 3826 The IETF Administrative Entity will consider price, experience, 3827 technical smarts, and a variety of other factors. Note well that the 3828 IETF Administrative Entity will not decide on price alone. Overall 3829 benefit to the IETF community will be the prime consideration. 3831 Index 3833 F 3834 functions 6, 6, 10, 11, 13, 16, 17 3836 M 3837 mechanisms 34, 34, 34, 34, 34, 34, 34, 34 3839 O 3840 opinions 16, 23 3841 options 1, 7, 9, 22, 22, 24, 27, 38 3843 P 3844 pillars 6, 6, 6 3846 R 3847 recommendations 8, 20, 21, 21, 28, 28, 37 3849 S 3850 strategies 22, 22, 22 3852 Intellectual Property Statement 3854 The IETF takes no position regarding the validity or scope of any 3855 Intellectual Property Rights or other rights that might be claimed to 3856 pertain to the implementation or use of the technology described in 3857 this document or the extent to which any license under such rights 3858 might or might not be available; nor does it represent that it has 3859 made any independent effort to identify any such rights. Information 3860 on the procedures with respect to rights in RFC documents can be 3861 found in BCP 78 and BCP 79. 3863 Copies of IPR disclosures made to the IETF Secretariat and any 3864 assurances of licenses to be made available, or the result of an 3865 attempt made to obtain a general license or permission for the use of 3866 such proprietary rights by implementers or users of this 3867 specification can be obtained from the IETF on-line IPR repository at 3868 http://www.ietf.org/ipr. 3870 The IETF invites any interested party to bring to its attention any 3871 copyrights, patents or patent applications, or other proprietary 3872 rights that may cover technology that may be required to implement 3873 this standard. Please address the information to the IETF at 3874 ietf-ipr@ietf.org. 3876 Disclaimer of Validity 3878 This document and the information contained herein are provided on an 3879 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3880 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3881 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3882 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3883 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3884 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3886 Copyright Statement 3888 Copyright (C) The Internet Society (2004). This document is subject 3889 to the rights, licenses and restrictions contained in BCP 78, and 3890 except as set forth therein, the authors retain all their rights. 3892 Acknowledgment 3894 Funding for the RFC Editor function is currently provided by the 3895 Internet Society.