RFC 4071

Structure of the IETF Administrative Support Activity (IASA)

📅 published April 2005, from ietf

RFC 4071 🎀 is called Structure of the IETF Administrative Support Activity (IASA). It's a Best Current Practice, filed as BCP 101, and it came out in April 2005. The editors are R. Austein, Ed. from ISC and B. Wijnen, Ed. from Lucent Technologies. It's part of the Network Working Group stream. The header doesn't list anything it obsoletes or updates, so this one stands on its own 🦋.

Status of This Memo 💌

This doc is a Best Current Practice for the whole Internet community 🌈, and it's literally asking you to discuss it and send suggestions for improvements 💬. Distribution of this memo is unlimited, so share it with everyone 💖.

Copyright (C) The Internet Society (2005).

Abstract ✨

This doc explains how the IETF Administrative Support Activity (IASA) is set up as an activity housed inside the Internet Society (ISOC) 🏠. It spells out the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC for the money and admin side of the IETF standards process 💼. It also covers who sits on the IAOC and how they get selected 🗳️.

Table of Contents 📚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Definitions and Principles . . . . . . . . . . . . . . . . . .  3
    2.1.  Alphabet Soup  . . . . . . . . . . . . . . . . . . . . .  3
    2.2.  Principles of the IASA, IETF, and ISOC Relationship  . .  4
    2.3.  Community Consensus and Grant of Authority . . . . . . .  5
    2.4.  Termination and Change . . . . . . . . . . . . . . . . .  5
    2.5.  Effective Date for Commencement of IASA  . . . . . . . .  5
3.  Structure of the IASA  . . . . . . . . . . . . . . . . . . . .  5
    3.1.  IAD Responsibilities . . . . . . . . . . . . . . . . . .  7
    3.2.  IAOC Responsibilities  . . . . . . . . . . . . . . . . .  9
    3.3.  Relationship of the IAOC to Existing IETF Leadership . . 10
    3.4.  IAOC Decision Making . . . . . . . . . . . . . . . . . . 10
    3.5.  Review and Appeal of IAD and IAOC Decision . . . . . . . 10
4.  IAOC Membership, Selection and Accountability  . . . . . . . . 11
    4.1.  Initial IAOC Selection . . . . . . . . . . . . . . . . . 13

5.  IASA Funding . . . . . . . . . . . . . . . . . . . . . . . . . 14
    5.1.  Cost Center Accounting . . . . . . . . . . . . . . . . . 14
    5.2.  IETF Meeting Revenues  . . . . . . . . . . . . . . . . . 14
    5.3.  Designated Donations, Monetary and In-Kind . . . . . . . 14
    5.4.  Other ISOC Support . . . . . . . . . . . . . . . . . . . 15
    5.5.  IASA Expenses  . . . . . . . . . . . . . . . . . . . . . 15
    5.6.  Operating Reserve  . . . . . . . . . . . . . . . . . . . 15
6.  IASA Budget Process  . . . . . . . . . . . . . . . . . . . . . 16
7.  ISOC Responsibilities for IASA . . . . . . . . . . . . . . . . 16
8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
    11.1. Normative References . . . . . . . . . . . . . . . . . . 18
    11.2. Informative References . . . . . . . . . . . . . . . . . 19

1. Introduction 🧚

This doc is the blueprint for IASA 💅, the IETF Administrative Support Activity, which lives inside ISOC. It defines the roles of the IAOC, the IAD, and ISOC for the fiscal and admin support of the IETF standards process 💖. It also sets the membership and selection rules for the IAOC 🎀.

The IETF does its technical work as an ongoing, open, consensus-based process 🫶. This doc sets up admin support that's meant to actually respond to what the technical community needs, and it shows how that support sits under ISOC's umbrella ☂️. It does not change the ISOC-IETF working relationship when it comes to standards development or passing along technical advice tied to ISOC's policy and educational goals 📚.

IASA gives the admin structure needed to support the IETF standards process and the IETF's technical activities 🔥. When this was written, that covered IETF working groups, the IESG, the IAB, and the IRTF 💜. If the standards process ever adds other technical activities down the line, the IAOC is in charge of making plans to support them 🌸. That support can include, where it makes sense, doing or contracting the work described in [RFC3716] 🍓. That covers IETF document and data management, IETF meetings, and any operational agreements or contracts with the RFC Editor and the Internet Assigned Numbers Authority (IANA) ✨. IASA is also ultimately responsible for the money side of IETF admin support 💸, like collecting IETF meeting fees, paying invoices, managing budgets and financial accounts, and so forth.

