idnits 2.17.1 draft-wasserman-iasa-bcp-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 637. ** 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 : ---------------------------------------------------------------------------- ** There are 88 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 423 has weird spacing: '...ng will be:...' -- 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 (October 25, 2004) is 7113 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: 'RFC3667' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 592, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 3716 ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3667 (Obsoleted by RFC 3978) -- Obsolete informational reference (is this intentional?): RFC 3668 (Obsoleted by RFC 3979) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wasserman 3 Internet-Draft ThingMagic 4 Expires: April 25, 2005 L. Daigle 5 VeriSign 6 October 25, 2004 8 Structure of the IETF Administrative Support Activity (IASA) 9 draft-wasserman-iasa-bcp-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 25, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document describes the structure of the IETF Administrative 45 Support Activity (IASA) as an IETF-controlled activity housed within 46 the Internet Society (ISOC) legal umbrella. It defines the roles and 47 responsibilities of the IETF Administrative Oversight Committee 48 (IAOC), the IETF Administrative Director (IAD) and ISOC in the fiscal 49 and administrative support of the IETF standards process. It also 50 defines how the IAOC will be comprised and selected. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Structure of the IASA . . . . . . . . . . . . . . . . . . . . 3 56 2.1 IAD Responsibilities . . . . . . . . . . . . . . . . . . . 4 57 2.2 IAD Committees . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3 IAOC Responsibilities . . . . . . . . . . . . . . . . . . 6 59 2.4 Relationship of the IAOC to Existing IETF Leadership . . . 6 60 2.5 IAOC Decision Making . . . . . . . . . . . . . . . . . . . 7 61 3. IAOC Membership, Selection and Accountability . . . . . . . . 7 62 3.1 Initial IAOC Selection . . . . . . . . . . . . . . . . . . 8 63 4. IASA Funding . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. IASA Budget Process . . . . . . . . . . . . . . . . . . . . . 10 65 6. ISOC Responsibilities for IASA . . . . . . . . . . . . . . . . 10 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 69 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 72 11.2 Informative References . . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 74 Intellectual Property and Copyright Statements . . . . . . . . 15 76 1. Introduction 78 This document describes the structure of the IETF Administrative 79 Support Activity (IASA) as an IETF-controlled activity housed within 80 the Internet Society (ISOC) legal umbrella. It defines the roles and 81 responsibilities of the IETF Administrative Oversight Committee 82 (IAOC), the IETF Administrative Director (IAD) and ISOC in the fiscal 83 and administrative support of the IETF standards process. It also 84 defines how the IAOC is comprised and selected. 86 The IETF undertakes its technical activities as an ongoing, open, 87 consensus-based process. The Internet Society has long been a part 88 of the IETF's standards process, and this document does not affect 89 the ISOC-IETF working relationship concerning standards development 90 or communication of technical advice. The purpose of this document 91 is to define an administrative support activity that is responsive to 92 the administrative needs of the IETF technical community, as well as 93 consistent with ISOC's operational, financial and fiduciary 94 requirements. 96 The IETF Administrative Support Activity (IASA) provides the 97 administrative structure required to support the IETF standards 98 process and to support the technical activities of the IETF, 99 including the IESG, the IAB, IETF working groups and the IRTF. This 100 includes, as appropriate, undertaking or contracting for the work 101 described in [RFC3716], including IETF document and data management, 102 IETF meetings, and any operational agreements or contracts with the 103 RFC Editor and IANA. The IASA is also responsible for the financial 104 activities associated with IETF administrative support such as 105 collecting IETF meeting fees, paying invoices, managing budgets and 106 financial accounts, etc. 108 The IASA is responsible for ensuring that the IETF's administrative 109 needs are met and met well; it is not expected that the IASA will 110 undertake the bulk of this work directly, but rather that IASA will 111 contract this work from others, and manage the contractual 112 relationships in line with key operating principles such as 113 efficiency, transparency and cost effectiveness. 115 The IASA is distinct from other IETF-related technical functions, 116 such as the RFC Editor, the Internet Assigned Numbers Authority 117 (IANA), and the IETF standards process itself. The IASA has no 118 influence on the technical decisions of the IETF or on the technical 119 contents of IETF work. 121 2. Structure of the IASA 123 The IASA will be structured to allow accountability and transparency 124 of the IETF administrative and fiscal activities to the IETF 125 community. The IASA will be directed and overseen by the IETF 126 Administrative Oversight Committee (IAOC). The IAOC will consist of 127 volunteers, all chosen directly or indirectly by the IETF community, 128 as well as appropriate ex officio appointments from ISOC and IETF 129 leadership. The IAOC will be accountable to the IETF community for 130 the effectiveness, efficiency and transparency of the IASA. 132 The IASA will initially consist of a single full-time ISOC employee, 133 the IETF Administrative Director (IAD), who will have executive-level 134 responsibility for the IASA. The IAD will require a variety of 135 financial, legal and administrative support, and it is expected that 136 this support will be provided by ISOC support staff or consultants 137 following an expense and/or allocation model determined by ISOC in 138 consultation with the IAOC. 140 Although the IAD will be an ISOC employee, he or she will work under 141 the direction of the IAOC. The IAD will be selected and hired by a 142 committee of the IAOC. The members of this committee will be 143 appointed by the IAOC, and will consist minimally of the ISOC 144 President and the IETF Chair. This same committee will be 145 responsible for periodically reviewing the performance of the IAD and 146 determining any changes to his or her employment and compensation. 148 Most IETF administrative functions will be outsourced via 149 well-defined contracts or equivalent instruments. The IAD will be 150 responsible for negotiating and maintaining those contracts, as well 151 as providing any coordination that is necessary to make sure the IETF 152 administrative support functions are properly covered. 154 2.1 IAD Responsibilities 156 The IAD will be responsible for working with the IAOC and others to 157 understand the administrative requirements of the IETF and for 158 managing the IASA to meet those needs. This will include determining 159 the structure of the IASA effort, establishing an operating budget, 160 negotiating contracts with service providers, managing the business 161 relationship with those providers and establishing mechanisms to 162 track their performance. The IAD may also manage ISOC support staff 163 or other IASA-related contractors or employees, as necessary. 165 The IAD will be responsible for running IASA in an open and 166 transparent manner and for producing regular (monthly, quarterly and 167 annual) financial and operational updates for IAOC and IETF community 168 review. 170 The IAD will be responsible for administering the IETF finances, 171 managing a separate financial account for the IASA, and establishing 172 and administering the IASA budget. While it is understood that ISOC 173 will need to put some financial controls in place to protect ISOC's 174 fiscal stability, the IAD (with IAOC approval, as appropriate) should 175 have signing authority consistent with carrying out IASA work 176 effectively, efficiently and independently. If there are any 177 problems regarding the level of financial approval granted to the 178 IAD, the IAOC and ISOC commit to working out a policy that is 179 mutually agreeable. 181 Service contracts will be negotiated by the IAD (with input from any 182 other appropriate bodies) and reviewed, as appropriate, by the IAOC. 183 It is expected that the IAOC will establish guidelines for what level 184 of review is expected based on contract type, size, cost and/or 185 duration. The contracts will be executed by ISOC, on behalf of the 186 IASA, after whatever review ISOC requires in order to ensure that the 187 contracts meet ISOC's legal and financial requirements. 189 Although the approval of the ISOC President/CEO or ISOC Board of 190 Trustees may be required for some contracts, their review should be 191 limited to protecting ISOC's liabilities and financial stability. 192 The IAD and IAOC are responsible for making all business decisions 193 regarding the IASA. In particular, the ISOC Board of Trustees will 194 not have direct influence over the choice of IASA contractors or IETF 195 meeting sponsors. This restriction is meant to enforce the 196 separation between fund raising and the actual operation of the 197 standards process. 199 The IAD will prepare an annual budget, which will be reviewed and 200 approved by the IAOC. The IAD will be responsible for presenting 201 this budget to the ISOC Board of Trustees, as part of ISOC's annual 202 financial planning process. The IAOC is responsible for ensuring the 203 suitability of the budget for meeting the IETF community's 204 administrative needs, but the IAOC does not bear fiduciary 205 responsibility for ISOC. Therefore, the ISOC Board also needs to 206 review and understand the budget and planned activity in enough 207 detail to properly carry out their fiduciary responsibility. Each 208 year, the complete IASA budget will published to the IETF community. 210 Unless explicitly delegated with the consent of the IAOC, the IAD 211 will also fill the role of the IETF Executive Director, as described 212 in various IETF process BCPs. 214 2.2 IAD Committees 216 The IAD may constitute special-purpose, chartered committees to bring 217 in expertise (e.g., financial, IETF process, tools), engage 218 volunteers in IASA activities and/or benefit from additional 219 perspectives. These committees may consist of subsets of the IAOC, 220 IAB or IESG, selected IETF participants, or external experts, 221 depending on the need. These committees are advisory in nature -- 222 the IAD is responsible for the outcome, including presenting and 223 supporting any decisions or work items to the IAOC and the IETF 224 community, as appropriate. 226 2.3 IAOC Responsibilities 228 The role of the IAOC is to provide appropriate direction to the IAD, 229 review the IAD's regular reports, and oversee the IASA functions to 230 ensure that the administrative needs of the IETF community are being 231 properly met. The IAOC is not expected to be regularly engaged in 232 the day-to-day administrative work of IASA, but rather to provide 233 appropriate direction, oversight and approval. 235 Therefore, the IAOC's responsibilities are: 237 o Select the IAD and provide high-level review and direction for his 238 or her work. It is expected that this task will be handled by a 239 sub-committee, as described above. 241 o Review the IAD's plans and contracts to ensure that they will meet 242 the administrative needs of the IETF. Track whether the IASA 243 functions are meeting the IETF community's administrative needs, 244 and work with the IAD to determine a plan for corrective action if 245 they are not. 247 o Review the IAD's budget proposals to ensure that they will meet 248 the IETF's needs, and review the IAD's regular financial reports. 250 o Ensure that the IASA is run in a transparent and accountable 251 manner. While the work may be delegated to the IAD and others, 252 the IAOC is responsible for ensuring that IASA finances and 253 operational status are appropriately tracked and that monthly, 254 quarterly and annual financial and operational reports are 255 published to the IETF community. 257 The IAOC's role is to direct and review, not perform, the work of the 258 IAD and IASA. It is expected the IAOC will have periodic 259 teleconferences and face-to-face meetings, as needed to efficiently 260 and effectively carry out their duties. 262 2.4 Relationship of the IAOC to Existing IETF Leadership 264 The IAOC will be directly accountable to the IETF Community. 265 However, the nature of the IAOC's work will involve treating the IESG 266 and IAB as internal customers. The IAOC and the IAD should not 267 consider their work successful unless the IESG and IAB are satisfied 268 with the administrative support that they are receiving. 270 2.5 IAOC Decision Making 272 The IAOC attempts to reach all decisions unanimously. If unanimity 273 cannot be achieved, the IAOC chair may conduct informal polls to 274 determine the consensus of the group. In cases where it is 275 necessary, some decisions may be made by voting. For the purpose of 276 judging consensus or voting, only full members of the IAOC (including 277 ex officio members, but not liaisons) will be counted. 279 Decisions of IAOC members or the entire IAOC are subject to appeal 280 using the procedures described in RFC 2026 [RFC2026]. Appeals of 281 IAOC decisions will go to the IESG and continue up the chain as 282 necessary (to the IAB and the ISOC Board). The IAOC will play no 283 role in appeals of WG Chair, IESG or IAB decisions. 285 3. IAOC Membership, Selection and Accountability 287 The IAOC will consist of seven voting members who will be selected as 288 follows: 290 o 2 members chosen by the IETF Nominations Committee (NomCom) 292 o 1 member chosen by the IESG 294 o 1 member chosen by the IAB 296 o 1 member chosen by the ISOC Board of Trustees 298 o The IETF Chair (ex officio) 300 o The ISOC President/CEO (ex officio) 302 There will also be two non-voting, ex officio liaisons: 304 o The IAB Chair 306 o The IETF Administrative Director 308 [Note: There is some question about whether the IAB Chair should be a 309 liaison or a full member of the IAOC. There are multiple trade-offs 310 here, and this should be discussed by the community.] 312 The members of the IAOC will typically serve two year terms. IAOC 313 terms will normally end at the first IETF meeting of a year, similar 314 to IAB and IESG terms. 316 The members of the IAOC will choose their own chair each year using a 317 consensus mechanism of their choosing. Any appointed member of the 318 IAOC may serve as the IAOC Chair (i.e., not the IETF Chair, the ISOC 319 President/CEO or a liaison). The role of the IAOC Chair is to 320 organize the IAOC. The IAOC Chair has no formal duties for 321 representing the IAOC, except as directed by IAOC consensus. 323 The two NomCom selected members will be selected using the procedures 324 described in RFC 3777 [RFC3777]. For the initial IAOC selection, the 325 IESG will provide the list of desired qualifications for these 326 positions. In later years, this list will be provided by the IAOC. 327 The IESG will serve as the confirming body for IAOC appointments. 329 While there are no hard rules regarding how the IAB and the IESG 330 should select members of the IAOC, it is not expected that they will 331 typically choose current IAB or IESG members, if only to avoid 332 overloading the existing leadership. They should choose people with 333 some knowledge of contracts and financial procedures who are familiar 334 with the administrative support needs of the IAB, the IESG and/or the 335 IETF standards process. It is suggested that a fairly open process 336 be followed for these selections, perhaps with an open call for 337 nominations and/or a period of public comment on the candidates. The 338 IAB and IESG are encouraged to look at the procedure for IAB 339 selection of ISOC Trustees for an example of how this might work. 340 After we gain some experience with IAOC selection, these selection 341 mechanisms should be more formally documented. 343 Although the IAB, IESG and ISOC BoT will choose some members of the 344 IAOC, those members will not directly represent the bodies that chose 345 them. All members of the IAOC are accountable directly to the IETF 346 community. To receive direct feedback from the community, the IAOC 347 will hold an open meeting at least once per year at an IETF meeting. 348 This may take the form of an open IAOC plenary or a working meeting 349 held during an IETF meeting slot. The form and contents of this 350 meeting are left to the discretion of the IAOC Chair. The IAOC 351 should also consider open mailing lists or other means to establish 352 open communication with the community. 354 In the event that an IAOC member abrogates his duties or acts against 355 the bests interests of the IETF community, IAOC members are subject 356 to recall. Any appointed IESG member, including those appointed by 357 the IAB, IESG or ISOC Board of Trustees, may be recalled using the 358 recall procedure defined in RFC 3777 [RFC3777]. IAOC members are not 359 subject to recall by the body that appointed them. 361 3.1 Initial IAOC Selection 363 The initial IAOC selection will start after this document is approved 364 as a BCP by the IESG and accepted by the ISOC Board of Trustees. The 365 IESG, IAB and ISOC should make their selections within 45-days of BCP 366 approval, and the NomCom should make their selections as quickly as 367 possible while complying with the documented NomCom procedures. The 368 IAOC will become active as soon as a majority (three or more) of the 369 appointed members are selected. 371 Initially, the IESG and ISOC Board will make one-year appointments, 372 the IAB will make a two-year appointment, and the NomCom will make 373 one one-year appointment and one two-year appointment to establish a 374 pattern where approximately half of the IAOC is selected each term. 376 4. IASA Funding 378 The IASA is supported financially in 3 ways: 380 1. IETF meeting revenues. The IAD, in consultation with the IAOC, 381 sets the meeting fees as part of the budgeting process. All 382 meeting revenues go into the IASA account. 384 2. Designated ISOC donations. The IETF and IASA undertake no fund 385 raising activities; this maintains separation between fund 386 raising and standards activities. Any organization interested in 387 supporting the IETF activity will continue to be directed to 388 ISOC, and any funds ISOC receives specifically for IETF 389 activities (as part of any ISOC program that allows for specific 390 designations) will also be put into the IASA account. 392 3. Other ISOC support. ISOC will deposit in the IASA account, each 393 quarter, other funds that ISOC has committed to providing as part 394 of the IASA budget (where the meeting revenues and specific 395 donations do not cover the budget). 397 Note that the goal is to achieve and maintain a viable IETF support 398 function based on meeting fees and specified donations, and the IAOC 399 and ISOC are expected to work together to attain that goal. (I.e., 400 dropping the meeting fees to $0 and expecting ISOC to pick up the 401 slack is not desirable; nor is raising the meeting fees to 402 prohibitive levels to fund all non-meeting-related activities). 404 In normal operating circumstances, the IASA would look to have an 405 operating reserve for its activities sufficient to cover 6-months of 406 non-meeting operational expenses, plus twice the recent average for 407 meeting contract guarantees. Rather than having the IASA attempt to 408 accrue that reserve in its separate account, the IASA looks to ISOC 409 to build and provide that operational reserve (through whatever 410 mechanisms ISOC deems appropriate -- line of credit, financial 411 reserves, meeting cancellation insurance, etc). Such reserves do not 412 appear instantaneously; the goal is to reach this level of reserves 413 by 3 years after the creation of the IASA. It is not expected that 414 any funds associated with such reserve will be held in the IASA 415 account, just that ISOC will have them on-hand for use in the event 416 of IETF meeting cancellation or other unexpected fiscal emergencies. 418 5. IASA Budget Process 420 While the IASA sets a budget for the IETF's administrative needs, its 421 budget process clearly needs to be closely coordinated with ISOC's. 422 The specific timeline will be established each year. A general 423 annual timeline for budgeting will be: 425 July 1: The IAD presents a budget proposal (for the following fiscal 426 year, with 3 year projections) to the IAOC. 428 August 1: The IAOC approves the budget proposal for IETF purposes, 429 after any appropriate revisions. As the ISOC President is part of 430 the IAOC, the IAOC should have a preliminary indication of how the 431 budget will fit with ISOC's own budgetary expectations. The 432 budget proposal is passed to the ISOC Board of Trustees for review 433 in accordance with their fiduciary duty. 435 September 1: The ISOC Board of Trustees approves the budget proposal 436 provisionally. During the next 2 months, the budget may be 437 revised to be integrated in ISOC's overall budgeting process. 439 November 1: Final budget to the ISOC Board for approval. 441 The dates described above are subject to change, and will most likely 442 be modified based on the dates of the summer and fall IETF meetings. 444 The IAD will provide monthly accountings of expenses, and will update 445 forecasts of expenditures quarterly. This may necessitate the 446 adjustment of the IASA budget. The revised budget will need to be 447 approved by the IAOC, the ISOC President/CEO and, if necessary, the 448 ISOC Board of Trustees. 450 6. ISOC Responsibilities for IASA 452 Within ISOC, support for the IASA should be structured to meet the 453 following goals: 455 Transparency: The IETF community should have complete visibility into 456 the financial and legal structure of the ISOC standards activity. 457 In particular, the IETF community should have access to a detailed 458 budget for the entire standards activity, quarterly financial 459 reports and audited annual financials. In addition, key contract 460 material and MOUs should be publicly available. Most of these 461 goals are already met by ISOC today. The IAOC will be responsible 462 for providing the IETF community with regular overviews of the 463 state of affairs. 465 Unification: As part of this arrangement, ISOC's sponsorship of the 466 RFC Editor, IAB and IESG will be managed as part of the IASA under 467 the IAOC. 469 Independence: The IASA should be financially and legally distinct 470 from other ISOC activities. IETF meeting fees should be deposited 471 in a separate IETF-specific financial account and used to fund the 472 IASA under the direction and oversight of the IAOC. Any fees or 473 payments collected from IETF meeting sponsors should also be 474 deposited into this account. This account will be administered by 475 the IAD and used to fund the IASA in accordance with a budget and 476 policies that are developed as described above. 478 Support: ISOC may, from time to time, choose to transfer other funds 479 into this account to fund IETF administrative projects or to cover 480 IETF meeting revenue shortfalls. There may also be cases where 481 ISOC chooses to loan money to the IASA to help with temporary cash 482 flow issues. These cases should be carefully documented and 483 tracked on both sides. ISOC will work to provide the operational 484 reserve for IASA functioning described above. 486 Removability: While there is no current plan to transfer the legal 487 and financial home of the IASA to another corporation, the IASA 488 should be structured to enable a clean transition in the event 489 that the IETF community decides, through BCP publication, that 490 such a transition is required. In that case, the IAOC will give 491 ISOC a minimum of six-months notice before the transition formally 492 occurs. During that period, the IAOC and ISOC will work together 493 to create a smooth transition that does not result in any 494 significant service outages or missed IETF meetings. All 495 contracts that are executed by ISOC as part of the IASA should 496 either include a clause allowing termination or transfer by ISOC 497 with six months notice, or should be transferrable to another 498 corporation in the event that the IASA is transitioned away from 499 ISOC in the future. Any accrued funds, and IETF-specific 500 intellectual property rights (concerning administrative data 501 and/or tools) would also be expected to be transitioned to the new 502 entity, as well. 504 Within the constraints outlined above, all other details of how to 505 structure this activity within ISOC (e.g. as a cost center, a 506 department or a formal subsidiary) shall be determined by ISOC in 507 consultation with the IAOC. 509 7. Security Considerations 511 This document describes the structure of the IETF's administrative 512 support activity. It introduces no security considerations for the 513 Internet. 515 8. IANA Considerations 517 This document has no IANA considerations in the traditional sense. 518 However, some of the information in this document may affect how the 519 IETF standards process interfaces with IANA, so IANA may be 520 interested in the contents. 522 9. Acknowledgements 524 The authors would like to thank the following people for their 525 feedback on the original "Scenario O" e-mail message and/or 526 intermediate versions of this document: Harald Alvestrand, Brian 527 Carpenter, Dave Crocker, Tony Hain, Joel Halpern, Eliot Lear, Bert 528 Wijnen 530 This document was written using the xml2rfc tool described in RFC 531 2629 [RFC2629]. 533 10. Change Log 535 This document was produced as part of the overall IETF Administrative 536 Restructuring (AdminRest) effort. Information about the effort and 537 related documents can be found at: 539 http://www.alvestrand.no/ietf/adminrest 541 We are using an issue tracker to track the editorial and substantive 542 feedback on this document. It can be found at: 544 https://rt.psg.com (user: ietf, password: ietf, queue: scenario-o). 546 Changes in the -01 Version: 548 o Tuned the IAD job description to make it clear that the IAD has 549 executive-level responsibility for IASA, serving under the 550 direction (not day-to-day management) of the IAOC. 552 o Added the concept of IAD committees, taken from the original 553 AdminRest proposal. 555 o Added text about the initial IAOC selection. 557 o Editorial clean-up. 559 Origination of the -00 Version: 561 The -00 version was derived from an e-mail message written by the 562 authors and posted to the IETF by Leslie Daigle. The original 563 message can be found at: 565 http://www1.ietf.org/mail-archive/web/ietf/current/msg31326.html 567 This document was derived from the "Draft BCP" portion of that 568 message and has been updated based on comments received. 570 11. References 572 11.1 Normative References 574 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 575 3", BCP 9, RFC 2026, October 1996. 577 [RFC3716] Advisory, IAB., "The IETF in the Large: Administration and 578 Execution", RFC 3716, March 2004. 580 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 581 Recall Process: Operation of the Nominating and Recall 582 Committees", BCP 10, RFC 3777, June 2004. 584 11.2 Informative References 586 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 587 June 1999. 589 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 590 3667, February 2004. 592 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 593 Technology", BCP 79, RFC 3668, February 2004. 595 Authors' Addresses 597 Margaret Wasserman 598 ThingMagic 599 One Broadway, 14th Floor 600 Cambridge, MA 02142 601 USA 603 Phone: +1 617 758-4177 604 EMail: margaret@thingmagic.com 605 URI: http://www.thingmagic.com 607 Leslie Daigle 608 VeriSign 609 21355 Ridgetop Circle 610 Dulles, VA 20176 611 USA 613 EMail: leslie@verisignlabs.com, leslie@thinkingcat.com 615 Intellectual Property Statement 617 The IETF takes no position regarding the validity or scope of any 618 Intellectual Property Rights or other rights that might be claimed to 619 pertain to the implementation or use of the technology described in 620 this document or the extent to which any license under such rights 621 might or might not be available; nor does it represent that it has 622 made any independent effort to identify any such rights. Information 623 on the procedures with respect to rights in RFC documents can be 624 found in BCP 78 and BCP 79. 626 Copies of IPR disclosures made to the IETF Secretariat and any 627 assurances of licenses to be made available, or the result of an 628 attempt made to obtain a general license or permission for the use of 629 such proprietary rights by implementers or users of this 630 specification can be obtained from the IETF on-line IPR repository at 631 http://www.ietf.org/ipr. 633 The IETF invites any interested party to bring to its attention any 634 copyrights, patents or patent applications, or other proprietary 635 rights that may cover technology that may be required to implement 636 this standard. Please address the information to the IETF at 637 ietf-ipr@ietf.org. 639 Disclaimer of Validity 641 This document and the information contained herein are provided on an 642 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 643 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 644 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 645 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 646 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 647 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 649 Copyright Statement 651 Copyright (C) The Internet Society (2004). This document is subject 652 to the rights, licenses and restrictions contained in BCP 78, and 653 except as set forth therein, the authors retain all their rights. 655 Acknowledgment 657 Funding for the RFC Editor function is currently provided by the 658 Internet Society.