idnits 2.17.1 draft-hall-iasa2-struct-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 05, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) == Outdated reference: A later version (-03) exists of draft-haberman-iasa20dt-recs-01 == Outdated reference: A later version (-16) exists of draft-ietf-mtgvenue-iaoc-venue-selection-process-12 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hall 3 Internet-Draft CDT 4 Intended status: Informational J. Livingood 5 Expires: September 6, 2018 Comcast 6 March 05, 2018 8 Proposed Structure of the IETF Administrative Support Activity (IASA), 9 Version 2.0 (for Discussion) 10 draft-hall-iasa2-struct-00 12 Abstract 14 The IETF Administrative Support Activity (IASA) was originally 15 established in 2005. In the intervening years, the needs of the IETF 16 have evolved in ways that require changes to its administrative 17 structure. The purpose of this document is to spur discussion by 18 outlining some details of what an "IASA 2.0" arrangement could look 19 like. The proposal is for the execution of the IETF's administrative 20 and fundraising tasks to be conducted by a new administrative 21 organization ("IETFAdminOrg"). The IAOC would be eliminated, and its 22 oversight and advising functions transferred to the IETFAdminOrg 23 board and a new IETF Administrative Advisory Council, respectively. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 6, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Differences from IASA 1.0 . . . . . . . . . . . . . . . . . . 3 61 3. IETFAdminOrg . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Responsibilities . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Board Formation and Responsibilities . . . . . . . . . . 5 64 3.3. Staffing . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4. IETF Administrative Advisory Council (AC) . . . . . . . . . . 8 66 5. Transition Considerations . . . . . . . . . . . . . . . . . . 9 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 7.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 The IETF Administrative Support Activity (IASA) was originally 76 established in 2005 [RFC4071]. In the intervening years, the needs 77 of the IETF have evolved in ways that require changes to its 78 administrative structure. [I-D.haberman-iasa20dt-recs] discusses the 79 challenges facing the current structure as well as several options 80 for reorganizing the IETF's administration under different legal 81 structures. [ML-memo] further outlines the legal details of various 82 options, including three options - an independent 501(c)(3) 83 organization, a 501(c)(3) Type 1 supporting organization of ISOC, and 84 an LLC that is a disregarded entity of ISOC - that would entail 85 setting up a new organization to house the administration of the 86 IETF. This document outlines one way that such an organization could 87 be structured and describes how the organization could fit together 88 with existing and new IETF community structures. In this document 89 the new administrative organization is known as IETFAdminOrg. 91 The purpose of this document is to spur discussion by outlining some 92 details of what an "IASA 2.0" arrangement could look like. Some of 93 the details of the organizational structure are dependent on the 94 choice of legal structure, but others are not. While community 95 discussion of the legal structure continues, the point of this 96 document is to get community input about organizational approaches to 97 solving some of the challenges identified in 98 [I-D.haberman-iasa20dt-recs]. Ultimately, if the IETF community 99 decides to make changes to IASA, those changes will need to be 100 documented in an update to or replacement of RFC 4071. 102 In brief, the proposal in this document is to transfer most of the 103 responsibilities that RFC 4071 currently assigns to the IAD and ISOC 104 to the newly created IETFAdminOrg. The IAOC would be eliminated, and 105 its oversight and advising functions transferred to the IETFAdminOrg 106 board and a new IETF Administrative Advisory Council ("the AC"), 107 respectively. It would be the job of IETFAdminOrg to meet the 108 administrative needs of the IETF. It would be the job of the AC to 109 provide any advice that the IETFAdminOrg needs from an IETF community 110 perspective. And it would be the job of the IETFAdminOrg board to 111 ensure that IETFAdminOrg is meeting the needs of the IETF community. 113 Eliminating the IAOC means that there will need to be another way for 114 trustees to be appointed for the IETF Trust. The details of how this 115 is done are for further work. 117 The proposal in this document is depicted visually in [Diagrams] 118 showing the IETF Trust and [Diagrams-no-trust] not showing the IETF 119 Trust. 121 The document does not propose any changes to anything related to the 122 oversight or steering of the standards process as currently conducted 123 by the IESG and IAB, the appeal chain, the confirming bodies for 124 existing IETF and IAB appointments, or the IRTF. 126 If the community decides to make changes to IASA along the lines 127 sketched out in this document, normative changes to IETF processes 128 will need to be documented in an RFC. Additional legal documents 129 (e.g., articles of incorporation, bylaws, operating agreements) 130 relating to the legal entity would provide the official, legal 131 definitions of processes, roles, etc. Section 5 sketches some 132 initial thoughts about transition; publishing a detailed transition 133 plan would likely also be useful. 135 2. Differences from IASA 1.0 137 o The IAOC and IAD roles defined in RFC 4071 would be eliminated. 139 o The ISOC and IAD responsibilities described in RFC 4071 would be 140 assigned to a new organization, "IETFAdminOrg." The legal 141 structure of this entity is to be determined. 143 o The corporate board of IETFAdminOrg would assume the oversight 144 responsibilities of the IAOC. 146 o A new IETF Administrative Advisory Council ("the AC") would be 147 established, which would assume the advisory responsibilities of 148 the IAOC. 150 3. IETFAdminOrg 152 3.1. Responsibilities 154 IETFAdminOrg would be established to provide administrative support 155 to the IETF. It would have no authority over standards development 156 activities. 158 The proposed responsibilities of the IETFAdminOrg are listed below. 159 Whether these responsibilities would be carried out by staff, 160 contractors, community volunteers, or a mix would be at the 161 discretion of the Executive Director and his or her staff (see 162 Section 3.3). The responsibilities are: 164 o Operations. The IETFAdminOrg is responsible for supporting the 165 ongoing operations of the IETF, including meetings and non-meeting 166 activities. 168 o Finances. The IETFAdminOrg is responsible for managing the IETF's 169 finances and budget. 171 o Fundraising. The IETFAdminOrg is responsible for raising money on 172 behalf of the IETF. 174 Housing these responsibilities at IETFAdminOrg is designed to address 175 the problems described in Sections 3.1.1., 3.1.2, and 3.1.3 of 176 [I-D.haberman-iasa20dt-recs] concerning lack of clarity around 177 responsibility, representation, and authority. By having 178 IETFAdminOrg manage the IETF's finances and conduct the IETF's 179 fundraising, confusion about who is responsible for representing the 180 IETF to sponsors and who directs the uses of sponsorship funds could 181 be reduced or eliminated. Having IETFAdminOrg reside in a legal 182 entity and take responsibility for operations would allow the org to 183 execute its own contracts without the need for further approvals from 184 ISOC. 186 The IETFAdminOrg would be expected to conduct its work according to 187 the following principles: 189 o Transparency. The IETFAdminOrg would be expected to keep the IETF 190 community informed about its work and to engage the community and/ 191 or the AC, as appropriate, to obtain community input. 193 o Responsiveness to the community. The IETFAdminOrg would be 194 expected to act consistently with the documented consensus of the 195 IETF community, to be responsive to the community's needs, and to 196 adapt its decisions in response to community feedback. 198 o Diligence. The IETFAdminOrg would be expected to act responsibly 199 so as to minimize risks to IETF participants and to the future of 200 the IETF as a whole. 202 The transparency and responsiveness principles are designed to 203 address the concern outlined in Section 3.3 of 204 [I-D.haberman-iasa20dt-recs] about the need for improved timeliness 205 of sharing of information and decisions and seeking community 206 comments. There is a need for agreement between the IETF community 207 and the IETFAdminOrg about the where to draw the line between 208 community's need for information and the need to keep some business 209 and personnel data confidential. The devil here is in the details 210 and it would be expected that one of the first tasks for the 211 IETFAdminOrg Executive Director would be to document how IETFAdminOrg 212 would engage with the community and to vet that proposal with the 213 community. 215 3.2. Board Formation and Responsibilities 217 The IETFAdminOrg board would be responsible for conducting oversight 218 of IETFAdminOrg's execution of its responsibilities, as described in 219 Section 3.1. This responsibility entails a number of concrete 220 functions analogous to those currently preformed by the IAOC: 222 o To hire, fire, and review the performance of the Executive 223 Director of IETFAdminOrg. 225 o To provide high-level direction for the Executive Director's work. 227 o To ensure that IETFAdminOrg has the financial and business 228 stability that it needs to be able to meet the needs of the IETF, 229 including approving an annual budget proposed by the Executive 230 Director. 232 o To ensure that IETFAdminOrg is run in a manner that is transparent 233 and accountable to the IETF community. 235 The board would be purely an oversight body. Its responsibilities 236 would be limited to those listed above. It would not conduct any of 237 the IETF's administrative work. 239 The role of the IETFAdminOrg board would be to ensure that the 240 strategic orientation of IETFAdminOrg is consistent with the IETF's 241 needs - both its concrete needs and its needs for transparency and 242 accountability. The board is not intended to represent the IETF 243 community in defining the IETF's needs; to the extent that is 244 required, the IETF community should document its needs in consensus 245 RFCs (e.g., as the community is aiming to do in 246 [I-D.ietf-mtgvenue-iaoc-venue-selection-process]) and provide more 247 detailed input via the Advisory Council. 249 The description below outlines one way in which the board of 250 IETFAdminOrg could be populated. The specific details are less 251 important than the goals motivating this particular formulation, 252 discussed below. Depending on the legal structure of IETFAdminOrg, 253 some or all board seats may need to be appointments made formally by 254 ISOC [ML-memo], however it may be possible to encourage or require 255 ISOC to appoint people on the basis of recommendations from the IETF 256 by establishing an operational agreement between IETFAdminOrg and 257 ISOC. Thus the details of any proposed board structure may be 258 refined depending on the legal structure that is chosen; the proposal 259 below could just as easily be a framework for having the IETF 260 recommend board members as it could be for having the IETF actually 261 appoint them. 263 The proposed structure of the board of IETFAdminOrg consists of five 264 people: 266 o The IETF Chair 268 o One member selected by the IETF NOMCOM 270 o One member selected by the ISOC board of trustees from among the 271 ISOC trustees appointed by the IAB 273 o Two members selected by the board itself 275 The goal of this structure is to balance the need for IETFAdminOrg to 276 be accountable to the IETF community with the need for this board to 277 have the expertise necessary to oversee a small corporation. The 278 first three seats listed above are all selected by the IETF 279 community, via NOMCOM and the IAB. The two board-selected seats are 280 there so that the board can bring in members with specific experience 281 or skills in non-profit management and finance needed to complement 282 the IETF-selected members. 284 The board is smaller than the current IAOC and the other leadership 285 bodies of the IETF. Part of the motivation for keeping the board 286 small is to keep the board focused on its rather limited set of 287 tasks. 289 This board structure, together with the staffing proposal below, is 290 designed to overcome the challenges described in Section 3.1.4 of 291 [I-D.haberman-iasa20dt-recs] concerning oversight. It establishes a 292 clear line of oversight over staff performance: the board oversees 293 the Executive Director's performance and has actual legal authority 294 to remove a non-performing Executive Director. The Executive 295 Director is responsible for the performance of the IETFAdminOrg. 297 Finally, the board would be expected to operate transparently, to 298 further address the concern raised in Section 3.3 of 299 [I-D.haberman-iasa20dt-recs]. As with the IETFAdminOrg, the board 300 would need to establish up front how it would fulfill this commitment 301 and how and when it would inform the IETF community about its 302 actions. These commitments and procedures embodying them could be 303 encoded in the board's governing documents (e.g., bylaws). 305 Note also that the board formation rules of IETFAdminOrg would be 306 defined in its corporate documents, e.g., its articles of 307 incorporation and bylaws. 309 On a small board, board member term lengths and appointment cycles 310 need some careful thought to ensure some continuity on the board and 311 to account for external term limits and appointment cycles of the 312 IETF Chair and the ISOC trustees. One way to arrange this would be 313 to have the IETF Nomcom-appointed member's term be two years and 314 shifted a year from IETF Chair's term. Setting the term for the ISOC 315 trustees-selected member to two years would provide some additional 316 continuity. The two members appointed by the board itself should 317 have terms that do not both end at the same time. 319 3.3. Staffing 321 IETFAdminOrg would be led by an Executive Director chosen by the 322 board. The Executive Director would determine what other staff and 323 contractors are required by IETFAdminOrg. Allowing for the division 324 of responsibilities among multiple staff members and contractors 325 should hopefully address some of the concerns raised in Section 3.2 326 (Lack of Resources) and Section 3.4 (Funding/Operating Model Mismatch 327 and Rising Costs) of [I-D.haberman-iasa20dt-recs]. 329 Based on the amount of work currently undertaken by the IAD and 330 others involved in the IETF administration who are not currently in 331 contracted roles, it is anticipated that the Executive Director would 332 hire multiple additional staff members. For example, there will 333 likely be a need for dedicated staff to manage fundraising, to manage 334 the various contractors that are engaged to fulfill the IETF's 335 administrative needs, and to support outreach and communications. 337 The IETF currently benefits from the use of contractors for 338 accounting, finance, meeting planning, administrative assistance, 339 legal counsel, tools, and web site support, as well as other services 340 related to the standards process (RFC Editor and IANA). The IETF 341 budget currently reflects specific support from ISOC for 342 communications and fundraising as well as some general support for 343 accounting, finance, legal, and other services. The division of 344 responsibilities between staff and contractors would be at the 345 discretion of the Executive Director and his or her staff. 347 The IETF has a long history of community involvement in the execution 348 of certain administrative functions, in particular development of 349 IETF tools, the NOC's operation of the meeting network, and some 350 outreach and communications activities conducted by the EDU and 351 Mentoring Directorate. The IETFAdminOrg staff would be expected to 352 respect the IETF community's wishes about community involvement in 353 these and other functions going forward as long as the staff feels 354 that they can meet the otherwise-stated needs of the community. 355 Establishing the framework to allow the IETFAdminOrg to staff each 356 administrative function as appropriate may require the IETF community 357 to document its consensus expectations in areas where no 358 documentation currently exists (see Section 5). 360 4. IETF Administrative Advisory Council (AC) 362 The AC is proposed to advise the staff of IETFAdminOrg about how 363 their work can best support the IETF. If the staff and contractors 364 find it desirable, the AC may also advise the contractors. 366 The AC is conceptualized as a body of IETF community members who can 367 serve as a sounding board in situations where the IETFAdminOrg staff 368 or contractors need to gauge community opinion or have questions 369 about how administrative decisions might be viewed by the IETF 370 community. For major administrative decisions, the IETFAdminOrg 371 could be required to consult with the AC to gauge community opinion 372 prior to deciding. Major administrative decisions might include the 373 selection of a meeting venue or the award of a contract in excess of 374 a certain fraction of the annual IETF budget. 376 The AC would not have decisional authority, but the process for the 377 IETFAdminOrg to engage the AC would be documented, and the 378 IETFAdminOrg would be expected to inform the community about how AC 379 input was incorporated into its decision-making. A requirement to 380 provide this kind of information could be included in the 381 IETFAdminOrg bylaws. The oversight responsibilities of the 382 IETFAdminOrg board would include ensuring that the IETFAdminOrg was 383 complying with documented processes, and generally maintaining an 384 appropriate level of engagement with the AC and the broader 385 community. 387 For other more minor administrative decisions, there would be no 388 requirement that the staff consult the AC about any particular 389 decision, but there would be the expectation that the staff could 390 consult the AC whenever they felt it necessary. 392 The virtue of the AC would be that for matters where the staff feels 393 confident that they understand the community's desires and direction, 394 they could execute their tasks without additional delays or 395 approvals. For matters where they are unsure, they could seek 396 opinions from the AC before proceeding. And for major decisions 397 there would be a well-defined process for the IETFAdminOrg to 398 understand a community perspective. The AC could also provide advice 399 about situations where bringing a proposal or decision to the full 400 IETF community for discussion would be warranted. It would be the 401 staff's responsibility to bring those proposals to the community and 402 manage those discussions, however. 404 (TODO - How is it formed? And how to deal with the likely need for 405 the AC to review confidential information?) 407 5. Transition Considerations 409 Conducting a transition as envisioned in this document would 410 encompass many different aspects and would require action from the 411 IETF community, the IAOC, the IAD, ISOC, the newly hired IETFAdminOrg 412 Executive Director and staff, and newly appointed IETFAdminOrg board 413 members. This document sketches some thoughts on the subset of tasks 414 that would entail some IETF community involvement or review (as 415 opposed to, say, the transfer of administrative assets). 417 There are a number of tasks under this proposal that would require an 418 initial bootstrap: 420 o Defining the articles of incorporation and the bylaws of 421 IETFAdminOrg, including provisions about how those documents may 422 be amended in the future. 424 o Populating the IETFAdminOrg board. The initial board for an 425 organization is usually specified in its founding documents (e.g., 426 articles of incorporation), along with a mechanism for replacing 427 the initial board. The current IETF Chair can be included in this 428 initial set, and the NOMCOM-appointed and ISOC-board-appointed 429 members can be seated as the appointing bodies are able. It 430 remains to determine how to select the initial board-selected 431 members. 433 o Hiring the Executive Director. This would presumably be 434 undertaken by the IETFAdminOrg board once its membership is 435 sufficiently well established. 437 o Defining the operating procedures and administrative support for 438 the board. The board would need to have processes defined for 439 selecting a chair and conducting its work. The board would also 440 need to define how it would fulfill its transparency obligations 441 to the community. 443 o Defining the operating procedures and administrative support for 444 the AC. The AC would need to have processes defined for selecting 445 a chair and engaging with the IETFAdminOrg. 447 Once the Executive Director and any additional staff are hired, it 448 would be expected for IETFAdminOrg to: 450 o Document how it will fulfill its commitment to transparency and 451 how it will engage with the IETF community. 453 o Do a thorough review of existing contracts, community volunteer 454 arrangements, and administrative assets to determine the need for 455 initial changes. 457 At the same time, there may be areas where the IETF community needs 458 to document its consensus, e.g., expectations about community 459 involvement in NOC or tools efforts. 461 (TODO: Document how to unwind the existing structures.) 463 6. Acknowledgments 465 Thanks to Jari Arkko, Richard Barnes, Alissa Cooper, Brian Haberman, 466 and Sean Turner for discussions of possible structures, and to the 467 attorneys of Morgan Lewis for their advice on possible legal impacts. 469 7. References 471 7.1. Normative References 473 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 474 IETF Administrative Support Activity (IASA)", BCP 101, 475 RFC 4071, DOI 10.17487/RFC4071, April 2005, 476 . 478 7.2. Informative References 480 [Diagrams] 481 Barnes, R., "IASA 2.0 Strawman Diagram", n.d., 482 . 484 [Diagrams-no-trust] 485 Barnes, R., "IASA 2.0 Strawman Diagram, IETF Trust Not 486 Shown", n.d., 487 . 489 [I-D.haberman-iasa20dt-recs] 490 Haberman, B., Arkko, J., Daigle, L., Livingood, J., Hall, 491 J., and E. Rescorla, "IASA 2.0 Design Team 492 Recommendations", draft-haberman-iasa20dt-recs-01 (work in 493 progress), October 2017. 495 [I-D.ietf-mtgvenue-iaoc-venue-selection-process] 496 Lear, E., "IETF Plenary Meeting Venue Selection Process", 497 draft-ietf-mtgvenue-iaoc-venue-selection-process-12 (work 498 in progress), February 2018. 500 [ML-memo] Morgan Lewis, "Options for New Organization to Conduct 501 IETF Administrative Support Activities", February 2018, 502 . 505 Authors' Addresses 507 Joseph Lorenzo Hall 508 CDT 510 Email: joe@cdt.org 512 Jason Livingood 513 Comcast 515 Email: Jason_Livingood@comcast.com