IASA is responsible for making sure the IETF's admin needs are met, and met well 👑. The IETF doesn't expect IASA to do most of this work directly. Instead, it expects IASA to contract the work out to others and manage those contracts for efficiency, transparency, and cost effectiveness 🧾.

IASA is separate from IETF technical functions like the RFC Editor, IANA, and the standards process itself 🚫. IASA has no influence on IETF technical decisions or on the technical content of IETF work 🙅. Still, people in IASA can totally take part as individuals in IETF technical activities, so no worries 💖.

2. Definitions and Principles 📖

This section is the vocab and principles check 🍬 for the rest of the doc.

2.1. Alphabet Soup 🍬

Most of the terms, abbreviations, and acronyms in this doc are reasonably well known, but first-time readers can get lost in this alphabet soup 🥣. So this section gives a quick summary.

  • IAB: Internet Architecture Board (see [RFC2026], [RFC2850]).
  • IAD: IETF Administrative Director, defined by this document.
  • IAOC: IETF Administrative Oversight Committee, defined by this document.
  • IASA: IETF Administrative Support Activity, defined by this document.
  • IESG: Internet Engineering Steering Group (see [RFC2026], [RFC3710]).
  • IETF: Internet Engineering Task Force (see [RFC3233]).
  • ISOC: Internet Society (see [RFC2031] and [ISOC]).

2.2. Principles of the IASA, IETF, and ISOC Relationship 🧩

This section describes the principles behind the mechanisms in this doc 🧠.

  1. The IETF wants a structure (the IASA) so its admin functions get managed properly, with good admin, fiscal, and management principles 📊. The IASA includes the IAD and the IAOC, and it shall be housed within ISOC 🏡.
  2. The IAD and IAOC shall not have any authority over IETF standards development activities 🙅. This doc doesn't change ISOC's other roles related to the IETF standards process 💜.
  3. The IAD and IAOC, working with the ISOC President/CEO and staff, shall develop an annual budget for the IASA 📅. The budget must clearly identify all expected direct and indirect expenditures related to the IASA 🔍. ISOC, through its normal procedures, shall evaluate and approve the IASA budget as part of ISOC's own budget process, and it commits to making sure funds support the approved budget 💰.
  4. Responsibility for evaluating, reviewing, and negotiating contracts and other IETF admin and support agreements, plus any other spending of IASA funds, shall rest with the IAD 🤝. The IAD operates under policies and procedures set by the IAOC, and they have to be consistent with ISOC's operating policies 📜.
  5. Once funds or in-kind donations have been credited to the IASA accounts, they shall be irrevocably allocated to supporting the IETF 🔒.
  6. There shall be a detailed public accounting that separately identifies all funds available to the IETF and the IASA, and all expenditures relating to them, including any donations (money or in-kind) that ISOC receives for IETF-related activities 🧾. In-kind donations shall only be accepted at the direction of the IAD and IAOC 🎁.
  7. Between the IETF, IASA, and ISOC, the IETF (through the IASA) shall have a perpetual right to use, display, distribute, reproduce, modify, and create derivatives of all software and data created to support IETF activities 💻.
  8. The IASA, working with ISOC, shall use reasonable efforts to make sure there are enough reserves to keep the IETF running if something unexpected happens, like an income shortfall 🛟.

The rest of this doc details the principles above 📝.

2.3. Community Consensus and Grant of Authority 🫶

The IETF is a consensus-based group, so acting on behalf of the community requires a high degree of consensus and the community's continued consent 🌟. After a careful process of deliberation, a broad-based community consensus formed to house the IETF Administrative Support Activity (IASA) within the Internet Society 🏡. This document reflects that consensus 💖.

2.4. Termination and Change 🔄

Any change to this agreement shall require a similar level of community consensus and deliberation, and shall be reflected by a later Best Current Practice (BCP) document 📄.

2.5. Effective Date for Commencement of IASA 🎟️

The procedures in this document shall become operational once this document has been approved through the process in BCP 9 [RFC2026] ✅. That includes its acceptance as an IETF process BCP by the ISOC Board of Trustees, and it also needs the ISOC Board of Trustees to confirm that it accepts ISOC's responsibilities under the terms described here 🥳.

3. Structure of the IASA ✨

