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