idnits 2.17.1 draft-hall-iasa20-workshops-report-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-daigle-iasa-retrospective-00 -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 A. Mahoney 5 Expires: September 14, 2017 March 13, 2017 7 Report from the IASA 2.0 Virtual Workshops 8 draft-hall-iasa20-workshops-report-00 10 Abstract 12 This is the Workshop Report for the IETF Administrative Support 13 Activity 2.0 (IASA 2.0) Virtual Workshops, held on 28 February 2017 14 at 1100 UT and 1600 UT. The original IETF Administrative Support 15 Activity (IASA) was created ten years ago, and since has been subject 16 to some reflection. In the intervening years, there has been 17 considerable change in the necessary tasks of IETF administration and 18 in the world around the IETF, and in how the IETF raises funds and 19 finances its work. The IASA 2.0 process seeks to address which 20 administrative arrangements will best support the IETF going forward. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 14, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology and Organizational Structure . . . . . . . . . . 3 58 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Organizational Structure . . . . . . . . . . . . . . . . 3 60 3. Issues Raised . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Structural and Organizational Issues . . . . . . . . . . 4 62 3.2. Funding Issues . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Transparency and Communication Issues . . . . . . . . . . 9 64 3.4. Staff and Volunteer Resource Issues . . . . . . . . . . . 10 65 3.5. Internal IAOC Organizational Issues . . . . . . . . . . . 11 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 69 7. Informative References . . . . . . . . . . . . . . . . . . . 14 70 Appendix A. Participants . . . . . . . . . . . . . . . . . . . . 15 71 A.1. Participants in the 1100 UTC virtual workshop . . . . . . 15 72 A.2. Participants in the 1600 UTC virtual workshop . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 75 1. Introduction 77 The IETF Administrative Support Activity (IASA) arrangements were 78 created more than ten years ago, when the IETF initially took charge 79 of its own administration [RFC4071]. In the intervening years, there 80 has been considerable change in the tasks of IETF administration and 81 in the world around the IETF [I-D.daigle-iasa-retrospective] and in 82 how the IETF raises funds and finances its work 83 [I-D.arkko-ietf-finance-thoughts]. 85 In 2016, IETF leadership began a discussion to review and possibly 86 rework administrative arrangements at the IETF, dubbed the IETF 87 Administrative Support Activity 2.0 project [Arkko-2016]. The IASA 88 2.0 process seeks to address what administrative arrangements that 89 will best support the IETF going forward. 91 To make changes, the IETF community first needs to understand the 92 challenges and/or missed opportunities within the current system. A 93 number of areas face challenges: structural and organizational issues 94 regarding the roles and interfaces between the IETF, the IAOC, ISOC, 95 the IESG, and contractors; the IETF funding model; transparency and 96 communication issues among the many IASA moving pieces; availability 97 of staff, contractor, and volunteer resources compared to the 98 administrative workload; and internal IAOC organizational issues. 100 To get input from the community to identify challenges and 101 opportunities in these and other areas, the IETF leadership set up 102 two virtual workshops open to everyone in the IETF community and to 103 people who are or have worked in IETF-administrative roles. These 104 virtual workshops were held on 28 February 2017 at 11:00 UTC and 105 16:00 UTC. The agenda, slides, and minutes from the two meetings are 106 available at the workshop proceedings [IASA20-proceedings]. 107 Recordings of the two workshops are also available 108 [IASA20-1100UT-rec] [IASA20-1600UT-rec]. 110 At these workshops, the participants provided their experiences and 111 suggestions. Proposed changes and solutions will be discussed and 112 dealt with in a later phase of the IASA 2.0 project. 114 2. Terminology and Organizational Structure 116 2.1. Terminology 118 The following acronyms will be heavily used in the discussion below: 120 o IASA - IETF Administrative Support Activity - An organized 121 activity that provides administrative support for the IETF, the 122 IAB and the IESG. 124 o IAOC - IETF Administrative Oversight Committee - A largely IETF- 125 selected committee that oversees and directs IASA. Accountable to 126 the IETF community. 128 o ISOC - The Internet Society - An organization that assists the 129 IETF with legal, administrative, and funding tasks. 131 o IAD - IETF Administrative Director - The sole staff member 132 responsible for carrying out the work of the IASA. An ISOC 133 employee. 135 o IETF Trust - Acquires, maintains, and licenses intellectual and 136 other property used in connection with the administration of the 137 IETF. Same composition as IAOC. 139 2.2. Organizational Structure 141 In terms of organizational arrangements, the workshop chairs provided 142 a diagram that captured many of the organizational relationships 143 among various entities [IASA-Org-Chart]. The IAOC relies on a number 144 of committees to get its work done - Finance, Legal Management, 145 Meetings, Technology Management, and RFP Committee in addition to any 146 ad hoc committees. Participants noted that the connections between 147 these committees and the IAD are not reflected in the diagram. 149 Some workshop participants felt that the diagram generally reflected 150 reality and that it illustrated the large number of moving pieces 151 involved. A workshop participant said that there are a lot of moving 152 parts compared to 11 years ago when the IASA was formed, as IASA now 153 encompasses certain functions that it did not at that time, such as 154 the Secretariat and the RFC Production Center. 156 3. Issues Raised 158 The IASA 2.0 Virtual Workshops focused on the areas below. 160 3.1. Structural and Organizational Issues 162 Slide 10 of the slide deck [IASA2-Workshop-Slides] discussed the 163 following structural issues between the IETF, the IAOC, ISOC, the 164 IESG, and contractors: 166 o The line between the IETF and ISOC is not organizationally clear- 167 cut, which has led to issues around transparency, allocation of 168 staff time and priorities, budgeting, and clarity of who is 169 responsible for what. 171 o The respective roles of ISOC, the IETF chair, the IAOC, and the 172 secretariat in representing the IETF to sponsors and donors and 173 communicating with them are not clear. 175 o Having ISOC represent the IETF to sponsors and donors - 177 * creates confusion about why the IETF does not represent itself, 179 * yields questions about why ISOC does not instead increase its 180 IETF support and how donations can be guaranteed to be 181 dedicated to the IETF, and 183 * can result in those soliciting sponsorships and donations 184 having a lack of familiarity with IETF work. 186 Workshop participants discussed organizational issues between ISOC 187 and IETF. For example, participants noted some items are branded 188 IETF, like the IETF Journal, are ISOC driven and funded, and are not 189 directed by the IETF community. One participant said it is often not 190 clear who is doing what on behalf of whom; a comment was made that 191 IASA 2.0 discussions should focus on what the _IETF_ is doing. Other 192 ISOC-funded activities include participation in the Ombudsteam - 193 which was requested by IETF and should show up in an accounting of 194 IETF resources - and ISOC Fellows and Policy Fellows - which are 195 ISOC-funded and controlled programs that should not show up in an 196 IETF budget. (The ISOC Fellows and Policy Fellows programs 197 encourage, respectively, technologists from emerging and developing 198 economies and policy experts from around the world to interact with 199 the IETF community.) A commentor mentioned that this sounded like a 200 branding issue at times: while the IETF Trust holds IETF trademarks, 201 is the IETF brand and the contours of what it encompasses clear? The 202 commentor further asked: who defines the contents of ISOC activities 203 that are visible to the outside world? Who decides how to drive 204 those things? Should those be included in the budget? 206 A related but distinct issue arose around control and policy 207 authority among the various IASA components. One workshop 208 participant said that the IETF community is confused about who has 209 policy authority. They continued: for example, if the IETF community 210 wants to change the structure of relationships with sponsors, who has 211 the authority to make that decision? IESG? IAOC? Community 212 consensus? This participant felt that this is unclear. A 213 participant said that there is a gap in terms of the IAOC being the 214 body that carries this out. How does the IAOC get its policy 215 instructions from the IETF community? The IAOC only goes to the 216 community for specific policy questions - e.g., the privacy policy or 217 changes to the trust legal provisions - but does not get general 218 "please do this" feedback from the community. A commentor stated: In 219 many cases the "policy from the IETF community" comes through the 220 IESG as voiced by the IETF chair. Another workshop participant felt 221 that there was a lack of clarity around even where some questions 222 should be asked (e.g. "how many logos do we want on our badges?" or 223 "who drives/has responsibility for some specific functions?"). That 224 commentor felt that an important question is whether or not the IETF 225 community wants a "thin" IAOC that has mostly oversight of the IAD or 226 a "thick" IAOC that has administrative responsibilities - i.e. "who 227 is driving the bus?" 229 In terms of accounting structure, the discussion at the virtual 230 workshop concluded that there have been improvements to accounting 231 that have helped increase accuracy, and the IETF budget has been 232 adjusted over the last 5 or 6 years to recognize ISOC staff 233 contributions, but appropriate accounting between ISOC and IETF needs 234 more work. One commentor said that it was not clear to them who is 235 in the driver's seat. One participant stated it as: "If we don't 236 like a function, can we delete it? Or does that require IETF 237 participation?" Some things are very clearly IETF topics, and then 238 there are some that fall in between IETF and ISOC, and then there are 239 some that are purely ISOC. A participant felt that control needs to 240 be aligned with accounting. 242 On the marketing side, workshop participants discussed how the IETF 243 is represented to the outside world - donors, media, other 244 organizations and communities - and some felt that it needs to be 245 clearer, even if this is currently an ISOC activity. One participant 246 said that people don't understand the difference between ISOC and 247 IETF and that we need to understand this before we can correctly 248 communicate it. 250 Some felt that the lack of rigid formality in the organization and 251 structure was not necessarily a bad thing. One commentor felt that 252 the structure of IETF, which is not well-defined and flexible, 253 provides a benefit to the Internet. Another commentor stated that 254 given the proclivities of engineers towards structure and formality, 255 working to improve IASA could make the IETF more structured and thus 256 less appealing to some kinds of contributors. Further, they stated 257 that we need clarity that institutionalizes this level accessibility 258 to all participants, which will be tricky. In contrast, another 259 participant felt that we do ourselves a disservice by this long- 260 standing confusion about whether IETF is an organization; they felt 261 that people within the community know what is meant by the IETF and 262 that more formality is not necessary. The point was made that any 263 changes to the organization of the IETF will have practical 264 implications, such as impacting legal transactions, which generally 265 go through ISOC. 267 3.2. Funding Issues 269 Slide 12 of the slide deck [IASA2-Workshop-Slides] discussed the 270 following issues related to the IETF funding model: 272 o Meeting fees are currently an important source of revenue, but 273 remote participation and other factors may be responsible for 274 declining in-person meeting attendance going forward. Even if 275 fees were charged for remote participation, charging the same for 276 remote and in-person attendance is unlikely to be a viable way to 277 make up the difference. 279 o While there has been a lot of sponsor support for, e.g., meeting 280 hosting, getting support for the full sponsorship program is not 281 easy. The value to sponsors is not always obvious, the IETF 282 community is sometimes critical or unappreciative, and the same 283 sponsors get tapped again and again for many related but different 284 opportunities. 286 o Relying heavily on meeting-based revenue is somewhat at odds with 287 the fact that much of the IETF's work takes place outside of in- 288 person meetings. 290 o The IETF is increasingly relying on professional services to 291 support its activities, causing expenses to grow. 293 Workshop participants discussed funding issues faced by the IETF, 294 including: increasing costs due to more tools, higher hotel fees, 295 etc.; relatively flat growth in funding; meeting fees that do not 296 cover operating expenses so that there is increased pressure on 297 sponsorship and increased ISOC contributions. These funding issues 298 are covered in [I-D.arkko-ietf-finance-thoughts]. 300 Some workshop participants commented on how the willingness of 301 sponsors to fund IETF is a useful measure of the IETF's relevance. 302 That is, they said, looking for sponsors is a good way to measure 303 support in the community. The commentor went on to say if 304 sponsorship starts to dry up, it may be a symptom of larger problems, 305 that the IETF is no longer relevant or at least becoming less 306 relevant. This participant felt that the IETF needs to ensure its 307 ongoing relevance and that the IETF needs to understand what it's 308 offering. One commentor stated that while it's valuable to stay in 309 touch with the engineers who understand how the Internet works, that 310 may not justify their attendance at three meetings a year. It was 311 felt that individual sponsors' goals and the goals of the IETF 312 community will never line up perfectly, but that fact doesn't take 313 away the need for clarity. 315 In terms of funding sources, participants commented that it is 316 generally good for the IETF to have multiple sources of funding on 317 which to stand. This participant further stated that diversity in 318 funding sources allows IETF to shift gears: IETF endowment can 319 provide longer-term stability; Long-term sponsorship, such as the 320 Global Host program ($100k per year for 10 years, also stated as the 321 best way to support the IETF as an organization); meetings can be 322 funded through fees (although registration fees are prohibitive for 323 many) and sponsorships. However, explaining the need for diversity 324 of funding is more complicated than it needs to be. One participant 325 felt that we probably need to find a simpler story. 327 Specifically, participants discussed a potential mismatch between the 328 IETF's activities and its funding model, which is mainly constituted 329 from meeting fees. Questions raised included: What is the right 330 proportion for meeting-based revenue? What are the alternative 331 methods to fund the non-meeting-based activities? Sponsorships? Do 332 we hire staff or contract to provide assistance? 334 While ISOC currently makes up any current budget shortfalls for IETF 335 (after meeting fee and sponsorship income), a participant commented 336 that the assumption that ISOC's primary purpose is to fund the IETF 337 is more strongly held in some corners than others. At the same time, 338 this commentor said that another school of thought believes that the 339 .org contract that funds ISOC requires ISOC to ensure the support of 340 the IETF, so is a core goal of ISOC. Another commentor said that 341 after consulting some of the people involved when the .org contract 342 was given to ISOC, the IETF was clearly only a part of the public 343 interest the .org contract mission sought to fulfill. Further, 344 another commentor noted, those in local ISOC chapters don't think 345 that IETF is a purpose of ISOC, let alone the main purpose. 347 In terms of the relative amounts of funding from sources, a commentor 348 mentioned that the level of funding that the IETF receives through 349 Global Hosts is much smaller compared to the sponsorship funding of 350 many large-scale open-source projects (e.g., $500K/year per sponsor), 351 and the IETF could be getting a lot more money through this source. 353 Further, in terms of sponsorship funding, a participant state that 354 it's not often a cut-and-dry proposition, requiring a larger, more 355 diffuse commitment than a sponsor may originally expect. For 356 example, this participant noted that meeting sponsors are also 357 responsible for extra work like printing T-shirts and staging social 358 events, and there is a lot of risk to a meeting sponsor if they get 359 anything wrong (presumably in terms of backlash from the community). 360 This aspect of logistics and event programming is an area of 361 expertise that few IETF participants have, so sponsors often have to 362 get their marketing departments involved, for example. A commentor 363 said, if sponsors could focus on just securing the money, where 364 someone else would worry about the logistics problems, that would 365 help. 367 There were also issues discussed with communication to potential 368 sponsors and funders what they are agreeing to. A workshop 369 participant felt that the IETF needs to be able to clearly state what 370 it is asking for, and what the relevance is for the potential 371 sponsor. One participant stated that it's unclear now who is 372 responsible for communicating these messages to funding sources, 373 Further this participant said that it's unclear how this outreach is 374 done and if it is done well, especially for large sponsors. One 375 commentor states that it seems like there are two types of 376 organizations the IETF is looking for - those involved in the 377 Internet ecosystem, and those interested in standards. This person 378 felt that honing outreach to both of those types of organizations 379 would be helpful. Another commentor stated that the same sponsors 380 are asked for support over and over again. This person further asked 381 about how new companies are sought out and developed for potential 382 support. One commentor noted that outreach appears to be split 383 between the various IASA parties. A commentor stated that when ISOC 384 is raising funds on behalf of the IETF, its relationship to the IETF 385 needs to be clearly communicated. 387 Participants offered up some perspective as current and past IETF 388 sponsors through their own organization. One participant noted that 389 they consider it unusual to fund the IETF through a third party 390 (ISOC). This can raise approval and audit questions inside the 391 sponsor company, and the sponsor is left guessing as to when the IETF 392 might receive the money they contribute. Finally, this participant 393 wondered if this indirect structure makes sense in the future or if 394 can be made direct. The structure also makes it difficult to 395 contribute to the IETF endowment for the same issues and because 396 there is no independent organization managing and reporting on the 397 IETF endowment. Thus, perhaps a different level of financial and 398 administrative separation from ISOC would be helpful for fundraising 399 in the future, both for supporting the IETF generally and for the 400 endowment. 402 Some commentors talked about what kinds of support were easier to 403 secure from their organizations. An IETF participant may be more 404 inclined to seek, and find it easier to gain, sponsorship for easily 405 communicated and defined activities, for example, the Systers Lunch. 406 For activities like these, commentors noted that IETF participants 407 may do a better job than staffers hired to solicit funding, and we 408 should distribute the solicitation work as best as we can. 410 3.3. Transparency and Communication Issues 412 Slide 9 of the slide deck [IASA2-Workshop-Slides] discussed the 413 following issues involving transparency and communication: 415 o IAOC has typically been perceived to operate less transparently 416 than what is the norm for IETF processes and other IETF leadership 417 bodies. 419 o Lack of transparency has some roots in concerns about 420 confidentiality of contract terms and business relationships, and 421 fear of community reaction to administrative decisions. 423 o Requirements from the community about IAOC transparency 424 expectations are not clear. 426 Some said that he IAOC and IASA could better communicate with the 427 IETF community. IASA has lagged progress of groups like the IESG, 428 who have made agendas and meetings open. Participants felt that the 429 IETF community should document the transparency requirement clearly, 430 e.g., set the default to be open, such as open meetings and 431 materials, and publish an exception list for confidential or 432 sensitive matters. Hotel contracts aren't shown due to 433 confidentiality agreements, and there have been some arguments about 434 that reducing transparency of meeting deals. One workshop 435 participant identified fear as a significant cause of lack of 436 transparency. A commentor offered two potential sources of fear: 437 making a decision that the IAOC knows the community won't like, and 438 having a situation where there is a Last Call and all of the previous 439 conversations the IAOC has had are rehashed. 441 With regards to IAOC communication to IETF, some said that we could 442 use a better understanding of what needs to improve and where it can 443 improve. A commentor felt that the IAOC could do better in telling 444 the community what it does and how it makes decisions. However, 445 another commentor noted, now that plenary time has been shortened, 446 the community doesn't get to see the IAOC, and this reduces the 447 opportunities for the community to understand what they do. This 448 commentor noted that participants have said that they don't want 449 exposure to the boring details at the plenaries - "which are boring 450 until they're not, and then everyone is surprised." Another 451 participant asked, how we encourage the IETF community to understand 452 the IAOC and role of the IASA to best reduce these poor outcomes? 453 One suggestion was for the IAOC to hold information sessions or 454 office hours at meetings, to allow people to raise concerns and ask 455 for guidance. This could help the community get to know the IAOC and 456 have people volunteer. Some felt that the IAOC needs to provide 457 insight into what the IAOC is going to do, as opposed to what it has 458 just done. This commentor felt that telegraphing for a few years may 459 improve the level of education. It could help with transparency 460 without running afoul of the confidentiality of contracts. Some felt 461 that a Last Call for some IAOC things is worthwhile, but other, more 462 mundane tasks don't need it. A participant mentioned that the IAOC 463 should document the basis for a decision, rather than the mere fact 464 of it. 466 3.4. Staff and Volunteer Resource Issues 468 Slide 8 of the slide deck [IASA2-Workshop-Slides] discussed the 469 following issues involving staff and volunteer resources: 471 o IAD workload is (much) more than a full-time job, but we have one 472 staff person allocated to it. 474 o IASA tasks touch on a wider variety of topics and require more 475 different kinds of expertise than 10 years ago (visa issues, local 476 social/political/health issues, new modes of fundraising, etc.), 477 but the job descriptions and skill sets of staff and volunteers do 478 not always match these needs. 480 o Very few community members have the time, support, and interest to 481 stand for the IAOC (or even participate in administrative 482 discussions, unless something goes astray), and many who do are 483 self-funding their work. 485 Much of the discussion at the workshops regarding staff and volunteer 486 issues focused on the IAOC committees. Committees allow the IAOC to 487 draw in expertise in a particular area, without burdening committee 488 members with the overall task of IAOC responsibility. One 489 participant observed that the function of the committees seems to go 490 pretty well, but sometimes scope and authority in relation to the 491 IAOC are unclear. They asked, who's really in charge of the 492 committee? Who is leading the discussions and making decisions? 493 What kind of decision is being made? Who is supporting those 494 decisions? Another participant noted that a committee can make a 495 recommendation that is subject to easy reversal by the IAOC, which 496 can provide an undercurrent of doubt when discussions take place. 498 A participant said that, although IAOC committees are listed on the 499 IAOC website (https://iaoc.ietf.org/committees.html), there is a lack 500 of documentation about how the committee participants are chosen. 501 Elaborating the expertise and skills needed can be a challenge. For 502 some teams it is necessary to have paid staff or contractors. 503 Examples of paid contractors include the IETF lawyer, and some of the 504 site visit and meeting contract negotiation staff. Last year the 505 IAOC asked for volunteers from the community and added participants 506 to several committees. 508 A Workshop participant noted that, in order to understand how the 509 committees work, one needs to understand the requirements and 510 dependencies on contractors and other support structures, which is 511 complicated and not generally well understood. The commentor further 512 asked, what are the contractors doing? What effort is required to 513 serve as a volunteer? A participant felt that the committee 514 composition of volunteers plus paid staff may cause confusion about 515 participants' roles, and also cause control and accountability 516 issues. Another person said that the lack of encouragement for 517 participation in committees might be a disincentive for IAOC 518 participation. However, one workshop participant was surprised at 519 the number of participants involved in IAOC committees as well as the 520 varied mix of roles - volunteers, contractors, staff - which can make 521 it hard to assess if a committee member was serving as a paid hand, 522 policy maker, or somewhere in between. 524 3.5. Internal IAOC Organizational Issues 526 Slide 11 of the slide deck [IASA2-Workshop-Slides] discussed the 527 following issues specific to internal IAOC organizational matters: 529 o The IAOC has 4 ex officio members (IETF Chair, IAB Chair, ISOC 530 CEO, IAD (non-voting)), and 5 appointed members. One of 5 members 531 is appointed by the ISOC Board of Trustees, and is traditionally 532 expected not to stand for IAOC Chair. This yields - 534 * A small pool from which to select the IAOC Chair 536 * A small pool from which to select the IETF Trust Chair 538 * Very few (2, by the time you've appointed IAOC and Trust 539 Chairs) "worker bees" for the IAOC 541 o Requiring that the IAOC and the IETF Trust be constituted by the 542 same group of people overloads the job responsibilities of both 543 roles, narrows the pool of individuals willing and able to serve 544 on the IAOC, and creates the potential for conflicts in cases 545 where the creation of Trust policies requires IAOC oversight. 547 o Requiring that the IAB chair serve on the IAOC overloads the IAB 548 Chair's job responsibilities and narrows the pool of people 549 willing and able to serve as IAB Chair. The same may be true for 550 the IETF Chair. 552 Some workshop participants wondered if better communication, for 553 instance, knowing about IAOC activities early enough to affect them, 554 would translate into more people wanting to participate in the IAOC. 555 Information about the IAOC can be made available in email and on the 556 website, but that may not inspire people who don't care about 557 administrative issues to volunteer. A workshop participant stated 558 that having people spend time just on the technical work would be a 559 success, but relying on volunteers for the IAOC's large volume of 560 work may be unreasonable. 562 It was pointed out that populating the IAOC is difficult because is 563 there are so many leadership positions, and only those appointees 564 from the IESG, IAB, and the two appointed by NomCom can be Chair. 565 One of those four people will always be the Chair, and another of 566 those four will chair the IETF Trust. Another participant said that 567 there is a tradition of the ISOC Board of Trustees appointee not 568 standing for chair, but that is not a requirement, and the IAOC could 569 move away from it. It's important that the appointers choose people 570 who have interest in chairing, otherwise the pool gets smaller. A 571 workshop participant said that they had heard stories that NomComs 572 did not know what to look for when appointing someone to the IAOC. 573 One participant followed up to say that in their experience, NomComs 574 have looked for someone to clearly represent the IETF community, to 575 act as a balance against the institutional appointees. This 576 participant noted that This goal is probably in contrast to finding a 577 good chair. 579 Participants noted that the ex officios bring much knowledge to the 580 IAOC and they need to be participants, but they don't have the time. 581 One way to solve that would be to increase the regular membership of 582 the IAOC. There needs to be a way for the community to pick 583 additional people. 585 The question was asked: to what extent is the IAOC an oversight body? 586 A participant felt that if the community wants the IAOC to be able to 587 do more than provide the thinnest layer of oversight, then it needs 588 to revisit how to populate the IAOC. Another commentor felt that in 589 order to make any changes to the IAOC, the community needs to 590 understand the current roles and responsibilities of its members. 592 A commentor said that the IETF Trust requires talent separate from 593 the rest of the IAOC tasks. This commentor said that maybe it is no 594 longer convenient that the IAOC and Trust are together, given the 595 IANA stewardship transition and the need for IAOC feedback to the 596 Trust concerning the IANA IPR. However, this commentor felt that 597 this is a secondary issue compared to other issues raised during the 598 workshops. When asked if the Trust could be smaller, workshop 599 participants responded that size was not an issue aside from getting 600 quorum occasionally (this has only happened once or twice). Another 601 commentor felt that the size and composition of the IETF Trust should 602 be determined by its role, which needs to be discussed. Currently, 603 the IETF Trust has a light workload. 605 4. Security Considerations 607 This document describes the challenges and opportunities of the 608 IETF's administrative support activity. It introduces no security 609 considerations for the Internet. 611 5. IANA Considerations 613 This document has no actions for IANA. 615 6. Acknowledgments 617 The authors would like to thank the participants of the IASA 2.0 618 workshops for their thoughtful insights. 620 7. Informative References 622 [Arkko-2016] 623 Arkko, J., "Proposed Project: IETF Administrative Support 624 2.0", 2016, . 627 [I-D.arkko-ietf-finance-thoughts] 628 Arkko, J., "Thoughts on IETF Finance Arrangements", draft- 629 arkko-ietf-finance-thoughts-00 (work in progress), 630 February 2017. 632 [I-D.daigle-iasa-retrospective] 633 Daigle, L., "After the first decade: IASA Retrospective", 634 draft-daigle-iasa-retrospective-00 (work in progress), 635 October 2016. 637 [IASA-Org-Chart] 638 IETF, "IASA 2.0 Workshop #2 Slide Deck; Slide 5: IASA 639 Organizational Chart", 2017, 640 . 644 [IASA2-Workshop-Slides] 645 IETF, "IASA 2.0 Workshop #2 Slide Deck", 2017, 646 . 650 [IASA20-1100UT-rec] 651 IETF, "Recording: IASA 2.0 Virtual Workshop, 28 February 652 2017 (1100 UT)", 2017, . 655 [IASA20-1600UT-rec] 656 IETF, "Recording: IASA 2.0 Virtual Workshop, 28 February 657 2017 (1600 UT)", 2017, . 660 [IASA20-proceedings] 661 IETF, "IASA 2.0 Virtual Workshop Proceedings", 2017, 662 . 665 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 666 IETF Administrative Support Activity (IASA)", BCP 101, 667 RFC 4071, DOI 10.17487/RFC4071, April 2005, 668 . 670 Appendix A. Participants 672 We list here participants in each virtual workshop (as listed in the 673 WebEx recording "Participants" list). 675 A.1. Participants in the 1100 UTC virtual workshop 677 o Alissa Cooper 679 o Eric Rescorla 681 o Gonzalo Camarillo 683 o Greg Wood 685 o Hans Peter Dittler 687 o Jari Arkko 689 o Joseph Lorenzo Hall 691 o Lars Eggert 693 o Leslie Daigle 695 o Lou Berger 697 o Randy Bush 699 o Scott Bradner 701 o Sean Turner 703 o Stephen Farrell 705 o Suzanne Woolf 707 A.2. Participants in the 1600 UTC virtual workshop 709 o Alexa Morris 711 o Alia Atlas 712 o Alissa Cooper 714 o Ben Campbell 716 o Avri Doria 718 o Ben Campbell 720 o Bob Hinden 722 o Cindy Morgan 724 o Dave Crocker 726 o Desiree Miloshevic 728 o Gonzalo Camarillo 730 o Greg Wood 732 o Hans Peter Dittler 734 o Henrik Levkowetz 736 o Jari Arkko 738 o Jason Livingood 740 o Jean Mahoney 742 o Joel Halpern 744 o Joseph Lorenzo Hall 746 o Kathleen Moriarty 748 o Laura Nugent 750 o Leslie Daigle 752 o Mat Ford 754 o Peter Yee 756 o Ray Pelletier 758 o Richard Barnes 759 o Robert Sparks 761 o Russ Housley 763 o Scott Bradner 765 o Spencer Dawkins 767 o Suresh Krishnan 769 o Suzanne Woolf 771 Authors' Addresses 773 Joseph Lorenzo Hall 774 CDT 776 Email: joe@cdt.org 778 A. Jean Mahoney 780 Email: mahoney@nostrum.com