okay so bestie, the whole point of the IASA setup is accountability and transparency for everything the IETF does with admin and money 🫶 the IETF Administrative Oversight Committee (IAOC) is the one steering the IASA 👑 it's made of volunteers, all picked directly or indirectly by the IETF community, plus some ex officio members from ISOC and IETF leadership. the IAOC MUST be accountable to the IETF community for how effective, efficient, and transparent the IASA is. no skipping this, it's literally the whole vibe 💅

at first the IASA is just one full-time ISOC employee, the IETF Administrative Director (IAD) 🌸 they're allowed to act for the IASA, but only when the IAOC tells them to. the IAD will probably lean on financial, legal, and admin help from ISOC support staff or consultants 🧚 the costs for that help get split based on actual expenses or some other model that the IAOC and ISOC agree on together.

even tho the IAD works for ISOC, they answer to the IAOC 🎀 a committee inside the IAOC handles hiring and firing the IAD, reviewing how they're doing, and setting their pay. the people on that committee are appointed by the IAOC and it MUST include at minimum the ISOC President, the IETF Chair, and one of the Nomcom-appointed IAOC members. the commitee lineup is non-negotiable, iykyk 😭

the IAOC decides which IETF admin functions happen and how or where they get done (inside the IASA or by outside orgs), aiming for the best balance of performance and cost for each one 🦋 the IAOC SHOULD write down every one of those decisions and the reasons behind them so the community can review them. each function should get a regular review, and the starting assumption is that, unless there's a good reason, the function is either unnecessary or, if it IS needed, overstaffed 💀 it is NOT a case of "we've always done it this way so it stays." after the review, each function gets adjusted as needed. main character energy for accountability 🔥

the IAD is responsible for negotiating and keeping up contracts (or equivalent arrangements) with outside orgs, and for coordinating whatever is needed so the IETF admin support is covered properly 💖 every function, whether it's contracted out or done in-house in the IASA, MUST be clearly specified and documented, with well-defined deliverables, service level agreements, and transparent accounting for what it costs 🍓

the IASA handles all the IPR the IETF owns, including trademarks and copyrights (not limited to those) 🌈 it also manages ownership, registration, and admin of the relevant domain names. and it MUST take any and all required actions for the IETF to get, protect, and manage the rights it needs to do its work. this part is lowkey a lot but it's important ✨

if the IASA can't follow the procedures in this document for legal, accounting, or practical reasons, the IAOC MUST tell the community about it, along with the variant procedure it plans to use instead 🫶 if the problem sticks around long-term, the IAOC MUST ask the IETF to update this document so it matches the new procedure. no sneaking around the rules, periodt 💅

3.1. IAD Responsibilities 🎀

the IAD is responsible for working with the IAOC and others to figure out what the IETF's admin needs are, and then running the IASA to meet them 💖 that covers deciding how the IASA effort is structured, setting an operating budget, negotiating contracts with service providers, managing those relationships, and setting up ways to track how the providers perform. the IAD can also manage other contractors or ISOC employees (like support staff) when they're doing IASA work 🧚

the IAD MUST run the IASA in an open and transparent way and put out regular monthly, quarterly, and annual financial and operational updates for the IAOC and community to review 📊✨

the IAD is in charge of the IETF finances, separate financial accounts for the IASA, and the IASA budget 💰 the IAD (with IAOC approval where it applies) SHOULD have signing authority that lets them do IASA work effectively, efficiently, and independently, while still respecting ISOC's financial and approval controls 🦋 if there's any problem with how much financial approval the IAD gets, the IAOC and ISOC SHALL work out a policy they both agree on, and they SHALL do it within a reasonable time frame. no drama, just solutions 🌸

the IAD negotiates service contracts, getting input from other bodies where it makes sense (like legal advice) and getting review from the IAOC where it makes sense 🫶 the IAOC SHOULD set guidelines for how much review each contract needs, based on type, size, cost, or duration. ISOC signs the contracts for the IASA after doing whatever review it needs to make sure they meet ISOC's legal and financial guidelines 💅

now the data part, which is kinda serious 👀 the IAD MUST make sure that contracts ISOC signs for the IASA and/or the IETF (called an "IASA Contract") that cover creating, developing, changing, or storing any data (including, without limitation, data about IETF membership, documents, archives, mailing lists, correspondence, financial records, personnel records and the like) ("Data") give ISOC the perpetual, irrevocable right, on behalf of the IASA and IETF, to use, display, distribute, reproduce, modify, and make derivatives of that Data. ISOC MUST let the IASA and its designee(s) have sole control and custodianship of that Data, and ISOC MUST NOT use or access that Data for any ISOC function other than IETF work without the IAD's written consent 🔒 the vibe is "it's ours, not theirs" 💜

