Network Working Group | J. Hall |
Internet-Draft | CDT |
Intended status: Informational | J. Livingood |
Expires: September 6, 2018 | Comcast |
March 05, 2018 |
Proposed Structure of the IETF Administrative Support Activity (IASA), Version 2.0 (for Discussion)
draft-hall-iasa2-struct-00
The IETF Administrative Support Activity (IASA) was originally established in 2005. In the intervening years, the needs of the IETF have evolved in ways that require changes to its administrative structure. The purpose of this document is to spur discussion by outlining some details of what an “IASA 2.0” arrangement could look like. The proposal is for the execution of the IETF’s administrative and fundraising tasks to be conducted by a new administrative organization (“IETFAdminOrg”). The IAOC would be eliminated, and its oversight and advising functions transferred to the IETFAdminOrg board and a new IETF Administrative Advisory Council, respectively.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The IETF Administrative Support Activity (IASA) was originally established in 2005 [RFC4071]. In the intervening years, the needs of the IETF have evolved in ways that require changes to its administrative structure. [I-D.haberman-iasa20dt-recs] discusses the challenges facing the current structure as well as several options for reorganizing the IETF’s administration under different legal structures. [ML-memo] further outlines the legal details of various options, including three options – an independent 501(c)(3) organization, a 501(c)(3) Type 1 supporting organization of ISOC, and an LLC that is a disregarded entity of ISOC – that would entail setting up a new organization to house the administration of the IETF. This document outlines one way that such an organization could be structured and describes how the organization could fit together with existing and new IETF community structures. In this document the new administrative organization is known as IETFAdminOrg.
The purpose of this document is to spur discussion by outlining some details of what an “IASA 2.0” arrangement could look like. Some of the details of the organizational structure are dependent on the choice of legal structure, but others are not. While community discussion of the legal structure continues, the point of this document is to get community input about organizational approaches to solving some of the challenges identified in [I-D.haberman-iasa20dt-recs]. Ultimately, if the IETF community decides to make changes to IASA, those changes will need to be documented in an update to or replacement of RFC 4071.
In brief, the proposal in this document is to transfer most of the responsibilities that RFC 4071 currently assigns to the IAD and ISOC to the newly created IETFAdminOrg. The IAOC would be eliminated, and its oversight and advising functions transferred to the IETFAdminOrg board and a new IETF Administrative Advisory Council (“the AC”), respectively. It would be the job of IETFAdminOrg to meet the administrative needs of the IETF. It would be the job of the AC to provide any advice that the IETFAdminOrg needs from an IETF community perspective. And it would be the job of the IETFAdminOrg board to ensure that IETFAdminOrg is meeting the needs of the IETF community.
Eliminating the IAOC means that there will need to be another way for trustees to be appointed for the IETF Trust. The details of how this is done are for further work.
The proposal in this document is depicted visually in [Diagrams] showing the IETF Trust and [Diagrams-no-trust] not showing the IETF Trust.
The document does not propose any changes to anything related to the oversight or steering of the standards process as currently conducted by the IESG and IAB, the appeal chain, the confirming bodies for existing IETF and IAB appointments, or the IRTF.
If the community decides to make changes to IASA along the lines sketched out in this document, normative changes to IETF processes will need to be documented in an RFC. Additional legal documents (e.g., articles of incorporation, bylaws, operating agreements) relating to the legal entity would provide the official, legal definitions of processes, roles, etc. Section 5 sketches some initial thoughts about transition; publishing a detailed transition plan would likely also be useful.
IETFAdminOrg would be established to provide administrative support to the IETF. It would have no authority over standards development activities.
The proposed responsibilities of the IETFAdminOrg are listed below. Whether these responsibilities would be carried out by staff, contractors, community volunteers, or a mix would be at the discretion of the Executive Director and his or her staff (see Section 3.3). The responsibilities are:
Housing these responsibilities at IETFAdminOrg is designed to address the problems described in Sections 3.1.1., 3.1.2, and 3.1.3 of [I-D.haberman-iasa20dt-recs] concerning lack of clarity around responsibility, representation, and authority. By having IETFAdminOrg manage the IETF’s finances and conduct the IETF’s fundraising, confusion about who is responsible for representing the IETF to sponsors and who directs the uses of sponsorship funds could be reduced or eliminated. Having IETFAdminOrg reside in a legal entity and take responsibility for operations would allow the org to execute its own contracts without the need for further approvals from ISOC.
The IETFAdminOrg would be expected to conduct its work according to the following principles:
The transparency and responsiveness principles are designed to address the concern outlined in Section 3.3 of [I-D.haberman-iasa20dt-recs] about the need for improved timeliness of sharing of information and decisions and seeking community comments. There is a need for agreement between the IETF community and the IETFAdminOrg about the where to draw the line between community’s need for information and the need to keep some business and personnel data confidential. The devil here is in the details and it would be expected that one of the first tasks for the IETFAdminOrg Executive Director would be to document how IETFAdminOrg would engage with the community and to vet that proposal with the community.
The IETFAdminOrg board would be responsible for conducting oversight of IETFAdminOrg’s execution of its responsibilities, as described in Section 3.1. This responsibility entails a number of concrete functions analogous to those currently preformed by the IAOC:
The board would be purely an oversight body. Its responsibilities would be limited to those listed above. It would not conduct any of the IETF’s administrative work.
The role of the IETFAdminOrg board would be to ensure that the strategic orientation of IETFAdminOrg is consistent with the IETF’s needs – both its concrete needs and its needs for transparency and accountability. The board is not intended to represent the IETF community in defining the IETF’s needs; to the extent that is required, the IETF community should document its needs in consensus RFCs (e.g., as the community is aiming to do in [I-D.ietf-mtgvenue-iaoc-venue-selection-process]) and provide more detailed input via the Advisory Council.
The description below outlines one way in which the board of IETFAdminOrg could be populated. The specific details are less important than the goals motivating this particular formulation, discussed below. Depending on the legal structure of IETFAdminOrg, some or all board seats may need to be appointments made formally by ISOC [ML-memo], however it may be possible to encourage or require ISOC to appoint people on the basis of recommendations from the IETF by establishing an operational agreement between IETFAdminOrg and ISOC. Thus the details of any proposed board structure may be refined depending on the legal structure that is chosen; the proposal below could just as easily be a framework for having the IETF recommend board members as it could be for having the IETF actually appoint them.
The proposed structure of the board of IETFAdminOrg consists of five people:
The goal of this structure is to balance the need for IETFAdminOrg to be accountable to the IETF community with the need for this board to have the expertise necessary to oversee a small corporation. The first three seats listed above are all selected by the IETF community, via NOMCOM and the IAB. The two board-selected seats are there so that the board can bring in members with specific experience or skills in non-profit management and finance needed to complement the IETF-selected members.
The board is smaller than the current IAOC and the other leadership bodies of the IETF. Part of the motivation for keeping the board small is to keep the board focused on its rather limited set of tasks.
This board structure, together with the staffing proposal below, is designed to overcome the challenges described in Section 3.1.4 of [I-D.haberman-iasa20dt-recs] concerning oversight. It establishes a clear line of oversight over staff performance: the board oversees the Executive Director’s performance and has actual legal authority to remove a non-performing Executive Director. The Executive Director is responsible for the performance of the IETFAdminOrg.
Finally, the board would be expected to operate transparently, to further address the concern raised in Section 3.3 of [I-D.haberman-iasa20dt-recs]. As with the IETFAdminOrg, the board would need to establish up front how it would fulfill this commitment and how and when it would inform the IETF community about its actions. These commitments and procedures embodying them could be encoded in the board’s governing documents (e.g., bylaws).
Note also that the board formation rules of IETFAdminOrg would be defined in its corporate documents, e.g., its articles of incorporation and bylaws.
On a small board, board member term lengths and appointment cycles need some careful thought to ensure some continuity on the board and to account for external term limits and appointment cycles of the IETF Chair and the ISOC trustees. One way to arrange this would be to have the IETF Nomcom-appointed member’s term be two years and shifted a year from IETF Chair’s term. Setting the term for the ISOC trustees-selected member to two years would provide some additional continuity. The two members appointed by the board itself should have terms that do not both end at the same time.
IETFAdminOrg would be led by an Executive Director chosen by the board. The Executive Director would determine what other staff and contractors are required by IETFAdminOrg. Allowing for the division of responsibilities among multiple staff members and contractors should hopefully address some of the concerns raised in Section 3.2 (Lack of Resources) and Section 3.4 (Funding/Operating Model Mismatch and Rising Costs) of [I-D.haberman-iasa20dt-recs].
Based on the amount of work currently undertaken by the IAD and others involved in the IETF administration who are not currently in contracted roles, it is anticipated that the Executive Director would hire multiple additional staff members. For example, there will likely be a need for dedicated staff to manage fundraising, to manage the various contractors that are engaged to fulfill the IETF’s administrative needs, and to support outreach and communications.
The IETF currently benefits from the use of contractors for accounting, finance, meeting planning, administrative assistance, legal counsel, tools, and web site support, as well as other services related to the standards process (RFC Editor and IANA). The IETF budget currently reflects specific support from ISOC for communications and fundraising as well as some general support for accounting, finance, legal, and other services. The division of responsibilities between staff and contractors would be at the discretion of the Executive Director and his or her staff.
The IETF has a long history of community involvement in the execution of certain administrative functions, in particular development of IETF tools, the NOC’s operation of the meeting network, and some outreach and communications activities conducted by the EDU and Mentoring Directorate. The IETFAdminOrg staff would be expected to respect the IETF community’s wishes about community involvement in these and other functions going forward as long as the staff feels that they can meet the otherwise-stated needs of the community. Establishing the framework to allow the IETFAdminOrg to staff each administrative function as appropriate may require the IETF community to document its consensus expectations in areas where no documentation currently exists (see Section 5).
The AC is proposed to advise the staff of IETFAdminOrg about how their work can best support the IETF. If the staff and contractors find it desirable, the AC may also advise the contractors.
The AC is conceptualized as a body of IETF community members who can serve as a sounding board in situations where the IETFAdminOrg staff or contractors need to gauge community opinion or have questions about how administrative decisions might be viewed by the IETF community. For major administrative decisions, the IETFAdminOrg could be required to consult with the AC to gauge community opinion prior to deciding. Major administrative decisions might include the selection of a meeting venue or the award of a contract in excess of a certain fraction of the annual IETF budget.
The AC would not have decisional authority, but the process for the IETFAdminOrg to engage the AC would be documented, and the IETFAdminOrg would be expected to inform the community about how AC input was incorporated into its decision-making. A requirement to provide this kind of information could be included in the IETFAdminOrg bylaws. The oversight responsibilities of the IETFAdminOrg board would include ensuring that the IETFAdminOrg was complying with documented processes, and generally maintaining an appropriate level of engagement with the AC and the broader community.
For other more minor administrative decisions, there would be no requirement that the staff consult the AC about any particular decision, but there would be the expectation that the staff could consult the AC whenever they felt it necessary.
The virtue of the AC would be that for matters where the staff feels confident that they understand the community’s desires and direction, they could execute their tasks without additional delays or approvals. For matters where they are unsure, they could seek opinions from the AC before proceeding. And for major decisions there would be a well-defined process for the IETFAdminOrg to understand a community perspective. The AC could also provide advice about situations where bringing a proposal or decision to the full IETF community for discussion would be warranted. It would be the staff’s responsibility to bring those proposals to the community and manage those discussions, however.
(TODO - How is it formed? And how to deal with the likely need for the AC to review confidential information?)
Conducting a transition as envisioned in this document would encompass many different aspects and would require action from the IETF community, the IAOC, the IAD, ISOC, the newly hired IETFAdminOrg Executive Director and staff, and newly appointed IETFAdminOrg board members. This document sketches some thoughts on the subset of tasks that would entail some IETF community involvement or review (as opposed to, say, the transfer of administrative assets).
There are a number of tasks under this proposal that would require an initial bootstrap:
Once the Executive Director and any additional staff are hired, it would be expected for IETFAdminOrg to:
At the same time, there may be areas where the IETF community needs to document its consensus, e.g., expectations about community involvement in NOC or tools efforts.
(TODO: Document how to unwind the existing structures.)
Thanks to Jari Arkko, Richard Barnes, Alissa Cooper, Brian Haberman, and Sean Turner for discussions of possible structures, and to the attorneys of Morgan Lewis for their advice on possible legal impacts.
[RFC4071] | Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005. |
[Diagrams] | Barnes, R., "IASA 2.0 Strawman Diagram", n.d.. |
[Diagrams-no-trust] | Barnes, R., "IASA 2.0 Strawman Diagram, IETF Trust Not Shown", n.d.. |
[I-D.haberman-iasa20dt-recs] | Haberman, B., Arkko, J., Daigle, L., Livingood, J., Hall, J. and E. Rescorla, "IASA 2.0 Design Team Recommendations", Internet-Draft draft-haberman-iasa20dt-recs-01, October 2017. |
[I-D.ietf-mtgvenue-iaoc-venue-selection-process] | Lear, E., "IETF Plenary Meeting Venue Selection Process", Internet-Draft draft-ietf-mtgvenue-iaoc-venue-selection-process-12, February 2018. |
[ML-memo] | Morgan Lewis, "Options for New Organization to Conduct IETF Administrative Support Activities", February 2018. |