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