the IAD MUST make sure personal data collected for the IASA's legitimate purposes is protected properly. at the very least, it MUST be protected to a level that matches relevant legislation and applicable privacy policies 🙈

if an IASA Contract covers creating, developing, or changing any software (including, without limitation, search tools, indexing tools, and the like) ("Developed Software"), then the IAD SHALL, whenever it's reasonable and practical, make sure that contract either (a) gives ownership of that Developed Software to ISOC, or (b) gives ISOC a perpetual, irrevocable right, on behalf of the IASA and IETF, to use, display, distribute, reproduce, modify, and make derivatives of that Software (including, without limitation, under an open source style license) ✨ it's preferred that Developed Software is delivered and licensed for IASA and IETF use in source code form, with no ongoing payments 🍓 ISOC MUST let the IASA and its designee(s) have sole control and custodianship of that Developed Software. the above rights are NOT required for off-the-shelf or other commercially-available software that wasn't developed at ISOC's expense 🧚

if an IASA Contract is about licensing third-party software, the IAD MUST make sure that license expressly allows the software to be used for and on behalf of the IASA and/or the IETF (as applicable), and that the license is transferable under the provisions of Section 7 (Removability) 🎀

that said, the IAD CAN agree to different terms if it's in the best interest of the IETF and the IAOC approves 🌈

the IAD and IAOC are responsible for all the business decisions for the IASA. specifically, the ISOC Board of Trustees MUST NOT have direct influence over who gets picked as IASA contractors or IETF meeting sponsors 🚫 this rule exists to keep fund-raising separate from actually running the standards process, and it's a big deal 💅

the IAD prepares an annual budget, and the IAOC reviews and approves it 📊 the IAD presents that budget to the ISOC Board of Trustees as part of ISOC's annual financial planning. the IAOC is responsible for making sure the budget fits the IETF community's admin needs, but the IAOC does NOT carry fiduciary responsibility for ISOC 💖 so the ISOC Board of Trustees needs to review and understand the budget and planned activity in enough detail to do its own fiduciary job properly. the IAD runs that review and approval process 🫶 the IAD also makes sure the IASA publishes its complete approved budget to the IETF community every year 🌸

3.2. IAOC Responsibilities 👑

the IAOC's job is to give the IAD proper direction, review the IAD's regular reports, and oversee IASA functions so the IETF community's admin needs are actually being met 💅 the IAOC is NOT supposed to be doing the day-to-day admin work of the IASA. its role is direction, oversight, and approval 🦋

so, the IAOC's responsibilities are:

  • to select the IAD and give high-level review and direction for their work. this task SHOULD be handled by a sub-committee, as described above 🎀
  • to review the IAD's plans and contracts to make sure they'll meet the IETF's admin needs 📋
  • to track whether IASA functions are meeting the IETF community's admin needs, and to work with the IAD on a corrective action plan if they aren't 🔥
  • to review the IAD's budget proposals to make sure they'll meet the IETF's needs, and to review the IAD's regular financial reports 💰
  • to make sure the IASA is run in a transparent and accountable way. even though the day-to-day work goes to the IAD and others, the IAOC is responsible for making sure IASA finances and operational status are tracked properly, and that monthly, quarterly, and annual financial and operational reports get published to the IETF community ✨
  • to designate, in consultation with the IAB and the IESG, the person or people who do the tasks that other IETF process documents say the IETF Executive Director does 🧚

the IAOC's role is to direct and review, NOT to do the work of the IAD and IASA 💜 the IAOC holds periodic teleconferences and face-to-face meetings as needed to get its duties done efficiently and effectively 📞

if there's no IAD, or the IAD is unavailable, the IAOC MAY temporarily hand the IAD's duties to individual IAOC members 🌸

3.3. Relationship of the IAOC to Existing IETF Leadership 🫶

the IAOC is directly accountable to the IETF community for how the IASA performs 💖 but the IAOC's work also means treating the IESG and IAB as its major internal customers for admin support services. the IAOC and the IAD SHOULD NOT count their work as successful unless the IESG and IAB are also happy with the admin support the IETF is getting 🦋 periodt, the IESG and IAB have to be satisfied too 💅

3.4. IAOC Decision Making ✨

Okay so the IAOC tries really hard to reach consensus on everything 🫶 That's the vibe. If they can't get a consensus, they MAY decide by voting instead.

The IAOC gets to sort out the nitty-gritty of its own decision-making rules 💅 including the quorum rules, the conflict of interest rules, and how ties get broken. These rules SHALL be made public, no hiding allowed 👀

Every IAOC decision SHALL be written down in the IAOC minutes, and those minutes SHALL be published in a timely fashion 📝

3.5. Review and Appeal of IAD and IAOC Decision ⚖️

The IAOC is directly accountable to the IETF community for how the IASA performs 👑 So the IAOC and the IAD are going to make sure guidelines get developed for everyday operational decisions. Where it makes sense, these guidelines SHOULD be developed with public input. In every case, they MUST be made public 🌸

If someone in the IETF community wonders whether a decision or action by the IAD or IAOC was done according to IETF BCPs or IASA operational guidelines, or whether the IASA has actually created and kept up appropriate guidelines, they MAY ask the IAOC for a formal review 🔍

The request for review SHOULD be addressed to the IAOC chair and SHOULD include a description of the decision or action being reviewed, an explanation of how the requestor thinks it violates the BCPs or operational guidelines, and a suggestion for how things could be fixed 🛠️ Every request for review SHALL be posted publicly, and the IAOC is expected to respond within a reasonable period, typically within 90 days. It's up to the IAOC to figure out what kind of review and response is needed, based on the request. Based on the results, the IAOC MAY choose to overturn its own decision, change its operational guidelines to prevent more misunderstandings, take other appropriate action, or just publish the review result and take no further action 🦋

If a community member isn't happy with the IAOC's response, they MAY escalate by appealing the decision or action to the IAB, using the appeals procedures outlined in RFC 2026 [RFC2026]. If they're still not satisfied with the IAB's response, they can escalate the issue to the ISOC Board of Trustees, as described in RFC 2026 🧚

The reviewing body (the IAB or ISOC Board of Trustees) SHALL review the decision of the IAD or IAOC to determine whether it was made in accordance with existing BCPs and operational guidelines. As a result, the reviewing body MAY recommend to the community that the BCPs governing IAOC actions SHOULD be changed. The reviewing body MAY also advise the IAOC to modify existing operational guidelines to avoid similar issues in the future, and/or it MAY advise the IAOC to re-consider their decision or action. It MAY also recommend that no action be taken, based on the review 💜

In exceptional cases, when no other recourse seems reasonable, the reviewing body MAY overturn or reverse a non-binding decision or action of the IAOC. This SHOULD be done only after careful consideration and consultation with the IAOC regarding the ramifications of this action 😤 In no circumstances MAY the IAB or ISOC Board of Trustees overturn a decision of the IAOC that involves a binding contract, or overturn a personnel-related action (such as hiring, firing, promotion, demotion, performance reviews, salary adjustments, etc.). That one is a hard no 🚫

4. IAOC Membership, Selection and Accountability 🎀

The IAOC SHALL consist of eight voting members, who SHALL be selected as follows:

  • Two members appointed by the IETF Nominations Committee (NomCom);
  • One member appointed by the IESG;
  • One member appointed by the IAB;
  • One member appointed by the ISOC Board of Trustees;
  • The IETF Chair (ex officio);
  • The IAB Chair (ex officio);
  • The ISOC President/CEO (ex officio).

The IETF Administrative Director also serves, ex officio, as a non-voting member of the IAOC 🌈

The IAOC MAY also choose to invite liaisons from other groups, but it is not required to do so. The IAOC decides whether to have a liaison to any particular group. Any such liaisons are non-voting. Responsibility for selecting the individual filling a particular liaison role lies with the body from which the IAOC has requested the liaison 🫧

Subject to paragraph 2 of Section 4.1, appointed members of the IAOC serve two-year terms. IAOC terms normally end at the end of the first IETF meeting of a year 📅

The members of the IAOC SHALL select one of its appointed voting members to serve as the chair of the IAOC. The term of the IAOC chair is one year from the time of selection or the remaining time of their tenure on the IAOC, whichever is less. An individual MAY serve any number of terms as chair, if selected by the IAOC 👑

