RFC 4089
IAB and IESG Recommendation for IETF Administrative Restructuring
RFC 4089: IAB and IESG Recommendation for IETF Administrative Restructuring ✨
Okay bestie, this one is the IAB and IESG's official recommendation for restructuring the IETF's admin side. 🎀 It's a Informational doc from May 2005, so it gives information to the Internet community and doesn't set any Internet standard. 🫶
- Series: Network Working Group
- Author: S. Hollenbeck, Ed.
- Written on behalf of: IAB and IESG
- Category: Informational
- Date: May 2005
- Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 🙈
Status of This Memo 💅
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 🌸
Copyright (C) The Internet Society (2005).
Abstract 🦋
Okay so the abstract says this doc is a joint recommendation from the Internet Architecture Board and the Internet Engineering Steering Group for restructuring the IETF's administration. The IETF Chair declared that the IETF had consensus to follow it on November 11, 2004. After that, people kept refining the proposed structures, and the recommendation is being published so it's on the record. 📜✨
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Process That Produced This Recommendation . . . . . . . . 2
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Arguments That Had Particular Weight in the Discussions . . . 4
4.1. Focusing on Scenarios C and O . . . . . . . . . . . . . 4
4.2. Why We Chose Scenario O . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix: Scenario C . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix: Scenario O . . . . . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . . . . . 541. Introduction 🧚
Okay so the IETF needs admin support functions, and the debate from 2003 and 2004 made everyone feel like the way those functions get provided has to change. 💜
This doc is the IESG and IAB's recommendation for what the next step in that change should be, plus the background and reasoning behind it. 🍓
2. The Process That Produced This Recommendation 🫶
So during several months in 2004, the IAB and the IESG worked together to look at different options for restructuring the IETF's admin functions. The goal was a recommendation for the IETF community to consider and approve. The reasoning behind all this is in RFC 3716 [1]. A consultant also wrote a report called "IETF Administrative Support Functions" [2], which has tons of background work and detailed proposals. 📚
The consultant's report had several possible scenarios for admin restructuring, named scenario A, B, C, and D. As people talked it out, it got clear that some scenarios looked more promising than others, but there wasn't a concrete enough proposal to turn opinions into consensus. So members of the IESG and IAB took on the job of writing more complete descriptions of two of them. ✨ They were:
- Scenario C (section 4.4 of the report) describes when "administrative support functions for the IETF are legally housed in a focused, incorporated institution" with close ties to the Internet Society (ISOC). Scenario C is included here as the first appendix. 🎀
- Scenario O, a new scenario that includes features derived from scenarios A and B (sections 4.2 and 4.3 of the report). It focuses on formalizing the ISOC/IETF relationship while housing the IETF's admin support functions within ISOC. Scenario O is included here as the second appendix. 🌈
These descriptions weren't meant to shut down discussion of other scenarios. They were meant to focus discussion on what looked like two independent sources of support. 🦋
Both scenarios were presented to the IETF community as mail notes (Scenario C [3], Scenario O [4]) sent to the IETF discussion list. IETF participants were pretty divided, but they seemed to lean toward Scenario O as a "lower risk operation." Some participants said they couldn't give an informed opinion, disagreed with the process, or said the subject was out of their field. About 40 people contributed to the list discussion. 💬
Then the IETF Chair asked for an informal poll of IETF opinion. People who wanted to take part were sent to a web site where they could note their opinions, including whether they wanted to state an opinion at all. The raw poll results [5] were also shared with the community in a mail note to the IETF discussion list. 📊
The poll sparked more discussion on the list, and not everyone agreed with how the poll was run. Still, taken together with the discussion, IESG and IAB members believe there's stronger evidence of community support for change based on Scenario O than on the other scenarios. They also believe Scenario O can be a workable basis for further progress, even if it isn't everyone's first pick. 🔥 Putting all of that together led to the IESG/IAB recommendation below. 👑
3. Recommendation 💅
The collective recommendation of the IAB and IESG was presented to the IETF community on Friday 8 October 2004 in a mail note [6] sent to the IETF mailing list. Here's the note, copied exactly:
"IETF folks,
The IESG and IAB have been considering the input from the IETF
community on the next steps going forward in IETF administrative
restructuring.
It appears clear to us that the community mostly sees scenario O
as the lower-risk scenario, and the one that gives us the greatest
probability of successfully doing what we have to do.
Based on this, the IESG and the IAB make the following
recommendation:
We recommend that the IETF pursue scenario O, with the
understanding that further work is needed to define the
roles and responsibilities of the IETF, the IAOC and the
ISOC BoT under this scenario.
The "BCP section" of the scenario O note will be pulled out and
published as an internet-draft. We'd like to put this description
to the IETF community for a formal Last Call before the November
IETF meeting, if possible.
Also, as noted in the recommendation above, there are a number of
points where we need to work out in more detail how the system is
going to work - who takes decisions, who accepts those decisions,
and what conflict resolution mechanisms may be necessary, and so
on. The IAB and IESG are drafting a document that will describe
the finer level of detail as to the respective roles and
responsibilities of each of the players. We will publish this as
an internet-draft shortly.
We will continue to work intensely on this!"4. Arguments That Had Particular Weight in the Discussions 🧠
4.1. Focusing on Scenarios C and O 👀
The IETF list was given four scenarios in the consultant report [2], which you should read for the full context. In slogan form, they could be summed up as:
- A: Leave it to ISOC.
- B: Increase IETF control of ISOC, and use ISOC to do it.
- C: Isolate the functions, let ISOC gather money, share control.
- D: Cut the IETF off from ISOC and do it ourselves.
On the list, very few people were comfortable with the idea that "we" (for some version of "we") could "do it ourselves" like Scenario D imagined. 🙅♀️ There was also a lot of worry about the risk tied to Scenario C, especially around financial stability. People feared that the perceived danger of problems would make sponsors hold back funding, which could cause problems even if nothing else did. 😬 Scenario C really spoke to people who worried about a possible conflict of interest between ISOC and the IETF community down the road. "We don't know what ISOC will turn into" was the capsule summary. 🫣
Scenario A worried people because it didn't seem to acknowledge the IETF community's ability to tell whether its needs were being met, or what could be done if they weren't. "Replace existing problematic structures by ISOC" was probably the capsule summary. 💀 Scenario B's list of possible ways to involve the IETF community directly in ISOC's operations wasn't seen as acceptable, or as balanced against the full scope of ISOC's activities. 🙈
So IAB and IESG members developed Scenario O, a solution that puts the admin activity within ISOC but aims to give the IETF oversight and control of that specific activity inside ISOC. Its name comes from blood types: "neither A nor B." 🩸✨
That's how the decision to focus on C and O as "alternatives to be worked out in detail" got made. 🎯
4.2. Why We Chose Scenario O 💖
Capsule summary: either scenario could probably work, but Scenario O could get worked out faster and with less pain. 🏃♀️💨
The ISOC Board of Trustees was seriously worried that Scenario C would make fundraising harder, which would directly affect its ability to support the IETF. 💸
The tax status of the new corporation was debated at length on the list. Legal counsel said a corporation doing the IETF work (Scenario D) would probably be easy to classify as 501(c)(3) (a type of non-profit corporation defined by U.S. Internal Revenue Service (IRS) regulations). A corporation that only did administrative support functions, like Scenario C envisioned, would have more problems. In every case, figuring this out would take months, and it could drag on even longer if we got unlucky. 🥲
The community feedback brought lots of well-formed, well-argued points to the discussion. It also gave a strong signal about where IETF consensus was possible: 🔍
- It seemed possible to get IETF consensus around Scenario O. The people arguing for Scenario C said they "could live with" that alternative. 🫶
- It seemed much harder to get IETF consensus around Scenario C. Many people arguing against it said they were firmly convinced it was the wrong choice for the IETF. 🚫
The IETF is built on the idea that the consensus process, when it works, comes up with reasonable decisions. So the IESG and IAB concluded that the apparent drift of community consensus was a reasonable basis for their recommendations. 🌟👑
5. IANA Considerations 🌐
This document doesn't require any IANA actions. That said, the IETF administrative restructuring process is likely to affect how the relationship between the IETF and the IANA is managed. 🧚♀️
6. Security Considerations 🔒
okay so this section is short but it's giving very serious energy 😭 This document doesn't add any security considerations for how the Internet operates. BUT administrative restructuring can put the future of the IETF at risk, so the risks and how to handle them are covered in the scenarios appended to this document 🫶
7. Acknowledgements 🌸
this doc is a collective effort from the members of the IAB and the IESG, and it's giving teamwork ✨ At the time of writing, the IAB members were Bernard Aboba, Harald Alvestrand, Rob Austein, Leslie Daigle, Patrik Faltstrom, Sally Floyd, Mark Handley, Bob Hinden, Geoff Huston, Jun-ichiro Itojun Hagano, Eric Rescorla, Pete Resnick, and Jonathan Rosenberg 💜
The IESG members at the time of writing were Harald Alvestrand, Steve Bellovin, Bill Fenner, Ted Hardie, Scott Hollenbeck, Russ Housley, David Kessens, Allison Mankin, Thomas Narten, Jon Peterson, Margaret Wasserman, Bert Wijnen, and Alex Zinin 🎀
Restructuring can't work without the community showing up and getting involved, so the IAB and IESG want to shout out everyone in the IETF community who joined the discussion on this topic 📣🦋
Appendix: Scenario C 🧚
this appendix is the Scenario C Internet-Draft exactly as it was posted on 20 September 2004 💅 The table of contents was removed and the text was reflowed to fit IETF publication guidelines, and every line is prefixed with C>> so you can tell it apart from the main doc ✨
C>> B. Wijnen
C>> LucentTechnologies
C>> H. Alvestrand
C>> Cisco Systems
C>> P. Resnick
C>> QUALCOMM Incorporated
C>> September 20, 2004
C>>
C>> AdminRest Scenario C: An IETF Administrative Support Foundation as
C>> an Independent Nonprofit Corporation
C>>
C>> Abstract
C>>
C>> This document defines a proposal for an IETF Administrative
C>> Support Foundation (IASF) as an independent not-for-profit
C>> corporation as a means for providing focused support for IETF
C>> community activities. It proposes the creation of an IASF Board
C>> of Trustees (BoT) that is mainly selected by and accountable to
C>> the IETF community and would provide oversight for the IETF
C>> Administrative Support Foundation. The IASF will also establish
C>> and maintain a strong relationship with the Internet Society
C>> (ISOC) and the current relationships between IETF and ISOC will
C>> basically be left unchanged.
C>>
C>> In order to allow the community to properly evaluate this
C>> scenario, some draft Articles of Incorporation and draft Bylaws
C>> for the IASF are included. Some draft BCP wording for the IASF,
C>> IETF and ISOC relationships is also included.
C>>
C>> 1. Overview of Scenario C
C>>
C>> This document follows from two previous documents. [RFC3716]
C>> defined the overall parameters and criteria for an administrative
C>> restructuring. [I-D.malamud-consultant-report] provided an
C>> analysis of the implications of several of the suggested
C>> strategies. This document picks one strategy and develops it
C>> further.
C>>
C>> In order to provide the most focused and effective administrative
C>> support to the IETF community, this updated scenario C proposes a
C>> new and well-defined legal entity to support the IETF
C>> administrative functions. The name of that new entity is "The
C>> IETF Administrative Support Foundation" (IASF).
C>>
C>> First, it is important to understand that the IETF has been
C>> organized as an Activity of the Internet Society (ISOC) and as
C>> such represents the "Standards and Protocols" pillar of ISOC.
C>> Under this proposal, the IETF would continue to be an integral
C>> part of the Standards and Protocols pillar of ISOC. ISOC
C>> currently provides these important functions to the IETF:
C>>
C>> 1. Standards Process Functions. ISOC plays a fundamental role in
C>> the IETF Standards Process, including appointment of the
C>> Nominating Committee (Nomcom) chair, confirmation of IAB
C>> members, confirmation of documents that describe the
C>> standards processes, and acting as the last resort in the
C>> appeals process. These Standards Process Functions are
C>> defined in [RFC2026], [RFC2028], [RFC2031], and [RFC3677].
C>>
C>> 2. IETF Fund Raising Functions. ISOC provides the fund raising
C>> function as one source for financial support the IETF.
C>>
C>> 3. Administration Functions. ISOC provides administrative and
C>> financial functions, managing the contract with the RFC
C>> Editor, providing insurance for selected IETF participants,
C>> and administering a discretionary fund for use by the IAB and
C>> the IETF Chairs.
C>>
C>> The administrative restructuring of the IETF proposed in this
C>> document keeps that basic relationship between IETF and ISOC.
C>> Specifically, the recommendation does not propose any changes to
C>> the "Standards Process Functions" or to the "IETF Fund Raising
C>> Functions".
C>>
C>> Under the "Administration Functions", ISOC both funds and
C>> administers some (as stated above) parts of the IETF
C>> Administrative Support Functions. Some of the funds (like for
C>> the RFC-Editor) go directly to the contractor who executes the
C>> administrative function. The streamlining of the administrative
C>> support for the IETF ultimately intends to put the complete
C>> Administrative Support Functions under the newly recommended
C>> IASF. This means that we recommend that ultimately, ISOC funds
C>> for the IETF will be transferred to the IASF, which will then
C>> administer all the contracts and payments according to an
C>> approved yearly budget. The details of that process will be
C>> documented in a Memorandum of Understanding (MoU) between ISOC,
C>> IETF and IASF.
C>>
C>> This updated AdminRest Scenario C aims to provide the following:
C>>
C>> o A continued close relationship between IETF and ISOC.
C>>
C>> o A well defined legal entity within which the IETF can define
C>> the administrative activity in terms of IETF community needs.
C>>
C>> o A Board of Trustees with operational oversight that is
C>> accountable to the IETF community.
C>>
C>> o Continued separation between the IETF standards activity and
C>> any fund-raising for standards work.
C>>
C>> o A close and well defined relationship between IASF and ISOC,
C>> documented in a BCP (or MoU).
C>>
C>> o Appropriate ISOC oversight of its standards activities funds
C>> via a yearly budget approval and open reporting of funds
C>> spent.
C>>
C>> In scenario C, it is intended that the IETF Administrative
C>> Support Foundation will be a tax-exempt not-for-profit
C>> corporation as defined by Articles of Incorporation and a set of
C>> Bylaws. These will describe the scope and purpose of the IASF
C>> and they also define the structure and responsibility of the
C>> Board of Trustees (BoT), a body that is mainly selected by the
C>> IETF and which is responsible for overseeing the IASF. A draft
C>> of the Articles of Incorporation and Bylaws is included in the
C>> next sections of this document.
C>>
C>> Scenario C allows us (IETF) to establish IETF control over our
C>> administrative support functions in terms of determining that
C>> they meet the community's needs, and adjusting them from time to
C>> time using IETF processes. This is to address the pressing
C>> administrative issues outlined in [RFC3716].
C>>
C>> Scenario C also encourages us (the IETF) to regularly evaluate
C>> that we do want to continue the relationships with ISOC and the
C>> contracts with our services providers (contractors). It is based
C>> on the premise that we prefer to actively maintain relationships
C>> with other organizations and service providers instead of being
C>> bound to such relationships based on poorly defined and poorly
C>> documented historical facts. A draft BCP for the relationship
C>> between ISOC, IETF and IASF is included as a separate section in
C>> this document.
C>>
C>> Scenario C does however bring the burden of creating a new legal
C>> entity (IASF) and such an undertaking is also not without risks.
C>> It will need careful planning and execution. Migration from the
C>> current structure to this new structure is probably also somewhat
C>> more costly and time and labour consuming. The sections below
C>> try to show how that would be achieved and outlines what further
C>> steps are needed to provide more detail if this scenario is
C>> chosen.
C>>
C>> 2. Work Plan for the IETF Administrative Support Foundation
C>>
C>> This section gives the work plan for the IETF Administrative
C>> Support Foundation (IASF) for the remainder of 2004 and the year
C>> 2005.
C>>
C>> 2.1 Workplan goals
C>>
C>> The work plan below is intended to satisfy three goals:
C>>
C>> o Satisfy the IETF's need for support functions in 2005
C>>
C>> o Operate with a positive account balance throughout 2005
C>>
C>> o Start building up a fund inside the IASF to serve as a buffer
C>> against budgetary emergencies in later years (such as meetings
C>> with a severe cost overrun, or force-majeure cancellations).
C>>
C>> The fund target is 6 months of operating revenue, and the target
C>> for building up the fund is 3 years. The budgeted set-aside for
C>> the fund should thus be approximately 17% of operating revenue.
C>>
C>> 2.2 Incorporation process
C>>
C>> There are 3 things that need to be in place before that
C>> corporation can be considered viable at all:
C>>
C>> o IETF consensus on the plan
C>>
C>> o ISOC agreement on a reasonable support contract
C>>
C>> o Assurance that the corporation will have tax-exempt status
C>>
C>> Once this document has been discussed in the IETF, and the IESG
C>> and IAB gauges that rough consensus seems reached, the IETF
C>> leadership will take the following actions:
C>>
C>> o Publish a Last Call on this document (to determine plan
C>> consensus).
C>>
C>> o Choose a negotiating team to negotiate the ISOC contract.
C>>
C>> o Choose an executive search team to find the IASF
C>> Administrative Director (IAD).
C>>
C>> o Consult with legal counsel to determine how best to achieve
C>> tax-exempt status; this will affect the bylaws and articles of
C>> incorporation.
C>>
C>> When the Last Call is over, the IESG will consider whether there
C>> is still consensus, and if there is, approve this document for
C>> publication. Once that happens, it will take the following
C>> steps:
C>>
C>> o As soon as negotiations conclude, publish a Last Call on the
C>> ISOC contract.
C>>
C>> o As soon as drafting of legal documents is completed, publish a
C>> Last Call on the Bylaws and Articles of Incorporation, and ask
C>> the Nomcom to start the process of selecting Nomcom-selected
C>> board representatives.
C>>
C>>
C>> These Last Calls are "speak now" Last Calls - if someone wishes
C>> to challenge the IETF consensus to go ahead with these actions,
C>> knowing what the formal documents will look like, this is their
C>> last chance.When these Last Calls wrap up, the IETF chair, the IAB chair and the ISOC President will jointly file the articles of incorporation 📜, and the IESG, IAB and ISOC will fill their board seats 🪑✨
Note: This document does not say when a Request for Information (RFI) for IETF support services such as meeting planning is sent out. Advice is sought on the earliest point where this can be done. 🙈
2.3 Contract establishment
okay so the most important activity for late 2004/early 2005 is to finalize contracts for the support of the IETF 💅 This includes:
- Funding 💰
- Technical infrastructure 🖥️
- Meeting management 🗓️
- Clerk's office 📎
- RFC Editor ✍️
- IANA 🌐
There appears to be consensus in the IETF community that these functions, whether they are offered for free, remunerated or arranged for other consideration, should be under contract 🫶 That's a whole vibe, honestly.
The contract for funding is expected to be with ISOC, and should be finalized before IASF is established 💜
The contract for technical infrastructure is expected to be an RFP, published in November of 2004, with responses being evaluated in December 2004, and services rendered from a mutually agreed date early in 2005 📅
The contract for meeting management will be influenced by the need to have stable agreements for the 2005 meetings at an early date. This indicates that IASF will honor a pre-IASF agreement to have these meeting contracts signed by Foretec (if that can be achieved) 🎀
It is not clear how the contract for the clerk's office is to be managed at the time of this writing 🤷♀️
The contract for the RFC Editor is expected to be with ISI, and is expected to be a continuation of the current contract with ISOC, which runs until the end of 2005 🌸
The contract with IANA will replace or augment the current MoU between the IETF and ICANN. In its simplest form, it would simply be a reconfirmation of the duties of ICANN under the MoU 🦋
2.4 Performance evaluation
The second task of the IASF is to make sure the IETF gets the support it needs 💖 The IASF will work together with the IETF community to make an effort to identify whether or not the IETF's needs are being met, and to coordinate improvements with the contractors. This is an ongoing activity 🔁
2.5 Budgeting for 2006
In June 2005, the IASF will start the yearly budgeting process with ISOC, as specified in the ISOC contract, leading to a work plan and budget for 2006 🧮
2.6 Reporting
The IASF will present monthly updates on its economic status. These will be delivered to ISOC as part of the ISOC contract, and also be made publicly available so that the IETF community can inspect them 👀
3. Details of the IETF Administrative Support Foundation
This section contains details about the proposal to change how the day-to-day IETF administrative support functions are provided. This recommendation is based on the initial description of "Scenario C" in the "Administrative Support Analysis" [I-D.malamud-consultant-report] provided by Carl Malamud. It is further based on discussion in the IESG and IAB and on feedback on Carl's document as received on the IETF mailing list. Further justifications, reasoning and motivations are given in Appendix A. Risk Analysis is done in Appendix C 🧠
This document recommends to create a well defined and legal entity called "The IETF Administrative Support Foundation" (IASF). The name intends to clearly express that this new legal entity has only one single function, namely to provide the administrative support of the IETF Standardization and Protocol Development activities. This entity will ultimately manage and administer all the administrative functions that are needed to support the IETF - the Standardization and Protocol Development activity of ISOC 👑
3.1 Organizational Form and Legal Domicile
The consultant report [I-D.malamud-consultant-report] contains a writeup on various choices in terms of how and where to incorporate. This recommendation has made the choice to incorporate in the US in the state of Virginia. Some detail can be found in Appendix B 🇺🇸
In this scenario, administrative support functions for the IETF are legally housed in a focused, incorporated institution (although the Administrative Director might be physically housed within the Internet Society) 🏢
This scenario defines a number of concrete linkages with the Internet Society, which supplement the current close interconnection of the IETF community with ISOC. The relationship is to be documented in a MoU (initial text is in Section 4) 📝
3.2 Draft Core Principles
3.2.1 Principles of Establishment and Governance
The following principles are to be respected for the establishment and governance of the IETF Administrative Support Foundation (IASF) and are the basis for the Draft Articles of Incorporation as in Section 6.1 and the Draft Bylaws as in Section 6.2:
- The IASF shall be governed by a Board of Trustees (BoT), who shall be responsible for the fiscal, legal, and administrative infrastructure that supports the activities of the IETF.
- The governance of the IETF, the standards process, and all other aspects of how we make our standards are defined in the procedural Best Current Practice (BCP) RFC series, which will be explicitly referenced in the organization documents of the IASF.
- The IASF shall be transparent and responsible to the IETF.
- The BoT shall appoint a Secretary and a Treasurer, who need not be members of the BoT. The IETF Administrative Director (IAD) of the IASF shall provide staff support to the BoT.
- The BoT shall be composed to strike a balance between "outside" and "inside" directors. The IESG and IAB will each select a representative to serve as a voting member of the BoT. Mechanisms such as the Nominating Committee (Nomcom) and the appointment of certain seats by the ISOC fulfill the outside director obligations.
- IAB, IESG and ISOC will have liaisons to the BoT in order to have a good basis for interaction.
The BoT will have strong governance over a limited scope of activities (e.g., the fiscal, legal, and administrative infrastructure that are the charter of the IASF) but will have no authority over the IETF standards process. In this board composition, the ISOC and Nomcom appointments ensure that outside directors with no perceived conflicts of interest are on the board 🫧
All nominating bodies should make strong fiscal, legal, and administrative acumen essential selection criteria for this position 💼
IAB and IESG representatives will serve for one year. For other appointments, a term proposed for the nominated positions is three years with staggered appointments. However, the nominating body might have the power to change their appointee during their term ⏳
All members of the BoT selected by the IETF are subject to the same recall procedures in effect for the IETF leadership such as members of the IAB and IESG 🔄
3.2.2 Principles of Operation of the IETF Administrative Support Foundation
The following are general principles for the operation of the IASF:
- The IASF shall employ an IETF Administrative Director (IAD) of the IASF, who shall be hired by the BoT with the advice and consent of the IESG and IAB.
- All support services shall be contracted in an open and transparent manner.
- The IAD shall submit a proposed annual budget to the BoT at least 90 days before the beginning of the fiscal year. Such budget shall be developed with the advice and consent of the IAB and IESG.
- The IAD shall serve on the BoT as a non-voting, ex-officio member.
- The BoT shall select a professional audit firm and shall commission an audit immediately upon the close of each fiscal year.
- The IASF will conduct financial reporting in a fully transparent fashion. Audits shall be conducted promptly and published. Tax returns shall be published. Detailed financial statements will be published on a regular basis, including timely reports on the financial results of IETF meetings 📊
4. Draft MoU between ISOC, IETF and IETF Administrative Support Foundation
4.1 Form and Scope of the Agreement
This section presents some principles to be incorporated in a draft MoU/Contract between the Internet Society (ISOC) and the IETF Administrative Support Foundation (IASF), detailing the work each is expected to perform, the responsibilities each has, and the means by which these functions are accomplished. This MoU/Contract shall be published as an RFC 📚
The MoU/Contract will specify the responsibilities of the Internet Society, including:
- Reaffirmation of the Standards Process Function that ISOC performs for the IETF.
- Continuation of the Fund Raising Function that ISOC conducts, in which a single, unified campaign is used to solicit corporate, individual, and other organizational donations for funding of the 3 Pillars.
- Disbursement of funds to the IASF according to the agreed-upon budgets and processes as specified in this agreement.
- Verification that IASF spends these funds to support the work of the IETF, within the scope described in the IASF bylaws.
Responsibilities of IASF:
- Determine, in cooperation with the IETF, the support functions that are needed for the IETF, and can be achieved within available funds.
- Enter into contracts for these support functions.
- Supervise these contracts and ensure that they are being performed in the best interest of the IETF, within a reasonable budget and with agreed-upon performance.
4.2 Cooperation mechanism
IASF and ISOC agree that they will perform a budgeting procedure each year, comprising the following steps 🤝
- IASF puts together a budget proposal to ISOC, and presents it in June. This will specify the functions that need to be performed, the cost of each, the expected revenue from IETF meeting participation, and how much is being requested for ISOC to contribute.
- By the end of August, ISOC will give a budget number to IASF that says how much ISOC is willing to contribute to support the functions described in the IASF budget.
- Before November 1, ISOC and IASF will agree on a budget, an ISOC contribution, and a disbursement schedule 🗓️
- If either party sees that there is reason to change the budget, they can start a negotiation to do so at any time 💅. Once both sides agree to a change, the payments get updated to match. 💸
- ISOC may withhold funds if IASF fails to account for its expenditures 🧾, if ISOC determines that IASF has departed significantly from its budgeted expenditures without agreement with ISOC to do so 🙅♀️, or if ISOC determines that IASF is spending funds in violation of its bylaws 🚫.
4.3. Promises Not to Do Things
This section lays out the stuff that would count as interfering in each other's business, or the stuff that is Just Plain Wrong 😤. In legal terms, these are called "covenants" 📜.
ISOC will not place requirements on how IASF does business, except on reporting 📊. For example, it will not try to influence IASF's choice of contractors or choice of meeting sponsors 🙅. This restriction is there to keep fundraising and the actual running of the standards process separated 🧱, which is very important and very iconic of them 👑.
IASF will not ask companies for money 🙅♀️💰. IASF may ask for sponsors for IETF events, because that's tradition 🎀, and it may accept zero-cost provider contracts or in-kind donations 🎁. But ISOC is the organization in charge of fundraising 💼.
Neither ISOC nor IASF will try to influence the technical decisions of the IETF standards process 🙅♀️🛑. Hands off the protocols, bestie 🫶.
4.4. Initial contribution
The Internet Society has already set aside $700,000 in transition funds 🌷. As part of the formation process, this section sketches out a way that a 2005 allocation of funds and an initial contribution for startup could be decided on 🌱. NOTE: This section is a GUESS! 🙈 Its purpose is just to give some sense of where we're at ✨.
If this plan goes ahead, one of the first things to do is put together a detailed 2005 budget 📅. That includes an analysis of cash flow and balance sheets, so we can make sure the organization is properly funded and stays solvent through the whole year 💖. This planning should project out 3 years and show how the organization will build up the right amount of cash reserve so operations can keep going in a stable way 🌈.
The initial estimate is an on-going annual contribution of USD 900.000 to IASF in 2005 💜. On top of that, ISOC will contribute an additional USD 600.000 as an initial fund to start up IASF 🎉. That money is payable after the Board of Trustees is seated and this contract is signed and approved by the IETF 🤝.
ISOC commits to this ongoing level of contribution (USD 75.000 per month) for the lifetime of this contract, unless the parties change it by mutual agreement 🫶.
4.5. Termination, law and so on
This agreement may be terminated by either party for any reason, as long as they give 12 months' notice 👋.
The parties may reach mutual agreement on a shorter termination period ⏳.
All conflicts under this agreement are to be adjudicated under the laws of the United States and the State of Virginia 🇺🇸. However, the parties may also agree to arbitration, mediation, or any other conflict resolution mechanisms 🕊️.
5. Notes and Explanations
This is where we put down why things are the way they are 🧠.
5.1. Type of legal instrument
This document is styled as a contract, which is an agreement between two parties that's enforceable under law 📝. An alternate formulation would be a Memorandum of Understanding, but we want it to be clear to everyone that the parties stand behind their responsibilities under this document 💪. At the moment, the authors see no compelling arguments for not making it a contract 🤷♀️. In either case, the document is published as an RFC 📰.
5.2. Power Balance
The design makes it easy to do the right thing, as long as the parties agree on what that is 🎯. It also makes it clear that ISOC will keep paying money as long as IASF does the Right Thing and reports what it's doing 💸. And if it becomes clear that IASF is not doing the Right Thing, ISOC can stop the show quickly 🛑. Main character energy for ISOC, honestly 👑.
5.3. Budget figures
The main purpose of the numbers is to make it clear that there WILL be numbers in this contract, and that they WILL represent a solid commitment by ISOC 💯. The numbers are "subject to change without notice" while this contract is being negotiated 📝.
6. Draft Incorporating Documents for the IETF Administrative Support Foundation
6.1. Draft Articles of Incorporation
This section contains standard, pro-forma Articles of Incorporation 📑. Note well that tax lawyers often make significant changes to standard Articles as they look at a 501(c)(3) application 🧾. These are included only as a sample, for illustrative purposes only 🎀.
'Commonwealth of Virginia -- State Corporation Commission'|
'Articles of Incorporation -- Virginia Nonstock Corporation'|
Form SCC819, 07/ 03 [1] ------The undersigned, pursuant to Chapter 10 of Title 13.1 of the Code of Virginia, [Virginia] state(s) as follows 🖋️:
- The name of the corporation is The IETF Administrative Support Foundation 🦋.
- The corporation shall have no members 🙅.
- The purpose of the corporation is to manage and administer all the administrative functions for the IETF, which is the Standardization and Protocol Development activity of the Internet Society 🌐.
- The Trustees of the corporation shall be elected or appointed as specified in Article IV (Section 6.2.5) of the Bylaws 🗳️.
- Name and agent:
- A. The name of the corporation's initial registered agent is: XXX
- B. The initial registered agent is a domestic or foreign stock or nonstock corporation, limited liability company, or registered limited liability partnership authorized to transact business in Virginia 🏢.
- The initial Trustees are: XXX 👩💼
- The incorporators are: XXX 🧚
6.2. Draft Bylaws of the IETF Administrative Support Foundation
As with the Draft Articles, the Draft Bylaws included here are a pro-forma, standard version 📚. Substantial alteration may be required as legal counsel reviews the specific nature of an incorporation ⚖️.
6.2.1. Article I: Organization
The name of the Corporation shall be The IETF Administrative Support Foundation, which is also referred to in these Bylaws as the "IASF" 🌸.
6.2.2. Article II: Purpose
Section 1: Purpose. The IASF shall be operated exclusively for nonprofit educational, charitable, and scientific purposes 📚, including, without limitation, the purposes stated in the IASF's Articles of Incorporation 🌟.
Section 2: Restrictions. No part of the net earnings of the IASF shall inure to the benefit of, or be distributable to, private persons 🙅♀️. The only exception is that the IASF is authorized and empowered to pay reasonable compensation for services rendered, and to make payments and distributions in furtherance of the purposes set forth in Article II, Section 1 hereof 💼. Any other provision of these Bylaws to the contrary notwithstanding, the IASF shall not carry on any activities that are not permitted for a corporation exempt from Federal Income Tax under Section 501(a) and Section 501(c)(3) of the Code 🚫. These Bylaws shall not be altered or amended in derogation of the provisions of this Section 🔒.
6.2.3. Article III: Members
The IASF shall have no members and no stockholders 🫶.
6.2.4. Article IV: Offices
The office of the IASF shall be as determined from time to time by the Board of Trustees (BoT), whether that's within or outside of the State of Virginia 🗺️.
6.2.5. Article V: Board of Trustees
Section 1: Authority and Responsibilities. The power, authority, property, and affairs of the IASF shall at all times be exclusively exercised, controlled, and conducted by or under the authority of the Board of Trustees (BoT) 👑. That's subject to any limitations set forth in the Articles of Incorporation, and in accordance with the Virginia Nonstock Corporation Act as it now exists or as it may hereafter be amended 📖.
Section 2: Board of Trustees Composition. The Board of Trustees shall consist of seven (7) Trustees 🧑🤝🧑:
- One (1) Trustee will be selected by the IAB 🌷.
- One (1) Trustee will be selected by the IESG 💜.
- Two (2) Trustees will be selected by the Internet Society 🌍.
- Three (3) Trustees will be selected by the IETF community 🎀.
The IAB chair and the IETF chair will function as liaisons from the IAB and IESG, respectively, to the Board of Trustees 🔗. The chair and president of the Internet Society will function as liaisons from the ISOC to the Board of Trustees 🫶.
Section 3: Terms. The term of office of IESG and IAB Selected Trustees shall be one (1) year, or until their successors have been selected and assume office ⏰. The term of office of otherwise Selected Trustees shall be three (3) years, or until their successors have been selected and assume office 🗓️. Selected Trustees may be selected to serve multiple terms 🔁.
Section 4: Selection of the Board of Trustee
- Selection of IESG and IAB Selected Trustees. The IESG and IAB shall each select one representative Trustee, who is not at the same time an IESG or IAB member 🧐.
- Selection of otherwise Selected Trustees. Three (3) IETF Selected Trustees shall be selected by the IETF nominations process (as defined in [RFC3777] or its successor) and confirmed by the IESG 🗳️. Two ISOC Selected Trustees shall be selected by the Internet Society using means of their own choosing 🌐.
- Resignation. A Selected Trustee may resign by delivering his resignation in writing to the IASF at its principal office, or to the Secretary of the IASF 📬. Such resignation shall be effective upon its receipt, or upon such date (if any) as is stated in such resignation, unless otherwise determined by the Board 🗓️.
- Removal. A Selected Trustee selected by the IETF nominations process may be removed from office at any time using the procedures specified in [RFC3777] or its successor ⚖️. A Selected Trustee selected by the Internet Society may be removed by the Internet Society using means of their own choosing 💅.
- Vacancies. Any vacancy in the Board of Trustees shall be filled using the procedures set forth above on the composition of the Board of Trustees 🪑. The Trustees shall have and may exercise all of their powers notwithstanding the existence of one or more vacancies in their number 💪.
Section 5: Quorum. A majority, which is fifty (50) percent plus one (1), of the Trustees shall constitute a quorum for the transaction of business 🥳. Unless otherwise stated in these
okay so for the Board's decisions 🎀 the rule is that they're made by the concurrence of a majority of the Trustees who are present and voting. and if there's no quorum at a meeting? the Board must not transact business at all. no vibes-based votes 💀
Section 6: Compensation and Reimbursement. 💖 No member of the Board of Trustees may receive compensation for his or her services as a Trustee 🙅. But a Trustee can ask to be reimbursed for actual, necessary and reasonable travel and subsistence expenses they rack up while doing their duties ✈️. Sis gets her receipts back 🧾.
Section 7: Meetings. 📅 The Board of Trustees shall meet at least twice annually.
- Written notice, waiver, action. 📧 Wherever the text below says "written," e-mail is also allowed.
- Annual Meeting. 🌸 The Board of Trustees shall hold a public Annual Meeting at a time and place tied to the first IETF meeting each year. This Annual meeting is open to all IETF attendees, except the parts dealing with personnel issues, which may be held in executive session 🤫.
- Meeting Types, Methods, and Notice. 🦋 Board meetings may be held from time to time, at such intervals and in such places as the Board fixes. Board meetings may be held only in person or via teleconference. Notice of all regular Board meetings shall be delivered to each Trustee by e-mail or by postal mail, and announced on the IETF-Announce list at least ten (10) calendar days before the meeting ⏰. Special meetings may be called for any purpose at any time by the Chairman of the Board or by any three (3) Trustees 📣. Notice of any special meeting shall state the purpose of the meeting. A Trustee may waive notice of a Board meeting by submitting a signed, written waiver of notice, either before or after the meeting ✍️. A Trustee's attendance at or participation in a meeting waives any required notice of that meeting, unless at the start of the meeting or promptly upon arrival the Trustee objects to holding the meeting or transacting business at it, and does not afterward vote for or assent to action taken at the meeting. Main character boundaries 💅.
- Actions Taken By the Board of Trustees Without Meeting. 🫶 Any action required or permitted to be taken at any Board meeting may be taken without a meeting if all Trustees consent in writing to that action. Such action shall be evidenced by written consents approving the lack of a meeting, signed by each Trustee 🖊️.
Section 8: Board Committees. 🧚 The Trustees may elect or appoint one or more committees (including, but not limited to, an Executive Committee), and may delegate to any such committee or committees any or all of their powers. But any committee that gets the Trustees' powers must consist solely of Trustees 👑. Committees conduct their affairs in the same manner as these By Laws provide for the Trustees. Committee members stay in office at the pleasure of the Board of Trustees 💜.
Section 9: Trustee Member Conflict of Interest. ⚖️
- As set forth in Section 9(3) below, a Trustee of the IETF Administrative Support Foundation (IASF) who has a personal interest in a transaction, as defined below, may not take part in any discussion of that transaction by the Trustees of The IASF, and may not vote to decide whether to authorize, approve, or ratify that transaction, except as specifically described below. For these Bylaws, a "personal interest" is any act that will provide, directly or indirectly, a financial benefit or a disparate benefit individually to the Trustee, or to a company he or she is employed by, has a significant financial interest in, or represents in any fashion. Now, policies under consideration by the IASF are likely to affect the business of every Trustee 🙃. It's expected that most policy decisions will have a direct or indirect impact on a Trustee's company, but that kind of non-individualized interest does not count as a "personal interest" as used in these Bylaws. A "transaction" with The IASF, for these Bylaws, is a contract or consultancy in which the Trustee has a direct or indirect financial benefit, or a policy under consideration that will have a disparate and unusual impact on a business the Trustee is directly or indirectly associated with 📊.
- The mere existence of a personal interest held by a Trustee of The IASF in a transaction with the IASF shall not invalidate the IASF's ability to enter that transaction, so long as one of the following conditions is met 🌈: (i) the material facts of the personal nature of the transaction with The IASF and the Trustee's interest in it are fully disclosed to the Board of Trustees of the IASF, either by the Trustee, who has a direct or indirect personal interest in the transaction, or are brought to the Board's attention by a third party; or (ii) the BoT of the IASF, by a vote of the Trustees (without a conflict of interest), votes to authorize, approve, or ratify a transaction with the IASF; or (iii) the transaction with the IASF, in which the direct or indirect personal interest of an IASF Trustee was disclosed to the BoT of The IASF, is determined by the BoT of the IASF entitled to vote on the matter to be in the IASF's interests by a vote of the BoT, notwithstanding the personal interest of the non-voting Trustee 🎯.
- In determining whether a conflict of interest exists, the BoT of the IASF has the prerogative, upon review of all facts and circumstances, to make its own determination of whether a conflict of interest exists and how it is appropriate to proceed. A Trustee who perceives the possibility of a conflict of interest for him or herself, or for another Board member, may raise the issue at any point before a vote on any issue 🙋. Any Trustee who perceives a possible conflict of interest may present justification as to whether or not a conflict of interest exists. But the entire Board, except the Trustee who has the potential conflict of interest, makes the final determination on whether to proceed in such a matter 🗳️. If the BoT finds there is a conflict of interest, the Chair of the Board may exclude the Trustee with the conflict from the portion of any meeting where a substantive discussion or decision to engage, or not engage, in such a transaction takes place. Before leaving that meeting, however, the Trustee may provide any information that will help the Trustees with the matter 💁.
Section 10: Approval of Meeting Minutes. 📝 Minutes of the BoT of the IASF must be approved by a procedure adopted by the board and published on the IASF web site 🌐.
6.2.6 Article VI: Officers 👑
Section 1: Number. 💅 The officers of the IASF shall consist of a Chairman of the Board, a Treasurer and a Secretary, plus such other inferior officers as the BoT may determine.
Section 2: Election Term of Office and Qualifications. 🗓️ All officers shall be elected annually, by the vote of a majority of the Board of Trustees present and voting (excluding abstentions) at the Annual Meeting. The Treasurer and Secretary need not be members of the Board. Neither the Chair of the IETF nor the chair of the IAB shall be the Chairman of the Board of the IASF 🙅♀️.
Section 3: Resignation. 👋 An officer may resign by delivering a written resignation to the IASF at its principal office, or to the Chair or Secretary. The resignation takes effect upon receipt, or on such date (if any) as is stated in it, unless the Board determines otherwise 🦋.
Section 4: Removal. ⚠️ The BoT may remove any officer, with or without cause, by a vote of a majority of the entire number of Trustees then in office, at a BoT meeting called for that purpose. An officer may be removed for cause only if notice of such action has been given to all of the Trustees before the meeting at which the action is to be taken, and if the officer to be removed has been given reasonable notice and an opportunity to be heard by the BoT 🎤.
Section 5: Vacancies. 🌱 If any elected officer position of the IASF becomes vacant, the majority of the Trustees in office, although less than a quorum, may elect an officer to fill the vacancy at the next BoT meeting. The officer so elected holds office and serves until the next Annual Meeting 🪄.
Section 6: Chairman of the Board. 🎀 The Chairman of the Board shall, when present, preside at all meetings of the BoT of the IASF. If the Chairman is not available to preside over a meeting, the majority of the Trustees present shall select another Trustee to preside at that meeting only 🫡.
Section 7: Treasurer. 💰 The Treasurer shall have custody of all funds, property, and securities of the IASF, subject to such regulations as the Board of Trustees may impose. He or she may be required to give bond for the faithful performance of his or her duties, in such sum and with such sureties as the BoT may require or as required by law, whichever is greater. When necessary or proper, he or she may endorse checks, notes and other obligations on behalf of the IASF for collection, and shall deposit them to the credit of the IASF at such bank or banks or depository as the BoT may designate. He or she shall make, or cause to be made, such payments as may be necessary or proper on behalf of the IASF. He or she shall enter, or cause to be entered regularly, in the books of the IASF kept for that purpose, a full and accurate account of all monies and obligations received, paid or incurred for or on account of the IASF, and shall exhibit those books at all reasonable times to any Trustee on application at the offices of the IASF, incident to the Office of Treasurer, subject to the control of the BoT 📚. Certain duties of the Treasurer, as specified by the BoT, may be delegated by the Treasurer 🧸.
6.2.6. Article VI: Officers 👑
Section 8: Secretary. Okay so the Secretary is basically in charge of whatever books, records, documents, and papers the BoT decides on, and they hold the corporate seal 🌸 The Secretary shall keep, or cause to be kept, the minutes of all meetings of the BoT. Together with the Chairman, the Secretary may sign any contracts or agreements in the name and on behalf of the IASF, and he or she may affix the corporate seal of the IASF. Generally speaking, they handle all the duties that come with being Secretary, under the supervision and control of the Board of Trustees 💅 They shall also do and perform any other duties the BoT or the Chairman of the BoT gives them. The BoT can specify certain Secretary duties, and the Secretary can delegate those ones. ✨
Section 9: Other Powers and Duties. Every officer gets the duties and powers written in these By Laws, plus whatever duties and powers are customarily part of their job, plus anything the Trustees choose to hand them from time to time 🦋
6.2.7. Article VII: Amendments 📝
Section 1: By Laws. These By Laws can be amended by an affirmative vote of a majority of the Trustees then in office (excluding abstentions). That vote happens at a regular board meeting, or at a board meeting called for that purpose, as long as the proposed changes are made available to all trustees and posted to the IETF Announce list at least 30 days before any such meeting. No surprise edits, bestie 🙈
Section 2: Articles of Incorporation. The Articles of Incorporation of the IASF can be amended by an affirmative vote of two-thirds of the BoT then in office. That vote also happens at a regular board meeting, or at a board meeting called for that purpose, as long as the proposed changes are made available to all trustees and posted to the IETF Announce list at least 30 days before any such meeting. Same energy, bigger threshold 💜
6.2.8. Article VIII: Dissolution 🦋
Okay, this one is serious but still iconic 😭 If the IASF ever dissolves, it first has to pay off, or make provisions to pay, all of its liabilities. Then it disposes of all of its assets exclusively for its exempt purposes, either in the manner described here or to an organization or organizations operated exclusively for social welfare or charitable purposes. Any assets that don't get disposed of that way will be handled by a court of competent jurisdiction in the county where the principal office of the organization is then located, and they still have to go exclusively to those purposes. In the event of a sale or dissolution of the corporation, the surplus funds of the corporation shall not inure to the benefit of, or be distributable to, its Trustees, officers, or other private persons. No one gets to cash out, periodt 💅
6.2.9. Article IX: Miscellaneous Provisions 🧚
Section 1: Fiscal Year. The fiscal year of the IASF shall run from January 1 to December 31 of each year. 📅
Section 2: Execution of Instruments. All checks, deeds, leases, transfers, contracts, bonds, notes, and other obligations that an officer of the IASF is authorized to execute on its behalf shall be signed by the Chairman of the Board or the Treasurer, or as the Trustees otherwise determine. A certificate from the Secretary about any action taken by the BoT shall, for everyone who relies on it in good faith, be conclusive evidence of that action. That's the paperwork flex 💼
Section 3: Severability. If any provision of these By-Laws is found, for any reason, to be inapplicable, illegal, or ineffective, that finding does not affect or invalidate any other provision of these By-Laws. The rest of the group chat stays intact 🫶
Section 4: Articles of Incorporation. Every reference in these By Laws to the Articles of Incorporation is deemed to refer to the Articles of Incorporation of the IASF, as amended and in effect from time to time. Always the latest version, bestie 🌈
Section 5: Gender. Whenever used here, the singular number includes the plural, the plural includes the singular, and the use of any gender includes all genders. Everyone's included, no exceptions 🌸
Section 6: Successor Provisions. All references in this document work like this: (1) a reference to the Internal Revenue Code is deemed to refer to the Internal Revenue Code of 1986, as now in force or hereafter amended; (2) a reference to the Code of the State of Virginia, or any Chapter thereof, is deemed to refer to that Code or Chapter as now in force or hereafter amended; (3) a reference to particular sections of the Internal Revenue Code or that Code is deemed to refer to similar or successor provisions hereafter adopted; and (4) a reference to the Request for Comment Series is deemed to refer to the Request for Comment Series as they are now in force or hereafter amended. Future-proof energy, iconic 🔮
7. Acknowledgment of Contributions and Reviews 🫶
A lot of text was taken from the report from Carl Malamud. 📄
Further review was done by various IESG and IAB members. Carl Malamud also reviewed this document and helped make the text better English and easier to read. Main character glow-up for the prose ✨
This document was created with "xml2rfc" <http://xml.resource.org/> using the format specified in [RFC2629]. 🎀
8. IANA Considerations 🎀
This documents requires no action from IANA. 💖
9. Security Considerations 🔥
This document describes a scenario for the structure of the IETF's administrative support activities. It introduces no security considerations for the Internet. Phew, no drama here 🙈
Safety considerations for the integrity of the standards process are outlined in Appendix C. Don't skip that one, it's the real tea 🍓
10. References 📚
10.1. Normative References
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
- [RFC2031] Huizer, E., "IETF-ISOC relationship", RFC 2031, October 1996.
- [RFC3677] Daigle, L. and Internet Architecture Board, "IETF ISOC Board of Trustee Appointment Procedures", BCP 77, RFC 3677, December 2003.
- [RFC3716] Advisory, IAB., "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.
- [Virginia] State of Virginia, "Title 13.1: Corporations, Limited Liability Companies, Business Trusts", Undated,
<http://leg1.state.va.us/cgi-bin/legp504.exe?000+cod+TOC1301000>.
10.2. Informative References
- [I-D.ietf-xmpp-core] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", draft-ietf-xmpp-core-24 (work in progress), May 2004.
- [I-D.malamud-consultant-report] Malamud, C., "IETF Administrative Support Functions", draft-malamud-consultant-report-01 (work in progress), September 2004.
- [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
URIs 🔗
Authors' Addresses 💌
Bert Wijnen
Lucent Technologies
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31-348-407-775
EMail: bwijnen at lucent.com
Harald Tveit Alvestrand
Cisco Systems
Weidemanns vei 27
Trondheim 7043
Norway
EMail: harald at alvestrand.no
Peter W. Resnick
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121-1714
US
EMail: presnick at qualcomm.comAppendix A. Justification, Reasoning and Motivations 🧠
Quite a bit of the proposals from the consultant report made it into this recommendation. However, a number of changes were made, and this section explains which changes they were and why. Receipts, bestie 🧾
A.1. Changes to the name of the administrative entity 🏷️
To make it very clear that the new, legal administrative entity is separate from the ISOC IETF activity that deals with standardization and protocol development, this recommendation uses "The IETF Administrative Support Foundation" as the name for the corporation to be created. Separate lanes, no mix-ups 💅
A.2. Domicile 🗽
Various questions have been raised about whether the choice of Domicile should be investigated further. To make progress, this document recommends making a definite choice now and going with a US based not-for-profit corporation in the state of Virginia. Further investigation would most probably delay the whole process by at least half a year, and nobody wants that 😭
A.3. Changes to the composition of the BoT 🌷
The consultant report had a proposal for Position-based Trustees, which would automatically make the IAB chair and the IETF chair voting members of the Board of Trustees (BoT) of the IETF Administrative Support Foundation. There was discussion on the IETF mailing list that those people are not selected because of their business acumen but rather for their technical leadership. We do not want to change those criteria. Another concern was that this might generate a conflict of interest as well. So this recommendation makes the IAB and IETF chairs liaisons to the BoT. 🤝
Instead of making the IAB and IESG chairs voting Trustees, this recommendation specifies that the IAB and IESG can each select an outside (i.e. not a member of IAB or IESG) person as a voting Trustee. ✨
The selection of three (3) IETF selected Trustees has not changed in this recommendation. However, there is a concern that the current composition of the Nomcom is not tailored to selecting people for this position. So over time, a different process may need to be defined for selecting those Trustees. 🔍
In order to balance the ISOC and IETF people present at the BoT meetings, this recommendation also specifies that the chair and president of ISOC also function as liaisons to the BoT of the IETF Administrative Support Foundation. Fair representation, iconic 🌈
Appendix B. Domicile of the IETF Administrative Support Foundation 🗺️
A U.S. non-profit, non-member corporation is being recommended. This recommendation is based on simple considerations of expediency and pragmatism: a transition will be simplest and least risky (in the short term). The reasoning is as follows:
Okay so the big one first 💅 IETF admin support is currently tangled up with a bunch of other institutions, and most of those are also U.S.-chartered non-profits 🫶 So any change to the institutional status of admin functions means you need to know U.S. nonprofit law inside out. Incorporating in another country means learning those laws too, so the paperwork costs more and takes longer 😭
- U.S. law has this whole vibe called "nexus" 🔍 It's basically when a foreign org has enough connection to U.S. law that a U.S. court can take it on. Since the IETF has a long history of operating in the U.S., tons of meetings there, and loads of U.S.-based participants and leaders, we think U.S. courts would probably find nexus with our U.S. activities even if the admin org was incorporated somewhere else 🇺🇸 So moving abroad doesn't magically free the support org from U.S. law vibes 🙃
- Incorporating outside the U.S. might have tax implications if the Internet Society is providing funding support 💸
- The IETF Administrative Support Foundation would very likely clearly count as "scientific" and "educational," so it would qualify as a tax-exempt charity under section 501(c)(3) of the IRS code. The tax-exempt application should be pretty straightforward ✨
- The incorporation laws of the U.S. states being considered don't require any Board of Trustees members to have a certain nationality or state residency (no "local director" rules!) 🎉 And the U.S. Dept. of Commerce foreign-controlled organization reporting requirements only apply to "business enterprises," so they don't hit non-profits like an IETF admin support org 🙌
Since this document recommends incorporating in the U.S., Virginia is the logical pick for the state of domicile 📍 That lets the IETF admin support org use ISOC headquarters to house its single employee 🏢 (Though the employee could still be housed at the Internet Society even if the incorporation happened somewhere else, like the ISOC Geneva office 🇨🇭)
Appendix C. Risk Analysis ✨
This scenario (like every scenario) has some risks 😬 This section lists the sort of risks we recognize and sums up why we think we can accept each one, or what kind of action we could take if a risk actually turns into a problem 🛠️
C.1. US Domicile risks
As explained in [I-D.malamud-consultant-report], incorporating in the US carries two specific risks: the perception of the IETF being a US-based organization, and the potential for (or perception of) governmental interference 👀
The IETF is an international organization, but even now the IETF standards processes run in English and many of its current support organizations are US-based. That leaves an impression that the IETF is too US-centric 🤔 Incorporating the new administrative entity in the US may add to that perception.
The IETF's history is also rooted in US federal government research and funding 🏛️ Although the IETF has been long separated from those beginnings, even in the past few years there have been interactions between the US government and the IETF that have worried people 😟 Incorporating the administrative entity in the US may invite more US governmental interference in the IETF's standards activity, or at the very least leave the perception that the US government might get involved.
Both of these are serious problems, but we think there is justification for them and at least one mitigation 💜 The main reason to consider US incorporation is expedience (see section 4.4.1.1 of [I-D.malamud-consultant-report]). We agree the expedience makes US incorporation worth the risk. But incorporating in multiple domiciles would significantly mitigate the risk 🌈 So, assuming we go down the path of US incorporation, we'd like legal counsel to advise on incorporating in other domiciles (specifically Switzerland and The Netherlands) at a later date, after US incorporation is done. If that's possible (as we suspect), we think it would be the best way forward 🦋
C.2. Non-profit status risk
One of the risks pointed out to incorporation is that we might not get non-profit status, which means we'd have to keep some money in escrow for tax liability purposes 💰 Estimates for how long it takes to get that status can run to several months, or even longer in some cases ⏳
It's important to point out that tax liability is based on profits, not gross revenues 🧾 If the IASF only takes in enough money to cover expenses, there's very little tax liability. But if more revenue comes in than gets spent, for example to build up an endowment or operating reserve, that "profit" could be taxable if non-profit status isn't granted 😳
To mitigate this, the corporation could be created and non-profit status applied for first, with operations only starting once that status is obtained. The IETF would use an interim plan for continued operations until then. This way, no money would need to sit in escrow during the application process 🛡️ However, that seems like an excessively cautious path given how clearly non-profit the IETF appears to be 🙄
Starting operations while the non-profit application is being considered seems like a prudent move, as long as we're careful about balancing revenue with expenses and keeping an appropriate escrow account 💅 Also, any fundraising campaigns that shift the balance sheet of the IASF should be run cautiously until non-profit status is granted 🫶
C.3. Execution risks
It's important that the execution goes well 🙏 Risks we're aware of include:
- we can't hire a good IAD
- we fail to project cash flow properly and go insolvent
- we can't cut a deal with Foretec and have no 2005 meetings
- we get bad lawyers and they take too long and charge too much
- isoc runs out of money and doesn't tell us early enough
To mitigate these problems, we have a proposed work plan included in this document 📋 It's important that we get this work plan reviewed by as many eyes as possible, to make sure we've considered all the steps that need to be taken 👀✨
C.4. Insolvency risk
Improper management controls and procedures, or other imprudent fiscal or administrative practices, could expose the IETF to a risk of insolvency 😱 Careful selection of trustees, a budget approval process, and a methodical system of fiscal controls are necessary to minimize this risk 🧠
C.5. Legal risks
Improper formulation of the legal framework underlying the IETF may expose the institution, and the individuals in leadership positions, to potential legal risks ⚖️ Any such risk under this plan appears to be equivalent to the risk the community already faces under the current legal framework. This risk is further mitigated by a thorough review by legal counsel and by use of insurance coverage 🛡️
The legal exposure is best minimized by careful adherence to our procedures and processes, as defined by the Best Current Practice Series 📚 A carefully stated process, like the BCP documents that govern the selection of leadership positions and define the standards process, is the best insurance against legal exposure, provided we take care to stick to the process standards that have been set 🔐 A public rule book and a fully open process are the most effective mechanisms the IETF community can use 🌸
Appendix: Scenario O 🦋
This Appendix reproduces the contents of an Internet-Draft defining Scenario O, as it was posted on 20 September 2004 📅 A table of contents has been removed from this copy, and the text has been reformatted to fit within IETF publication guidelines 💅
L. Daigle
VeriSign
M. Wasserman
ThingMagic
September 20, 2004
AdminRest Scenario O: An IETF-Directed Activity Housed Under the
Internet Society (ISOC) Legal UmbrellaAbstract
This document defines an alternative proposal for the structure of the IETF's administrative support activity (IASA) 💖 It's an IETF-defined and directed activity that operates within the ISOC legal umbrella ☂️ It proposes creating an IETF Administrative Oversight Committee (IAOC) that is selected by and accountable to the IETF community 🗳️ This committee would provide oversight for the IETF administrative support activity, which would be housed within the ISOC legal umbrella. To let the community properly evaluate this scenario, some draft BCP wording is included 📝
1. Overview of Scenario O
IETF community discussions of the scenarios for administrative restructuring in Carl Malamud's consultant report [I-D.malamud-consultant-report] have uncovered a potentially viable alternative that isn't in that report 🤩 It's an IETF-defined and directed administrative support function housed under the ISOC legal umbrella (called "IASA" from here on). This new scenario keeps some properties of the original ISOC-based scenarios, Scenarios A and B. But it also aims to provide:
- continued close relationship with ISOC
- a clear basis from which the IETF can define (and, over time, refine) the administrative activity in terms of IETF community needs, using existing IETF/ISOC processes
- an operational oversight board that is accountable to the IETF community
- continued separation between the IETF standards activity and any fund-raising for standards work (within ISOC)
- appropriate ISOC oversight of its standards activities funds
This scenario is nicknamed "Scenario O". It's derived from, but doesn't entirely encompass, Scenario A or Scenario B 🌈
Scenario O is the one where the IETF gets real control over its admin stuff without having to build its own whole corporate structure (and all the tax-exempt, financial-infrastructure drama that comes with it) 💅 The admin support function would get defined in a BCP made through the standards process [RFC2026], and ISOC's Board of Trustees would approve it. ✨ This BCP would scope out an IETF Administrative Support Activity (IASA) and set up the IETF Administrative Oversight Committee (IAOC), an IETF-picked group that oversees the IASA 🫶 Just like the Internet Architecture Board (IAB), the IASA would live under the ISOC legal umbrella. The BCP would also spell out ISOC's job in this scenario, including financial accounting and transparency rules 📋 A draft of that BCP is coming up in the next section 🎀
Scenario O lets the community steer its admin support functions, checking that they actually meet what people need and tweaking them over time through IETF processes 🔥 It doesn't make the community set up and take on the risks of a whole corporate structure (with financial infrastructure and tax-exempt status like ISOC's) just to fix the admin issues listed in [RFC3716] 😭 And it draws clear boundaries around the IASA, so it could be packaged up and moved somewhere else later if that ever becomes a good idea 🦋
2. Draft of Administrative Support BCP ✨
This section has draft text for a BCP that would define the scope and structure of the IASA 💖 The wording would still need more polishing with the IETF community, but this section is meant to be clear and complete enough that people can form a well-informed opinion about this scenario 🧚
2.1. Definition of the IETF Administrative Support Activity (IASA) 🌸
The IETF does its technical work as an ongoing, open, consensus-based process 🫶 ISOC has been part of the IETF's standards process for a long time, and this document doesn't change the ISOC-IETF working relationship around standards development or sharing technical advice 💜 The point of this memo is to define an admin support activity that actually serves the IETF technical community's needs, while also fitting ISOC's operational, financial and fiduciary requirements and still supporting the IETF's technical activity 👑
The IETF Administrative Support Activity (IASA) gives admin support to the IETF's technical work 💅 That includes, as appropriate, doing or contracting for the work described in [RFC3716] (the eventual BCP should put those details in an appendix), plus IETF document and data management, IETF meetings, and any operational agreements or contracts with the RFC Editor and IANA 🎀 This is the admin backdrop that the IETF standards process needs, and it supports the IETF's organized technical activities, including the IESG, IAB and working groups ✨ It also covers the money side of that support, like collecting IETF meeting fees, paying invoices, good financial management, and so on 🙈 The IASA is responsible for making sure the IETF's admin work gets done and done well 🔥 It isn't expected to do all that work itself. Instead, it contracts the work out to others and manages those contracts according to key operating principles like efficiency, transparency and cost effectiveness 💅
The IASA is separate from other IETF-related technical functions like the RFC Editor, the Internet Assigned Numbers Authority (IANA), and the IETF standards process itself 🦋 The IASA isn't meant to have any influence on the IETF's technical decisions or on the technical content of IETF work 🫶
2.1.1. Structure of the IASA 🌈
The IASA will be set up so it's accountable to the IETF community 💖 It will judge whether the activity keeps succeeding at meeting the IETF community needs laid out in this BCP, and ISOC keeps an eye on its financial and resource contributions too 👑 The supervisory body for this is the IETF Administrative Oversight Committee (IAOC) 🧚 The IAOC will be made of volunteers, all chosen directly or indirectly by the IETF community, plus appropriate ex officio appointments from ISOC and IETF leadership ✨ It will be accountable to the IETF community for the effectiveness, efficiency and transparency of the IASA 🫶
The IASA will start out with one full-time ISOC employee, the IETF Administrative Director (IAD) 🎀 The IAD will need a bunch of financial, legal and admin support, and that support is expected to come from ISOC support staff, following an expense and/or allocation model that's still TBD 😭
Even though the IAD is a full-time ISOC employee, he works under the direction of the IAOC 💅 The IAD gets selected by a committee of the IAOC, which has at minimum the ISOC President and the IETF Chair 👑 That same committee is also in charge of periodically reviewing the IAD's performance and deciding any changes to his employment and compensation 🌸 In certain cases (which still need to be defined clearly, mainly where the ISOC employee is found to have broken basic ISOC policies), the ISOC President can make summary decisions, which the hiring committee reviews after the fact 💀
The IAD handles the IETF finances, manages a separate bank account for the IASA, and sets up and runs the IASA budget 🍓 To do all this, the IAD is expected to have signing authority comparable to other ISOC director-level employees 💖 Expenses or agreements beyond that authority are to be approved for financial soundness as determined by ISOC policy 📋 The shared expectation is that ISOC's policies will allow the IAD to carry out IASA work effectively and efficiently 🫶 If the IAOC has concerns about that, the IAOC and ISOC commit to working out other policies that both sides can agree on 🦋
The IAD also takes on the role of IETF Executive Director, as described in various IETF process BCPs 🧚 Every other admin function gets outsourced through well-defined contracts 💅 The IAD is responsible for negotiating and maintaining those contracts, plus coordinating whatever is needed so the IETF admin support functions are properly covered 🎀
2.1.2. IAD Responsibilities 💜
The IAD's day-to-day job is mainly managing contracts with the entities doing the work that supports the IETF technical activity 🌈
The IAD gives regular (monthly and quarterly) reports to the IAOC and ISOC 📋
All contracts are negotiated by the IAD (with input from any other appropriate bodies) and reviewed by the IAOC 🔥 The contracts get executed by ISOC on behalf of the IETF, after whatever review ISOC requires (for example, legal and Board of Trustees) ✨
The IAD prepares an annual budget, which the IAOC reviews and approves 💖 The IAD is responsible for presenting this budget to the ISOC Board of Trustees as part of ISOC's annual financial planning process 👑 The arrangement works like this: the IAOC is responsible for making sure the budget suits the IETF community's needs, but it doesn't carry fiduciary responsibility 😭 The ISOC board needs to review and understand the budget and planned activity, and have enough detail on the budget and proposed plans to properly carry out its fiduciary responsibility 🫶
2.1.3. IAOC Responsibilities 🦋
The IAOC's role is to give appropriate input to the IAD and to oversee how the IASA is functioning 🌸 The IAOC isn't expected to be regularly doing IASA work itself. Its job is to provide appropriate approval and oversight 🧚
So, the IAOC's responsibilities are:
- Select the IAD, as described above. 👑
- Review the IAD's financial reports, and approve the IAD's budget proposals in terms of fitness for IETF purposes. 💅
- Review how the IASA is functioning with respect to meeting the IETF community's working needs. ✨
The IAOC reviews the work of the IAD and the IASA, it doesn't do that work itself 💖 Because of that, the IAOC is expected to hold monthly teleconferences and periodic face-to-face meetings, probably coinciding with IETF plenary meetings, to keep the operation efficient and effective 🎀
2.1.4. IASA Funding 🌈
The IASA gets financial support in 3 ways 💜
- IETF meeting revenues. The IAD, in consultation with the IAOC, sets the meeting fees as part of the budgeting process. All meeting revenues go to the IASA. 💖
- Designated ISOC donations. The IETF and IASA do no specific fundraising activities, which keeps fundraising separate from standards activities 🫶 Any organization that wants to support IETF activity will keep being directed to ISOC, and any funds ISOC receives specifically for IETF activities (as part of an ISOC program that allows specific designation) will go into the IASA bank account for IASA management 🦋
- Other ISOC support. Each quarter, ISOC will deposit in the IASA account the funds it has committed to provide as part of the IASA budget (for whenever meeting revenues and specific donations don't cover the budget) 🌸 These funds may come from member fees or from other revenue streams ISOC may create 💅
The goal is to reach and keep a viable IETF support function based on meeting fees and specified donations, and the IAOC and ISOC are expected to work together to get there 👑 (Basically, dropping the meeting fees to $0 and expecting ISOC to pick up the slack is not desirable 😭 Neither is raising the meeting fees to prohibitive levels just to fund all the non-meeting-related activities! 💀)
Also, in normal operating circumstances, the IASA would aim to have a 6 month operating reserve for its activities 🍓 Instead of the IASA trying to build that up in its bank account, the IASA looks to ISOC to build and provide that operational reserve, through whatever mechanism ISOC deems appropriate (a line of credit, financial reserves, etc.) 🧚 Reserves don't show up instantly, so the goal is to reach that level of reserve by 3 years after the IASA is created 🦋 Funds tied to that reserve are not expected to be held in the IASA bank account 🌈
2.2. IAOC Membership, Selection and Accountability ✨
bestie, this section is literally still being cooked 🍳 The note says it's "particularly subject to change," because the team is still figuring out the best way to hit the key principles. Those principles are: the IASA should be pretty separate from IETF Standards process management, BUT:
- the IETF and IAB Chairs need to be involved enough to oversee the parts of the technical work they're responsible for (e.g., the IAB looks after the RFC Editor relationship) 🧚
- the IETF and IAB Chairs must not be critical path to getting decisions to and through the IASA. 💀
So the current draft makes the IETF Chair an ex officio voting member of the IAOC, and the IAB Chair a non-voting liaison. Future versions might change either or both, depending on what the IETF community thinks makes sense 🫶
The IAOC will have seven voting members, picked like this:
- 2 members chosen by the IETF Nominations Committee (NomCom) 💜
- 1 member chosen by the IESG
- 1 member chosen by the IAB
- 1 member chosen by the ISOC Board of Trustees
- The IETF Chair (ex officio)
- The ISOC President/CEO (ex officio)
There are also two non-voting, ex officio liaisons:
- The IAB Chair
- The IETF Administrative Director
The voting IAOC members pick their own chair every year, using a consensus method they choose. Any appointed voting member can be the IAOC Chair (so not the IETF Chair or the ISOC President/CEO, babe). The IAOC Chair's whole job is to organize the IAOC 📋 They don't have any formal duties to represent the IAOC, unless the IAOC consensus tells them to.
The IAOC members usually serve two-year terms. At the start, the IESG and ISOC Board make one-year appointments, the IAB makes a two-year appointment, and the NomCom makes one one-year and one two-year appointment. That way roughly half the IAOC gets picked each term, which is iconic for continuity 🌈
The two NomCom-picked members get selected using the procedures in RFC 3777. For the very first selection, the IESG provides the list of qualifications they want for these seats. After that, the IAOC gives the list.
There are no hard rules about how the IAB and IESG should pick their IAOC members. It's not expected that they'll usually choose current IAB or IESG members, if only so the existing leadership doesn't get overloaded 🙈 They should pick people who understand the administrative support needs of the IAB, the IESG and/or the IETF standards process. The selections are suggested to be pretty open, maybe with a public call for nominations and/or a public comment period on the candidates. The IAB and IESG are encouraged to check out how the IAB selects ISOC Trustees as an example of how this might work. 🎀
Even though the IAB and IESG pick some IAOC members, those members won't directly represent the bodies that picked them. All IAOC members are accountable directly to the IETF community. To get direct feedback from the community, the IAOC will hold an open meeting at least once a year at an IETF meeting. That could be an open IAOC plenary or a working meeting in an IETF meeting slot. The form and contents of that meeting are up to the IAOC Chair.
Decisions made by individual IAOC members or the whole IAOC can be appealed using the procedures in RFC 2026. The first appeal of an individual decision goes to the full IAOC. Appeals of IAOC decisions go to the IESG and keep climbing the chain as needed (to the IAB and the ISOC Board). The IAOC plays no role (except possibly some admin support) in appeals of WG Chair, IESG or IAB decisions.
If an IAOC member abandons their duties or acts against the bests interests of the IETF community, IAOC members can be recalled using the recall procedure in RFC 3777. IAB- and IESG-appointed members are not subject to recall by the bodies that appointed them. 😤
2.3. IASA Budget Process 💸
The IASA sets a budget for the IETF's administrative needs, but the budget process has to be closely coordinated with ISOC's. The specific timeline gets set every year, before the second IETF meeting. A general annual budgeting timeline looks like this:
- July 1 The IAD presents a budget proposal (for the following fiscal year, with 3-year projections) to the IAOC. 📅
- August 1 The IAOC approves the budget proposal for IETF purposes, after any appropriate revisions. Since the ISOC President is part of the IAOC, the IAOC should have a preliminary idea of how the budget fits with ISOC's own budget expectations. The budget proposal then goes to the ISOC Board of Trustees for review, in line with their fiduciary duty.
- September 1 The ISOC Board of Trustees approves the budget proposal provisionally. For the next 2 months, the budget may be revised so it can be integrated into ISOC's overall budgeting process.
- November 1 Final budget goes to the ISOC Board for approval. 👑
The IAD gives monthly accountings of expenses and updates expenditure forecasts quarterly. This might mean the IASA budget has to be adjusted. Any revised budget needs approval from the IAOC and the ISOC Board of Trustees.
2.4. Relationship of the IAOC to Existing IETF Leadership 🫶
The IAOC is directly accountable to the IETF Community. But the IAOC's work involves treating the IESG and IAB as internal customers. The IAOC should not consider its work successful unless the IESG and IAB are happy with the administrative support they're getting. Main character energy for the leadership, ngl ✨
2.5. ISOC Responsibilities for IASA 🏢
Inside ISOC, support for the IASA should be set up to meet these goals:
- Transparency: The IETF community should have complete visibility into the financial and legal structure of the ISOC standards activity. Specifically, the IETF community should have access to a detailed budget for the entire standards activity, quarterly financial reports and audited annual financials. Key contract material and MOUs should also be publicly available. Most of these goals are already met by ISOC today. The IAOC will be responsible for giving the IETF community regular overviews of the state of affairs. 🔍
- Unification: As part of this arrangement, ISOC's sponsorship of the RFC Editor, IAB and IESG, as well as insurance coverage for the IETF, will be managed as part of the IASA under the IAOC. 🧩
- Independence: The IASA should be financially and legally distinct from other ISOC activities. IETF meeting fees should be deposited in a separate IETF-specific bank account and used to fund the IASA under the direction and oversight of the IAOC. Any fees or payments collected from IETF meeting sponsors should also go into this account. The IAD administers this account and uses it to fund the IASA, following a budget and policies developed as described above. 🌸
- Support: ISOC may, from time to time, choose to transfer other funds into this account to fund IETF administrative projects or to cover IETF meeting revenue shortfalls. There may also be cases where ISOC chooses to loan money to the IASA to help with temporary cash flow issues. These cases should be carefully documented and tracked on both sides. ISOC will work to provide the 6 month operational reserve for IASA functioning described above. 💖
- Removability: There is no current plan to transfer the legal and financial home of the IASA to another corporation. However, the IASA should be structured to allow a clean transition if the IETF community decides, through BCP publication, that such a transition is required. In that case, the IAOC will give ISOC a minimum of six months' notice before the transition formally happens. During that period, the IAOC and ISOC will work together to create a smooth transition that does not result in any significant service outages or missed IETF meetings. All contracts executed by ISOC as part of the IASA should either include a clause allowing termination or transfer by ISOC with six months' notice, or be transferrable to another corporation if the IASA is ever moved away from ISOC. Any accrued funds, and IETF-specific intellectual property rights (concerning administrative data and/ or tools) would also be expected to move to any new entity. 🦋
Within the constraints above, all other details about how to structure this activity within ISOC (as a cost center, a department or a formal subsidiary) should be decided by ISOC in consultation with the IAOC.
3. Workplan for Formalizing the IETF Administrative Support Activity 🗺️
This section proposes a workplan and schedule for formalizing the IETF administrative support activity (IASA) for the remainder of 2004 and 2005.
3.1. Workplan Goals 🎯
This workplan is meant to satisfy four goals:
- Satisfy the IETF's need for support functions through 2005, with a careful transition that minimizes the risk of substantial disruption to the IETF standards process.
- Establish IETF community consensus and ISOC approval of a BCP formalizing the IASA as described in this scenario before any actions are taken that will have long-term effects (hiring, contacts, etc.)
- Make sure that decisions with long-term impact, such as hiring the IAD and establishing contracts for administrative support, are made by people chosen for that purpose who will be responsible to the community for the effectiveness of this effort (the IAD and members of the IAOC) -- not by our already overloaded technical leadership. 🙌
- Within the above constraints, move as quickly as possible towards a well-defined administrative support structure that is transparent and accountable to the IETF community. ⭐
3.2. Workplan Overview 🧁
There are three major elements to this workplan, which can, to some degree, happen in parallel after we establish IETF community consensus to pursue Scenario O:
- Finalizing the BCP text and getting it approved by the IETF community and ISOC. 🎀 This is the big finish line, bestie.
- Selecting IASA leadership. This includes appointing an interim IAOC, recruiting the IAD, and eventually appointing the full IAOC. 👑
- Negotiating agreements with service providers. This includes determining the structure and work flow of the IASA, deciding which portions of the IASA should be staffed via an open request for proposals (RFP) process, and issuing a RFP for those portions, as well as establishing sole source contracts or MOUs for other portions of the IASA. 💅
Each of the three items listed above is described in more detail in the following sections. 🦋
3.3. Approval by the IETF Community and ISOC ✨
Okay so in Scenario O, the IASA gets formalized in a BCP. The IETF community has to approve it, and the ISOC Board of Trustees has to accept it. 🌈 There are three steps:
- Establishment of IETF community consensus that we should pursue Scenario O as defined in a joint IAB/IESG recommendation based on this proposal. This consensus will be established through community discussion and a formal two-week consensus call issued by the IETF chair on the IETF mailing list. 📣
- Establishment of IETF community consensus on a BCP that formalizes the IASA as described. This consensus would be established through public discussion, a four week IETF Last Call and IESG review and approval. 🔥
- ISOC approval of the BCP and acceptance of ISOC's responsibilities as described therein. This approval and acceptance would be signified by an ISOC Board resolution. 💜
The timeline for these three stages is rather long, but there is significant progress that can be made in other areas once we have established IETF community consensus to pursue this scenario. 🧚
O>>
3.4. Selecting IASA Leadership 👑
Once we have IETF consensus to pursue this scenario, we can appoint an interim IAOC to begin working on the IASA transition. 🎀 The interim IAOC could do substantial work on non-binding tasks, such as beginning the recruitment process for an IAD, determining the structure of the IASA work, issuing RFPs and negotiating potential agreements with service providers. The interim IAOC would not be empowered to make binding agreements, but could work appropriate consultants and advisors to make a lot of progress towards determining the initial structure and work flow of the IASA. 💖
Because the IETF Nominations Committee (NomCom) process for new positions will consume a lot of resources and take a long time to complete, we propose that the interim IAOC consist of: 🦋
- 1 IESG selected member
- 1 IAB selected member
- 1 ISOC selected member
- The IETF Chair
- The ISOC President/CEO
The IAB chair will serve as a liaison, as described above. 🫶
The IESG and ISOC Board appointments will be expected to serve until the first IETF meeting of 2006, and the IAB appointment will be expected to serve until the first IETF meeting of 2007, assuming that the BCP is approved and the IAOC continues to have appointed members from these bodies. 📅
After all of the interim IAOC members are selected, they will choose an interim IAOC chair from among the appointed members. 🌸
When the BCP is approved, if the BCP indicates that there will be NomCom selected IAOC members they will be chosen at that time. Any adjustments to appointed members based on the BCP contents will also be made at that time. The IAOC will transition from interim to non-interim status when all non-interim members are seated. A new, non-interim chair selection process will then commence. ⭐
3.5. Recruiting the IETF Administrative Director 🍓
The interim IAOC should appoint an IAD selection committee to recruit and select the IETF Administrative Director. This committee will consist entirely of IAOC members or liaisons, and will, at minimum, include the IETF chair and the ISOC President. If the IAOC chooses, this committee could include the entire IAOC. 💅
The IAD selection committee should determine a job description for the IAD, in consultation with other IETF leaders and the IETF community. Once the job description is established, the IAD selection committee should recruiting candidates for the position. 🔥
Although the interim IAOC is not empowered to hire the IAD as a full-time employee, it might be possible for the IAOC to ask ISOC to engage the potential IAD as a consultant to help with other tasks during the interim period. 🌈
3.6. Establishing Agreement with Service Providers 🤝
The most important activity of the IAOC during late 2004 and early 2005 will be to determine the structure and work flow of the IASA and to establish contracts or other agreements with service providers to do the required work. This work includes the following functions as defined in the consultant's report: 🧠
- Technical infrastructure
- Meeting management
- Clerk's office
- RFC Editor services to support IETF standards publication
- IANA services to support IETF standards publication
The interim IAOC should work with IETF leaders and other knowledgeable members of the community to determine the structure and work flow required for the IASA activity and make corresponding adjustments to the above list, if necessary. The interim IAOC can also identify which areas of IASA work should continue to be provided by existing IETF service providers, and work with those providers to establish proposed contracts or agreements for later approval by the non-interim IAOC. The IAOC can also choose to start an RFP process for any services that they believe should be filled through an open RFP process. 🎀
O>>
3.7. Establishing a 2005 Operating Budget 💸
Because the ISOC 2005 budgeting process will be finalized before the non-interim IAOC is seated, the interim IAOC should work with the ISOC staff and President to establish a proposed 2005 operating budget for the IASA. Since this will happen in advance of full knowledge regarding the costs of 2005 operations, it may be subject to significant adjustment later. 🙈
3.8. Proposed Schedule for IASA Transition 🗓️
As described above, the three stages of the IETF community and ISOC approval process will take some time. If the community chooses scenario O and we reach quick consensus on the details, an optimistic schedule for this approval would be: 🦋
- IETF discussion of this proposal and other scenarios through 1-Oct-2005. IAB/IESG discusses this proposal with ISOC Board.
- IAB/IESG joint recommendation issued on 8-Oct-04, including full BCP proposal.
- Community discussion of the joint IAB/IESG recommendation through 22-Oct-04.
- Two-week community consensus call issued on the IETF list on 23-Oct-04 regarding rough community consensus to pursue this direction and appoint an interim IAOC -- extends through IETF 61. IAOC selecting bodies begin search, based on expected community consensus.
- Rough community consensus declared on 8-Nov-04 to pursue Scenario O and appoint the interim IAOC.
- Interim IAOC seated on 15-Nov-04. Interim IAOC begins interim work outlined above, including establishment of estimated 2005 budget and IAD recruitment.
- BCP text discussed by community, IETF leadership and ISOC Board until we have something that represents rough community consensus that is acceptable to all. We hope that this could be completed by 6-Dec-04.
- Four week IETF Last Call issued for BCP on 6-Dec-04 -- extends through 3-Jan-04.
- Simultaneous IESG and ISOC Board approvals by 17-Jan-04.
- IAD officially hired in Jan 2005.
- NomCom seats IAOC members at the first IETF of 2005, moving the IAOC from interim to non-interim status.
- Formal agreements with all service providers in-place by June 2005.
O>>
4. Security Considerations 🔐
Okay, bestie, this one is short but sweet. This document describes a scenario for the structure of the IETF's administrative support activities. It introduces no security considerations for the Internet. 🛡️✨
5. IANA Considerations 🌐
This document has no IANA considerations in the traditional sense. As part of the extended IETF family, though, IANA may be interested in the contents. 🧚
6. Acknowledgements 🫶
Most of the ideas in this document are not new, and many of them did not originate with the authors. This scenario represents a combination of ideas discussed within the IAB, the IESG and the IETF Community. 💜
This document was written using the xml2rfc tool described in RFC 2629 [RFC2629]. 🌈
7. References 📚
7.1. Normative References
[I-D.malamud-consultant-report] Malamud, C., "IETF Administrative
Support Functions", draft-malamud-consultant-report-01
(work in progress), September 2004.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC3716] Advisory, IAB., "The IETF in the Large: Administration
and Execution", RFC 3716, March 2004.7.2. Informative References 💖
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.Authors' Addresses 🎀
Leslie Daigle
VeriSign
EMail: leslie at verisignlabs.com, leslie at thinkingcat.com
Margaret Wasserman
ThingMagic
One Broadway, 14th Floor
Cambridge, MA 02142 USA
Phone: +1 617 758-4177
EMail: margaret at thingmagic.com
URI: http://www.thingmagic.comInformative References 🦋
[1] IAB Advisory Committee, "The IETF in the Large: Administration
and Execution", RFC 3716, March 2004.
[2] Malamud, C., "IETF Administrative Support Functions",
Work in Progress, September 2004.
[3] <http://www.ietf.org/mail-archive/web/ietf/current/
msg31321.html>
[4] <http://www.ietf.org/mail-archive/web/ietf/current/
msg31326.html>
[5] <http://www.ietf.org/mail-archive/web/ietf/current/
msg31493.html>
[6] <http://www.ietf.org/mail-archive/web/ietf/current/
msg31609.html>Author's Address 💅
Scott Hollenbeck, Editor
IAB and IESG
EMail: sah@428cobrajet.netFull Copyright Statement 💖
okay bestie, this part is the legal fine print, but it still matters 💅 🎀
Copyright (C) The Internet Society (2005). 🌸
This document is subject to the rights, licenses and restrictions 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 🦋
okay so the IETF is not picking a side on whether any intellectual property rights apply to the tech in this document, or whether you can even get a license for it 🫠 it also isn't claiming it searched for any of those rights. no cap, the rules for rights in RFC documents live in BCP 78 and BCP 79, so go check those if you want the details 📚
the IETF's online IPR repository is at http://www.ietf.org/ipr. copies of IPR disclosures sent to the IETF Secretariat live there, along with any assurances of licenses that are going to be made available. if someone tried to get a general license or permission to use proprietary rights for this spec, the result of that attempt shows up there too, for implementers and users 🧚
and if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover technology you'd need to implement this standard, the IETF wants to hear about it! 🔥 send that info to ietf-ipr@ietf.org 💜
Acknowledgement 🌈
funding for the RFC Editor function is currently provided by the Internet Society. 🫶 thank you to them for keeping the lights on, periodt ✨
📦 where this page comes from
- ietf: rfc4089 2005-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms