| Network Working Group | J. Hall |
| Internet-Draft | CDT |
| Intended status: Informational | A. Mahoney |
| Expires: September 14, 2017 | March 13, 2017 |
Report from the IASA 2.0 Virtual Workshops
draft-hall-iasa20-workshops-report-00
This is the Workshop Report for the IETF Administrative Support Activity 2.0 (IASA 2.0) Virtual Workshops, held on 28 February 2017 at 1100 UT and 1600 UT. The original IETF Administrative Support Activity (IASA) was created ten years ago, and since has been subject to some reflection. In the intervening years, there has been considerable change in the necessary tasks of IETF administration and in the world around the IETF, and in how the IETF raises funds and finances its work. The IASA 2.0 process seeks to address which administrative arrangements will best support the IETF going forward.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The IETF Administrative Support Activity (IASA) arrangements were created more than ten years ago, when the IETF initially took charge of its own administration [RFC4071]. In the intervening years, there has been considerable change in the tasks of IETF administration and in the world around the IETF [I-D.daigle-iasa-retrospective] and in how the IETF raises funds and finances its work [I-D.arkko-ietf-finance-thoughts].
In 2016, IETF leadership began a discussion to review and possibly rework administrative arrangements at the IETF, dubbed the IETF Administrative Support Activity 2.0 project [Arkko-2016]. The IASA 2.0 process seeks to address what administrative arrangements that will best support the IETF going forward.
To make changes, the IETF community first needs to understand the challenges and/or missed opportunities within the current system. A number of areas face challenges: structural and organizational issues regarding the roles and interfaces between the IETF, the IAOC, ISOC, the IESG, and contractors; the IETF funding model; transparency and communication issues among the many IASA moving pieces; availability of staff, contractor, and volunteer resources compared to the administrative workload; and internal IAOC organizational issues.
To get input from the community to identify challenges and opportunities in these and other areas, the IETF leadership set up two virtual workshops open to everyone in the IETF community and to people who are or have worked in IETF-administrative roles. These virtual workshops were held on 28 February 2017 at 11:00 UTC and 16:00 UTC. The agenda, slides, and minutes from the two meetings are available at the workshop proceedings [IASA20-proceedings]. Recordings of the two workshops are also available [IASA20-1100UT-rec] [IASA20-1600UT-rec].
At these workshops, the participants provided their experiences and suggestions. Proposed changes and solutions will be discussed and dealt with in a later phase of the IASA 2.0 project.
The following acronyms will be heavily used in the discussion below:
In terms of organizational arrangements, the workshop chairs provided a diagram that captured many of the organizational relationships among various entities [IASA-Org-Chart]. The IAOC relies on a number of committees to get its work done – Finance, Legal Management, Meetings, Technology Management, and RFP Committee in addition to any ad hoc committees. Participants noted that the connections between these committees and the IAD are not reflected in the diagram.
Some workshop participants felt that the diagram generally reflected reality and that it illustrated the large number of moving pieces involved. A workshop participant said that there are a lot of moving parts compared to 11 years ago when the IASA was formed, as IASA now encompasses certain functions that it did not at that time, such as the Secretariat and the RFC Production Center.
The IASA 2.0 Virtual Workshops focused on the areas below.
Slide 10 of the slide deck [IASA2-Workshop-Slides] discussed the following structural issues between the IETF, the IAOC, ISOC, the IESG, and contractors:
Workshop participants discussed organizational issues between ISOC and IETF. For example, participants noted some items are branded IETF, like the IETF Journal, are ISOC driven and funded, and are not directed by the IETF community. One participant said it is often not clear who is doing what on behalf of whom; a comment was made that IASA 2.0 discussions should focus on what the IETF is doing. Other ISOC-funded activities include participation in the Ombudsteam – which was requested by IETF and should show up in an accounting of IETF resources – and ISOC Fellows and Policy Fellows – which are ISOC-funded and controlled programs that should not show up in an IETF budget. (The ISOC Fellows and Policy Fellows programs encourage, respectively, technologists from emerging and developing economies and policy experts from around the world to interact with the IETF community.) A commentor mentioned that this sounded like a branding issue at times: while the IETF Trust holds IETF trademarks, is the IETF brand and the contours of what it encompasses clear? The commentor further asked: who defines the contents of ISOC activities that are visible to the outside world? Who decides how to drive those things? Should those be included in the budget?
A related but distinct issue arose around control and policy authority among the various IASA components. One workshop participant said that the IETF community is confused about who has policy authority. They continued: for example, if the IETF community wants to change the structure of relationships with sponsors, who has the authority to make that decision? IESG? IAOC? Community consensus? This participant felt that this is unclear. A participant said that there is a gap in terms of the IAOC being the body that carries this out. How does the IAOC get its policy instructions from the IETF community? The IAOC only goes to the community for specific policy questions – e.g., the privacy policy or changes to the trust legal provisions – but does not get general “please do this” feedback from the community. A commentor stated: In many cases the “policy from the IETF community” comes through the IESG as voiced by the IETF chair. Another workshop participant felt that there was a lack of clarity around even where some questions should be asked (e.g. “how many logos do we want on our badges?” or “who drives/has responsibility for some specific functions?”). That commentor felt that an important question is whether or not the IETF community wants a “thin” IAOC that has mostly oversight of the IAD or a “thick” IAOC that has administrative responsibilities – i.e. “who is driving the bus?”
In terms of accounting structure, the discussion at the virtual workshop concluded that there have been improvements to accounting that have helped increase accuracy, and the IETF budget has been adjusted over the last 5 or 6 years to recognize ISOC staff contributions, but appropriate accounting between ISOC and IETF needs more work. One commentor said that it was not clear to them who is in the driver’s seat. One participant stated it as: “If we don’t like a function, can we delete it? Or does that require IETF participation?” Some things are very clearly IETF topics, and then there are some that fall in between IETF and ISOC, and then there are some that are purely ISOC. A participant felt that control needs to be aligned with accounting.
On the marketing side, workshop participants discussed how the IETF is represented to the outside world – donors, media, other organizations and communities – and some felt that it needs to be clearer, even if this is currently an ISOC activity. One participant said that people don’t understand the difference between ISOC and IETF and that we need to understand this before we can correctly communicate it.
Some felt that the lack of rigid formality in the organization and structure was not necessarily a bad thing. One commentor felt that the structure of IETF, which is not well-defined and flexible, provides a benefit to the Internet. Another commentor stated that given the proclivities of engineers towards structure and formality, working to improve IASA could make the IETF more structured and thus less appealing to some kinds of contributors. Further, they stated that we need clarity that institutionalizes this level accessibility to all participants, which will be tricky. In contrast, another participant felt that we do ourselves a disservice by this long-standing confusion about whether IETF is an organization; they felt that people within the community know what is meant by the IETF and that more formality is not necessary. The point was made that any changes to the organization of the IETF will have practical implications, such as impacting legal transactions, which generally go through ISOC.
Slide 12 of the slide deck [IASA2-Workshop-Slides] discussed the following issues related to the IETF funding model:
Workshop participants discussed funding issues faced by the IETF, including: increasing costs due to more tools, higher hotel fees, etc.; relatively flat growth in funding; meeting fees that do not cover operating expenses so that there is increased pressure on sponsorship and increased ISOC contributions. These funding issues are covered in [I-D.arkko-ietf-finance-thoughts].
Some workshop participants commented on how the willingness of sponsors to fund IETF is a useful measure of the IETF’s relevance. That is, they said, looking for sponsors is a good way to measure support in the community. The commentor went on to say if sponsorship starts to dry up, it may be a symptom of larger problems, that the IETF is no longer relevant or at least becoming less relevant. This participant felt that the IETF needs to ensure its ongoing relevance and that the IETF needs to understand what it’s offering. One commentor stated that while it’s valuable to stay in touch with the engineers who understand how the Internet works, that may not justify their attendance at three meetings a year. It was felt that individual sponsors’ goals and the goals of the IETF community will never line up perfectly, but that fact doesn’t take away the need for clarity.
In terms of funding sources, participants commented that it is generally good for the IETF to have multiple sources of funding on which to stand. This participant further stated that diversity in funding sources allows IETF to shift gears: IETF endowment can provide longer-term stability; Long-term sponsorship, such as the Global Host program ($100k per year for 10 years, also stated as the best way to support the IETF as an organization); meetings can be funded through fees (although registration fees are prohibitive for many) and sponsorships. However, explaining the need for diversity of funding is more complicated than it needs to be. One participant felt that we probably need to find a simpler story.
Specifically, participants discussed a potential mismatch between the IETF’s activities and its funding model, which is mainly constituted from meeting fees. Questions raised included: What is the right proportion for meeting-based revenue? What are the alternative methods to fund the non-meeting-based activities? Sponsorships? Do we hire staff or contract to provide assistance?
While ISOC currently makes up any current budget shortfalls for IETF (after meeting fee and sponsorship income), a participant commented that the assumption that ISOC’s primary purpose is to fund the IETF is more strongly held in some corners than others. At the same time, this commentor said that another school of thought believes that the .org contract that funds ISOC requires ISOC to ensure the support of the IETF, so is a core goal of ISOC. Another commentor said that after consulting some of the people involved when the .org contract was given to ISOC, the IETF was clearly only a part of the public interest the .org contract mission sought to fulfill. Further, another commentor noted, those in local ISOC chapters don’t think that IETF is a purpose of ISOC, let alone the main purpose.
In terms of the relative amounts of funding from sources, a commentor mentioned that the level of funding that the IETF receives through Global Hosts is much smaller compared to the sponsorship funding of many large-scale open-source projects (e.g., $500K/year per sponsor), and the IETF could be getting a lot more money through this source.
Further, in terms of sponsorship funding, a participant state that it’s not often a cut-and-dry proposition, requiring a larger, more diffuse commitment than a sponsor may originally expect. For example, this participant noted that meeting sponsors are also responsible for extra work like printing T-shirts and staging social events, and there is a lot of risk to a meeting sponsor if they get anything wrong (presumably in terms of backlash from the community). This aspect of logistics and event programming is an area of expertise that few IETF participants have, so sponsors often have to get their marketing departments involved, for example. A commentor said, if sponsors could focus on just securing the money, where someone else would worry about the logistics problems, that would help.
There were also issues discussed with communication to potential sponsors and funders what they are agreeing to. A workshop participant felt that the IETF needs to be able to clearly state what it is asking for, and what the relevance is for the potential sponsor. One participant stated that it’s unclear now who is responsible for communicating these messages to funding sources, Further this participant said that it’s unclear how this outreach is done and if it is done well, especially for large sponsors. One commentor states that it seems like there are two types of organizations the IETF is looking for – those involved in the Internet ecosystem, and those interested in standards. This person felt that honing outreach to both of those types of organizations would be helpful. Another commentor stated that the same sponsors are asked for support over and over again. This person further asked about how new companies are sought out and developed for potential support. One commentor noted that outreach appears to be split between the various IASA parties. A commentor stated that when ISOC is raising funds on behalf of the IETF, its relationship to the IETF needs to be clearly communicated.
Participants offered up some perspective as current and past IETF sponsors through their own organization. One participant noted that they consider it unusual to fund the IETF through a third party (ISOC). This can raise approval and audit questions inside the sponsor company, and the sponsor is left guessing as to when the IETF might receive the money they contribute. Finally, this participant wondered if this indirect structure makes sense in the future or if can be made direct. The structure also makes it difficult to contribute to the IETF endowment for the same issues and because there is no independent organization managing and reporting on the IETF endowment. Thus, perhaps a different level of financial and administrative separation from ISOC would be helpful for fundraising in the future, both for supporting the IETF generally and for the endowment.
Some commentors talked about what kinds of support were easier to secure from their organizations. An IETF participant may be more inclined to seek, and find it easier to gain, sponsorship for easily communicated and defined activities, for example, the Systers Lunch. For activities like these, commentors noted that IETF participants may do a better job than staffers hired to solicit funding, and we should distribute the solicitation work as best as we can.
Slide 9 of the slide deck [IASA2-Workshop-Slides] discussed the following issues involving transparency and communication:
Some said that he IAOC and IASA could better communicate with the IETF community. IASA has lagged progress of groups like the IESG, who have made agendas and meetings open. Participants felt that the IETF community should document the transparency requirement clearly, e.g., set the default to be open, such as open meetings and materials, and publish an exception list for confidential or sensitive matters. Hotel contracts aren’t shown due to confidentiality agreements, and there have been some arguments about that reducing transparency of meeting deals. One workshop participant identified fear as a significant cause of lack of transparency. A commentor offered two potential sources of fear: making a decision that the IAOC knows the community won’t like, and having a situation where there is a Last Call and all of the previous conversations the IAOC has had are rehashed.
With regards to IAOC communication to IETF, some said that we could use a better understanding of what needs to improve and where it can improve. A commentor felt that the IAOC could do better in telling the community what it does and how it makes decisions. However, another commentor noted, now that plenary time has been shortened, the community doesn’t get to see the IAOC, and this reduces the opportunities for the community to understand what they do. This commentor noted that participants have said that they don’t want exposure to the boring details at the plenaries – “which are boring until they’re not, and then everyone is surprised.” Another participant asked, how we encourage the IETF community to understand the IAOC and role of the IASA to best reduce these poor outcomes? One suggestion was for the IAOC to hold information sessions or office hours at meetings, to allow people to raise concerns and ask for guidance. This could help the community get to know the IAOC and have people volunteer. Some felt that the IAOC needs to provide insight into what the IAOC is going to do, as opposed to what it has just done. This commentor felt that telegraphing for a few years may improve the level of education. It could help with transparency without running afoul of the confidentiality of contracts. Some felt that a Last Call for some IAOC things is worthwhile, but other, more mundane tasks don’t need it. A participant mentioned that the IAOC should document the basis for a decision, rather than the mere fact of it.
Slide 8 of the slide deck [IASA2-Workshop-Slides] discussed the following issues involving staff and volunteer resources:
Much of the discussion at the workshops regarding staff and volunteer issues focused on the IAOC committees. Committees allow the IAOC to draw in expertise in a particular area, without burdening committee members with the overall task of IAOC responsibility. One participant observed that the function of the committees seems to go pretty well, but sometimes scope and authority in relation to the IAOC are unclear. They asked, who’s really in charge of the committee? Who is leading the discussions and making decisions? What kind of decision is being made? Who is supporting those decisions? Another participant noted that a committee can make a recommendation that is subject to easy reversal by the IAOC, which can provide an undercurrent of doubt when discussions take place.
A participant said that, although IAOC committees are listed on the IAOC website (https://iaoc.ietf.org/committees.html), there is a lack of documentation about how the committee participants are chosen. Elaborating the expertise and skills needed can be a challenge. For some teams it is necessary to have paid staff or contractors. Examples of paid contractors include the IETF lawyer, and some of the site visit and meeting contract negotiation staff. Last year the IAOC asked for volunteers from the community and added participants to several committees.
A Workshop participant noted that, in order to understand how the committees work, one needs to understand the requirements and dependencies on contractors and other support structures, which is complicated and not generally well understood. The commentor further asked, what are the contractors doing? What effort is required to serve as a volunteer? A participant felt that the committee composition of volunteers plus paid staff may cause confusion about participants’ roles, and also cause control and accountability issues. Another person said that the lack of encouragement for participation in committees might be a disincentive for IAOC participation. However, one workshop participant was surprised at the number of participants involved in IAOC committees as well as the varied mix of roles – volunteers, contractors, staff – which can make it hard to assess if a committee member was serving as a paid hand, policy maker, or somewhere in between.
Slide 11 of the slide deck [IASA2-Workshop-Slides] discussed the following issues specific to internal IAOC organizational matters:
Some workshop participants wondered if better communication, for instance, knowing about IAOC activities early enough to affect them, would translate into more people wanting to participate in the IAOC. Information about the IAOC can be made available in email and on the website, but that may not inspire people who don’t care about administrative issues to volunteer. A workshop participant stated that having people spend time just on the technical work would be a success, but relying on volunteers for the IAOC’s large volume of work may be unreasonable.
It was pointed out that populating the IAOC is difficult because is there are so many leadership positions, and only those appointees from the IESG, IAB, and the two appointed by NomCom can be Chair. One of those four people will always be the Chair, and another of those four will chair the IETF Trust. Another participant said that there is a tradition of the ISOC Board of Trustees appointee not standing for chair, but that is not a requirement, and the IAOC could move away from it. It’s important that the appointers choose people who have interest in chairing, otherwise the pool gets smaller. A workshop participant said that they had heard stories that NomComs did not know what to look for when appointing someone to the IAOC. One participant followed up to say that in their experience, NomComs have looked for someone to clearly represent the IETF community, to act as a balance against the institutional appointees. This participant noted that This goal is probably in contrast to finding a good chair.
Participants noted that the ex officios bring much knowledge to the IAOC and they need to be participants, but they don’t have the time. One way to solve that would be to increase the regular membership of the IAOC. There needs to be a way for the community to pick additional people.
The question was asked: to what extent is the IAOC an oversight body? A participant felt that if the community wants the IAOC to be able to do more than provide the thinnest layer of oversight, then it needs to revisit how to populate the IAOC. Another commentor felt that in order to make any changes to the IAOC, the community needs to understand the current roles and responsibilities of its members.
A commentor said that the IETF Trust requires talent separate from the rest of the IAOC tasks. This commentor said that maybe it is no longer convenient that the IAOC and Trust are together, given the IANA stewardship transition and the need for IAOC feedback to the Trust concerning the IANA IPR. However, this commentor felt that this is a secondary issue compared to other issues raised during the workshops. When asked if the Trust could be smaller, workshop participants responded that size was not an issue aside from getting quorum occasionally (this has only happened once or twice). Another commentor felt that the size and composition of the IETF Trust should be determined by its role, which needs to be discussed. Currently, the IETF Trust has a light workload.
This document describes the challenges and opportunities of the IETF’s administrative support activity. It introduces no security considerations for the Internet.
This document has no actions for IANA.
The authors would like to thank the participants of the IASA 2.0 workshops for their thoughtful insights.
| [Arkko-2016] | Arkko, J., "Proposed Project: IETF Administrative Support 2.0", 2016. |
| [I-D.arkko-ietf-finance-thoughts] | Arkko, J., "Thoughts on IETF Finance Arrangements", Internet-Draft draft-arkko-ietf-finance-thoughts-00, February 2017. |
| [I-D.daigle-iasa-retrospective] | Daigle, L., "After the first decade: IASA Retrospective", Internet-Draft draft-daigle-iasa-retrospective-00, October 2016. |
| [IASA-Org-Chart] | IETF, "IASA 2.0 Workshop #2 Slide Deck; Slide 5: IASA Organizational Chart", 2017. |
| [IASA2-Workshop-Slides] | IETF, "IASA 2.0 Workshop #2 Slide Deck", 2017. |
| [IASA20-1100UT-rec] | IETF, "Recording: IASA 2.0 Virtual Workshop, 28 February 2017 (1100 UT)", 2017. |
| [IASA20-1600UT-rec] | IETF, "Recording: IASA 2.0 Virtual Workshop, 28 February 2017 (1600 UT)", 2017. |
| [IASA20-proceedings] | IETF, "IASA 2.0 Virtual Workshop Proceedings", 2017. |
| [RFC4071] | Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005. |
We list here participants in each virtual workshop (as listed in the WebEx recording “Participants” list).