The Chair serves at the pleasure of the IAOC and MAY be removed from that position at any time by a vote of 2/3 of the voting IAOC members, not counting the IAOC chair. Yikes, no pressure 😬

The chair of the IAOC SHALL have the authority to manage the activities and meetings of the IAOC 🗓️

The two NomCom-appointed IAOC members are chosen using the procedures described in RFC 3777 [RFC3777]. For the initial IAOC selection, the IESG will provide the list of desired qualifications for these positions. In later years, the IAOC will provide this qualification list. The IESG will serve as the confirming body for IAOC appointments by the NomCom 🍓

While there are no hard rules about how the IAB and the IESG should select IAOC members, such appointees need not be current IAB or IESG members (and probably SHOULD NOT be, if only to avoid overloading the existing leadership). The IAB and IESG SHOULD choose people with some knowledge of contracts and financial procedures, who are familiar with the administrative support needs of the IAB, the IESG, or the IETF standards process. The IAB and IESG SHOULD follow a fairly open process for these selections, perhaps with an open call for nominations or a period of public comment on the candidates. The procedure for IAB selection of ISOC Board of Trustees [RFC3677] might be a good model for how this could work. After the IETF gains some experience with IAOC selection, these selection mechanisms SHOULD be documented more formally 📚

Although the IAB, the IESG, and the ISOC Board of Trustees choose some members of the IAOC, those members do not directly represent the bodies that chose them. All members of the IAOC are accountable directly to the IETF community. To get direct feedback from the community, the IAOC holds an open meeting at least once per year at an IETF meeting. This MAY take the form of an open IAOC plenary or a working meeting held during an IETF meeting slot. The form and contents of this meeting are left to the discretion of the IAOC Chair. The IAOC SHOULD also consider open mailing lists or other means to establish open communication with the community 🎤

IAOC members are subject to recall in the event that an IAOC member abrogates his or her duties or acts against the best interests of the IETF community. Any appointed IAOC member, including any appointed by the IAB, IESG, or ISOC Board of Trustees, MAY be recalled using the recall procedure defined in RFC 3777 [RFC3777]. IAOC members are not, however, subject to recall by the bodies that appointed them 🙅

If a vacancy occurs among the appointed members, it is filled by the appointing body for that position according to its procedures 🔄

The IAOC members SHALL NOT receive any compensation from the IASA, ISOC, or IETF for their services as members of the IAOC 🫶

The IAOC SHALL set and publish rules covering reimbursement of expenses, and such reimbursement SHALL generally be for exceptional cases only 🧾

4.1. Initial IAOC Selection 🌱

The initial IAOC selection will start after this document is approved as a BCP by the IESG and accepted by the ISOC Board of Trustees. The IESG, IAB, and ISOC Board of Trustees SHOULD make their selections within 45 days of BCP approval, and the NomCom SHOULD make its selections as quickly as possible while complying with the documented NomCom procedures. The IAOC will become active as soon as a majority (three or more) of the appointed members have been selected ✨

Initially, the IESG and the ISOC Board of Trustees will make one-year appointments, the IAB will make a two-year appointment, and the NomCom will make one one-year appointment and one two-year appointment. This will establish a pattern in which approximately half of the IAOC is selected each year 🌗

5. IASA Funding 💰

The IASA manages money from three sources:

  1. IETF meeting revenues;
  2. Designated donations to ISOC (both monetary and in-kind);
  3. Other ISOC support.

Note that the goal is to achieve and maintain a viable IETF support function based on available funding sources. The IETF community expects the IAOC and ISOC to work together to attain that goal 🤝

5.1. Cost Center Accounting 🧮

Funds managed by the IASA SHALL be accounted for in a separate set of general ledger accounts within the IASA Cost Center. In the rest of this document, these general ledger accounts are called "IASA accounts". A periodic summary of the IASA accounts SHALL be reported in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of the IASA 📊

The IAOC and ISOC SHALL agree upon and publish procedures for reporting and auditing of these accounts 🔎

Note that ISOC, in consultation with the IAOC, can decide to structure the IASA accounting differently in the future, within the constraints outlined in Section 7 💅

5.2. IETF Meeting Revenues 🎟️

Meeting revenues are an important source of funds for IETF functions. The IAD, in consultation with the IAOC, sets the meeting fees as part of the budgeting process. All meeting revenues SHALL be credited to the appropriate IASA accounts 🍰

5.3. Designated Donations, Monetary and In-Kind 🎁

Donations are an essential component of funding. The IASA undertakes no direct fund-raising activities. This establishes a practice of separating IETF administrative and standards activities from fund-raising activities, and it helps ensure that no undue influence MAY be ascribed to those from whom funds are raised 🛡️

ISOC SHALL create and maintain appropriate structures and programs to coordinate donations intended to support the work of the IETF, and these SHALL include mechanisms for both in-kind and direct contributions to the work supported by IASA. Since ISOC will be the sole entity through whom donations MAY be made to the work of the IETF, ISOC SHALL ensure that those programs are not unduly restrictive. ISOC SHALL maintain programs that allow for designated donations to the IETF 💖

In-kind resources are owned by ISOC on behalf of the IETF and SHALL be reported and accounted for in a manner that identifies them as such. Designated monetary donations SHALL be credited to the appropriate IASA accounts 🌷

5.4. Other ISOC Support 🫧

Other ISOC support SHALL be based on the budget process as specified in Section 6, which includes deciding when ISOC monetary support is to be credited to the IASA accounts.

All ISOC support, no matter how it is delivered, SHALL be reported in the IASA financial reports 🌟

5.5. IASA Expenses 💖

The IASA exists to support the IETF, bestie 🫶 That's its whole thing. Any money designated for the IASA shall only be spent on IETF activities, and never on anything else 💅

5.6. Operating Reserve 💰

Okay, so the vibe here is saving for a rainy day ☔ As a starting guideline, and when things are running normally, the IASA should keep an operating reserve that covers 6 months of non-meeting operational expenses, plus twice the recent average for meeting contract guarantees. 🧚

The IASA and ISOC are going to team up to set detailed reserve targets for normal operating expenses and meeting expenses. This has to be done with prudent planning and as part of the budget process 🎀

The IASA expects ISOC to use reasonable efforts to build and provide that operational reserve, using whatever mechanisms ISOC thinks are appropriate 🌸

And if the IASA accounts ever end up with a surplus, ISOC may count that toward the reserve ✨

6. IASA Budget Process 📅

The IASA sets the budget for the IETF's administrative needs, but ngl, this process is highly coordinated with ISOC's budget process 🫶 The IASA and ISOC decide the specific timeline together each year. Here's an example of what a general annual budgeting timeline could look like:

  • July 1: The IAD presents a budget proposal for the following fiscal year, with 3-year projections, to the IAOC. The IAD prepares it in consultation with ISOC staff 📊
  • August 1: The IAOC approves the budget proposal for IETF purposes, after any appropriate revisions. The ISOC President is part of the IAOC, so the IAOC should get a preliminary idea of how the budget fits with ISOC's own budget expectations 👀 After that, the proposal goes to the ISOC Board of Trustees for review, in line with its fiduciary duty.
  • September 1: The ISOC Board of Trustees approves the budget proposal provisionally. For the next 2 months, the budget can be revised so it fits into ISOC's overall budgeting process 🔄
  • November 1: The final budget goes to the ISOC Board for approval 🎉
These dates are only examples and can change. They'll most likely get modified each year based on the dates of the second and third IETF meetings of that year. They also need to stay in sync with the ISOC budgeting process, so no surprises 🙈

The IAD shall provide monthly accountings of expenses and shall update expenditure forecasts every quarter 📈 If that leads to an adjustment of the IASA budget, the revised budget will need approval from the IAOC, the ISOC President/CEO and, if necessary, the ISOC Board of Trustees 👑

7. ISOC Responsibilities for IASA 🏰

Within ISOC, support for the IASA shall meet the following goals. Let's go through them, babe 💅

  • Transparency: The IETF community shall have complete visibility into the financial and legal structure of the ISOC activities that are related to, but not part of, the IASA standards support activity. That means a detailed budget for the entire related ISOC activity, quarterly financial reports, and audited annual financial reports shall all be available to the IETF community. Key contract material and MOUs shall also be publicly available too, subject to any reasonable confidentiality obligations approved by the IAOC 👀🔍
  • Unification: As part of this arrangement, ISOC's sponsorship of the RFC Editor, IAB and IESG shall be managed as part of the IASA under the IAOC 🧩
  • Independence: The IASA shall be distinct from other ISOC activities. ISOC shall support the IASA through the mechanisms specified in this document and its successors 🦋
  • Support: ISOC shall work with the IAD and IAOC to ensure appropriate financial support for the IASA, following the mechanisms described in this document and its successors 💜
  • Removability: There's no current plan to move the legal and financial home of the IASA to another corporation. Still, the IASA shall be structured to enable a clean transition, in case the IETF community decides a transition is needed and writes its consensus down in a formal document (currently called a BCP) 🌈 If that happens, the IAOC shall give ISOC a minimum of six months' notice before the transition formally occurs. During that time, the IETF and ISOC shall work together to make it smooth, without any significant service outages or missed IETF meetings ✨ All contracts ISOC signs on behalf of the IASA shall either include a clause that lets ISOC terminate with six months notice, or be transferable to another corporation if the IASA moves away from ISOC. To the extent allowed by law, any balance in the IASA accounts, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also move to the new entity. Other terms shall be negotiated between the IETF and ISOC 🫶

Within the constraints above, ISOC decides all the other details of how to structure this activity inside ISOC. For instance, it could be a cost center, a division, or an affiliate 🎀

8. Security Considerations 🔐

Okay, this section is serious, so listen up 🙈 This document describes the structure of the IETF's administrative support activity. It introduces no security considerations for the Internet. ✨

9. IANA Considerations 🧚

This document has no IANA considerations in the traditional sense 🌸 But some of the information in here may affect how the IETF standards process interfaces with the IANA, so the IANA may be interested in what it says 👀

10. Acknowledgements 🫶

The editors want to thank everyone who gave feedback on this document or any of its predecessors, all the way back to the original "Scenario O" e-mail message 💖 In particular, they want to thank the following people:

Bernard Aboba, Jari Arkko, Fred Baker, Scott Bradner, Scott Brim, Brian Carpenter, Jorge Contreras, Dave Crocker, Elwyn Davies, Spencer Dawkins, Avri Doria, Tony Hain, Joel Halpern, Ted Hardie, Sam Hartman, Russel Housley, Geoff Huston, Jeff Hutzelman, John Klensin, Valdis Kletnieks, Eliot Lear, Henrik Levkowetz, Kurt Erik Lindqvist, John Loughney. Carl Malamud, Allison Mankin, Tom Petch, Eric Rescorla, Pete Resnick, Glenn Ricart, Jonne Soininen, Lynn St. Amour, and Michael StJohns. 🌟

Special thanks are due to Leslie Daigle and Margaret Wasserman, who wrote the original "Scenario O" message and edited the earliest versions of this document 👑

Special thanks are also due to Henrik Levkowetz for kindly volunteering to maintain the issue tracking system associated with this document 🎀

Last, special thanks are due to Harald Alvestrand, for leading the search for consensus on the IETF mailing list 🦋

No doubt the above list is incomplete. The editors apologize to anyone they left out 🥺

This document was written using the xml2rfc tool described in RFC 2629 [RFC2629]. 💅

11. References 📚

11.1. Normative References

[RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, October 1996.

[RFC3716]  IAB Advisory Committee, "The IETF in the Large:
           Administration and Execution", RFC 3716, March 2004.

[RFC3777]  Galvin, J., "IAB and IESG Selection, Confirmation, and
           Recall Process: Operation of the Nominating and Recall
           Committees", BCP 10, RFC 3777, June 2004.

11.2. Informative References

[ISOC]     Internet Society, "Internet Society By-Laws", February
           2001,
           <http://www.isoc.org/isoc/general/trustees/bylaws.shtml>.

[RFC2031]  Huizer, E., "IETF-ISOC relationship", RFC 2031, October
           1996.

[RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
           June 1999.

[RFC2850]  Internet Architecture Board and B. Carpenter, "Charter of
           the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
           May 2000.

[RFC3233]  Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58,
           RFC 3233, February 2002.

[RFC3677]  Daigle, L. and Internet Architecture Board, "IETF ISOC
           Board of Trustee Appointment Procedures", BCP 77, RFC
           3677, December 2003.

[RFC3710]  Alvestrand, H., "An IESG charter", RFC 3710, February
           2004.

Authors' Addresses 🖋️

Rob Austein (editor)
Internet Systems Consortium
950 Charter Street
Redwood City, CA  94063
USA

EMail: sra@isc.org


Bert Wijnen (editor)
Lucent Technologies
Schagen 33
3461 GL Linschoten
NL

Phone: +31-348-407-775
EMail: bwijnen@lucent.com

Okay, the legal bits 🙈 Keep these in mind, babe.

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💜

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. ✨🎀

📦 where this page comes from