| Individual Submission | B. Haberman, Ed. |
| Internet-Draft | Johns Hopkins University |
| Intended status: Informational | J. Arkko |
| Expires: January 8, 2018 | Ericsson Research |
| L. Daigle | |
| Thinking Cat Enterprises LLC | |
| J. Livingood | |
| Comcast | |
| J. Hall | |
| CDT | |
| E. Rescorla | |
| RTFM, Inc. | |
| July 7, 2017 |
IASA 2.0 Design Team Recommendations
draft-haberman-iasa20dt-recs-00
The arrangements relating to administrative support for the IETF were created more than ten years ago. Since then, there has been considerable change in the tasks and in our own expectations. The IETF community has discussed these changes and the problems they cause. The community has some sense of the properties they expect from future arrangements, including structural and organizational changes, changes to volunteer and staff personnel resources, and transparency changes.
This document is a product of a design team, focused on providing additional information to the community about solution options, as well as supporting analysis of the implications of those options. To be clear, the community is responsible for adopting any recommendations or making any final decisions.
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 January 8, 2018.
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 arrangements relating to administrative support for the IETF (referred to as the "IETF Administrative Support Activity" (IASA) [RFC4071]) were created more than ten years ago, when the IETF initially took charge of its own administration. The arrangements have served the IETF reasonably well, but there's been considerable change in the necessary tasks, in the world around us, and our own expectations since the creation of the IASA. What administrative arrangements best support the IETF in the next ten years?
The system has experienced various challenges and frustrations along the way, for instance around meeting arrangements. There are also some bigger questions about how the organisations are structured, for instance about the division of responsibilities between IETF and ISOC.
The IETF community has discussed and continues to discuss these topics, most recently on the "IASA20" mailing list and BOF at IETF98. Alissa Cooper, the Chair of the IETF, convened a small design team to start evaluating potential options going forward. The purpose of the design team is to provide material that informs the community discussion, both in terms of providing a bit more worked through solution ideas, as well as supporting analysis of the implications of those options. This information, along with all other input provided in the discussion, hopefully helps the community and IETF leadership decide what next steps to take.
To be clear, the community is in charge of adopting any recommendations or making any decisions. This draft, the output of the design team's considerations, has no particular official standing.
Once an initial version of this draft is published, the authors would like to ask feedback particularly on two aspects:
Once this discussion completes, it becomes feasible to discuss what the conclusions or recommendations ought to be, and which recommendations the community should adopt. It should also be noted that IETF administrative matters have been organised jointly with ISOC, and it is important that ISOC be involved in the process of looking at the reorganisation.
As a base for this work there was a good articulation of the set of problems we are facing in [I-D.hall-iasa20-workshops-report] and [I-D.daigle-iasa-retrospective]. The community discussion seems have indicated also some of the outcome properties that are expected. The scope of the solutions explored included:
Changes to the funding model are out of scope to the extent they fall outside the categories above.
The rest of the document is organised as follows. The next two sections (Section 2 and Section 3) describe the background and summarise the challenges noted in the community discussion. The two sections after that (Section 4 and Section 5) explain what categories of changes were considered, and describe the primary options for structural changes. The following two sections (Section 6 and Section 7) focus on analysis of the different options along with conclusions and recommendations.
The administrative support structure is intended to be responsive to the administrative needs of the IETF technical community.
RFC 4071 [RFC4071] defines the current IETF Administrative Support Activity (IASA). It is an activity housed within the Internet Society (ISOC), as is the rest of the IETF. RFC 4071 defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC.
As RFC 4071 notes, IASA is distinct from IETF-related technical functions, such as the RFC Editor, the IANA, and the IETF standards process itself. The IASA has no influence on the technical decisions of the IETF or on the technical contents of IETF work.
Today, IASA's activities support a number of functions within the IETF system:
The following acronyms are used in this document:
Discussion leading to this document has been framed by the issues discussed on IETF mailing lists and documented elsewhere [I-D.daigle-iasa-retrospective], [I-D.hall-iasa20-workshops-report], [I-D.arkko-ietf-iasa-thoughts]. The reader is referred to those documents and ongoing discussion on the IASA20@ietf.org mailing list for fuller details on the range of challenges facing the IETF in its handling of administrative matters.
In summary, the key areas of challenge that have shaped this work are:
Of the items above, the first two are largely to be addressed by structural updates, while the last two groups are more about discussing tradeoffs and updating documented expectations.
Given that a change seems necessary, what might that change include? There seem to be three broad categories of IETF organisation that will be affected:
The overall structure also includes questions such as whether IETF is an organisation and its relationship to ISOC.
There are some interconnections between different aspects of reorganisation. For instance, how IETF defines its relationship to ISOC will have some implications on what kind of oversight structure is needed; a more independent, free-standing organisational model for IETF would imply new functions for the IASA.
There are a number of choices to make within the reorganisation effort. In particular, IETF's relationship to ISOC could be arranged in a fundamentally similar manner than it is today, but improved, e.g., to make clear who is expected to control a particular part of the operation. But the relationship could also be arranged in a different way, for instance, as a subsidiary of ISOC or as a more free-standing, independent organisational unit.
The IASA redesign effort needs to address the main challenges listed above. More specifically, a new organisational structure needs to do at least the following:
The design team believes that there are three general approaches to evolving the IASA function. The options generally focus on the relationship between the IETF and ISOC. Changes to this relationship directly affect how the IASA function gets carried out.
It should be noted that all three options require more administrative budget per year than what is currently allocated for IASA functions. In addition, they will most likely require a more predictable level of ISOC funding, rather than the current model of a base funding level combined with periodic infusions to cover shortfalls.
The following subsections describe each option. Section 6 highlights their pros and cons and effectiveness in comparison to the goals stated earlier.
In the IASA++ option, the IETF and ISOC maintain the current structural relationship. This means that the IETF remains an organized activity of ISOC, ISOC maintains funds and contracting authority on behalf of the IETF, and all IASA staff are ISOC employees.
While the relationship remains the same, the IETF and ISOC will make improvements to the relationship in order to enhance the functionality of the IETF. The following are some potential improvements that could be made under this approach:
Some specific changes to make these improvements are discussed in Section 5.2 regarding board and staff work divisions. While in this option there is no need for a formal board, there is still a need to redefine the role of the IAOC. The necessary staff changes are discussed in Section 5.3.
It would also be necessary to improve IAOC transparency. In the IASA++ option, in addition to the general improvement needs in this area, there is an added need to continue the improvements relating to accurate accounting of resources and actions on the ISOC side.
In this option, an ISOC subsidiary would be created as the new legal home of the IETF. A subsidiary can have its own bank account, by-laws, charter, board of directors/trustees, staff, and corporate identity. As a subsidiary of ISOC, the IETF and ISOC can share overhead and resources. The IETF would likely rely heavily on contractors for most administrative tasks.
As a subsidiary of ISOC, the IETF could eliminate the IAOC and replace it with a board of directors/trustees (see Section 5.2). Administrative decision-making authority would rest primarily with the administrative staff, with oversight provided by the board (see Section 5.3. Exception cases could be developed where board approval would be required to authorize strategic decisions.
Other likely changes could include:
There are also other possible changes that would need further discussion:
In this option, a new non-profit organization (e.g., IETForg) is created independent from ISOC as the new legal home of the IETF. IETForg would have its own bank account, by-laws, charter, board of directors/trustees, staff, and corporate identity. The administrative staff for IETForg could be kept lean and would likely rely on contractors for the bulk of administrative tasks. Minimally, the IETForg staff would be responsible for administration, development/fundraising, communications, and personnel management.
As an independent organization, the IETF could eliminate the IAOC and replace it with a board of directors/trustees. Administrative (day-to-day) decision-making authority would rest primarily with IETForg staff and contractors, with oversight provided by the board. Exception cases could be developed where board approval would be required to authorize strategic decisions. Again, further detais regarding the board and staff changes are in Section 5.2 and Section 5.3.
Other likely changes could include:
Other possible changes that may need more discussion would include possible change in the role of IETF Trust, as discussed in Section 5.1.2.
Oversight is obviously affected by what we decide to do with the relationship to ISOC. A bigger, more independent role for the IETF would require an IASA board to be designed for that. Nevertheless, some change in the role of an oversight body and the work division between it and staff is necessary in any case.
Also, the design team believes the role of the community members serving in the IASA needs to be kept at a level appropriate for volunteer service (see community role in Section 3 and limits in Section 4.1).
Beyond this, there are a number of choices in division of responsibilities and the structure of the organisation. The key decision points are:
In this option, the current IAOC is disbanded and replaced by a traditional oversight board, common in most non-profit organisations. This board, the IASA Board (IB), acts to set strategic direction for IETF administrative matters, sets budgets, provides fiscal oversight, provides high-level oversight about major new projects, and so on. The board is also responsible for hiring and assessing the performance of the Executive Director (the highest-level staff director, see Section 5.3).
This option is potentially valid for all overall structure choices outlined in Section 5. However, for the ISOC Subsidiary and Independent Organisation options, the board would have to be a formal board, typical of other non-profit organisations.
The board works with staff who is empowered to carry out the operations as directed by the board. The staff is responsible for operating within the limits set by the board, and are accountable to the board. Including being hired and fired as needed. The staff's responsibilities include:
The primary difference between this option and the current IAOC arrangements is that board acts at a higher decision level, and is not involved either in detailed decisions. These are tasks reserved for the staff, and the board's role is to oversee that staff performs appropriately in their role.
The composition of the board needs careful attention. It is important to have regular IETF participants in the board, but at least some of the board members need to have skills and experience less common among IETF participants, namely non-profit management, budget experience, and ability to help make connections to raise money or provide advice about fundraising (all of which are typical for a non-profit board).
One potential model for populating the board is a Nomcom-selection for 2/3 of the board members and some other type of selection for 1/3 of the board members with a view for more independent, well-networked members. However, the responsibility of the board and the manner in which board members are selected are separable design matters.
In this option, there is a board and staff just like in Section 5.2.1, but in addition, an Advisory Council (AC) provides an interface to the community on matters that require assessing community opinion. For instance, the current polling of community feedback relating to potential future meeting locations could be one such matter.
An advisory council canvassing and pulling for this information might be a better approach than either free-form mailing list discussion, or the relatively opaque process that is currently used. Advisory board results could be documented in the same fashion as IESG documents last call results. Some IAOC site decisions have been done in this way, summarising feedback received, others with less information.
The advisory council would be comprised of IETF community members and selected by Nomcom, and would benefit from having either the IETF Chair or another IESG member as a liaison. The advisory council would not make decisions about how the IETF should run, but it would be available for the staff to consult whenever they needed a view from the community, and it would also be available to run community discussion processes or to get input from the community to funnel back to the staff. The advisory council would have a well-defined interface to the IESG as well.
The separation of the board and the advisory council, with some overlap between them, allows the allocation of people to tasks according to their skills. We can have experienced managers involved in hiring, firing, and reviewing the Executive Director and overseeing the budget, while we have experienced community people giving the perspective of the community.
The design team believes that staff resources need to increase and/or be reorganised in order to move from one director to a few more specialised roles (see growth in Section 3). And In addition, the team believes that future organisation for IASA may benefit from organising all resources under the more clear and direct control of the IETF (see division of responsibilities in Section 3 and roles in Section 4.1).
The current arrangement involves one officially designated IASA employee, but there are also many supporting employees. They are less clearly assigned for the IETF, working as contractors or at ISOC.
This document suggests a structure that involves the following roles:
Note: The Executive Director likely needs to be a full-time employee, as is likely the case for the other Director-level positions.
These persons also need to rely on a number of contractors and outside specialists. For instance, a Legal Counsel, to assist the IASA on legal matters as well as contracting.
This section provides a basic analysis of the effects of the different options.
We use the following criteria based on the goals stated earlier (Section 4.1):
Table 1 highlights the pros and cons of the IASA++ option.
| Pros | Cons |
|---|---|
| Maintains familiar structures and relationships | Does not provide the IETF with true independence of funding or staff from ISOC |
| Start-up costs limited to those associated with hiring additional staff | Creates risk that challenges present in the current IASA will not actually be solved or will re-emerge over time |
| Does not require legal and administrative work to incorporate a new entity | Potentially requires ISOC to cede more authority to the IETF community or increase transparency beyond ISOC's comfort zone |
| Allows IETF to continue to rely on ISOC to somewhat frictionlessly compensate for budget shortfalls if necessary | Continuing confusion about alignment between ISOC and IETF on policy and standards matters. |
Table 2 highlights the pros and cons of the ISOC subsidiary option.
| Pros | Cons |
|---|---|
| Forces some delineation of responsibility, staff, and funds between the IETF and ISOC | Leaves open some potential for continued lack of clarity about authority and funding between the IETF and ISOC |
| Provides the IETF community with greater authority over IETF administration | Potentially requires ISOC to cede more authority to the IETF community or increase transparency beyond ISOC's comfort zone |
| Can leverage existing ISOC legal structures and personnel to keep administrative work required to incorporate subsidiary to a minimum | Requires legal and administrative work to incorporate subsidiary |
| Requires less IETF community volunteer time commitment to administrative matters than current IASA | Vests more decision-making authority in paid staff than under current IASA |
| Allows IETF to continue to rely on ISOC to somewhat frictionlessly compensate for budget shortfalls if necessary | Start-up costs include costs of incorporating the subsidiary and re-organizing/hiring additional staff |
| Allows IETF to continue to leverage expertise of ISOC administrative personnel | Continuing confusion about alignment between ISOC and IETF on policy and standards matters. |
Table 3 highlights the pros and cons of the independent organization option.
| Pros | Cons |
|---|---|
| Eliminates all ambiguity about IETF having authority independent from ISOC over staff, funds, and decisions | Start-up costs include legal and administrative costs to incorporate a new entity, hire new staff, transfer contracts and funds |
| Provides the IETF community with potentially complete authority over IETF administration and funding | ISOC's financial support for the IETF may be viewed as more tenuous if the IETF is a legally separate entity from ISOC |
| Requires less IETF community volunteer time commitment to administrative matters than current IASA | Ability for the IETF to rely on ISOC in the event of budget shortfalls may be more limited |
| Allows for direct investment in small number of professional staff specifically tailored to the IETF's needs and culture, while continuing to rely heavily on contractors | Vests more decision-making authority in paid staff than under current IASA |
| Provides opportunity to structure board in such a way to overcome current challenges with IAOC structure | Requires more from board members than what is currently required of IAOC insofar as hiring and evaluating staff |
| Removes need for alignment between ISOC and IETF on policy and standards matters. | Requires IETF to assume legal risk currently assumed by ISOC |
For the overall structure, the implications of the current situation and the three options are summarized in Table 4.
| Criteria | Current situation | IASA++ | ISOC Subsidiary | Independent Organization |
|---|---|---|---|---|
| SCALE | NO | NO | YES | YES |
| EVOLVE | NO | NO (Note 1) | MAYBE (Note 1) | YES (Note 1) |
| STRAT TSK | NO | NO (Note 1) | YES | YES |
| OPS TSK | YES | YES | YES | YES |
| OVERLOAD SEP | YES | YES | YES | YES |
| CLEAR ISOC REL | NO | NO | YES | YES |
| DIR CONTROL | NO | NO | YES | YES |
| CULTURE | YES | YES | YES | YES |
| WORK SEP | YES | YES | YES | YES |
| IASA EXP | NO | MAYBE (Note 2) | MAYBE (Note 2) | MAYBE (Note 2) |
Note 1: Evolution in the current system is more difficult than if IETF was either clearly a subsidiary or its own organisation. This is because changes need agreement from two organisations, and, in the current model, the control of IETF-dedicated resource is not as clear as it could be. A subsidiary or independent model would also ease driving any strategy that the IETF wants to drive, as decisions would be more on the IETF side than something that today would require negotiation with ISOC.
Note 2: Setting expectations is difficult merely based on an organisational model. Certainly a clear separation between roles of the board and staff helps. However, expectations are also a matter of documentation, which would have be created and communicated. Finally, expectations are a cultural matter, current IAOC arrangements and community views have ended up in a situation where there is a lack of trust and unclear models for what can or cannot be expected.
For the internal organisation, the implications of the current situation vs. a strategic board model is summarised in Table 5.
| Criteria | Current Situation | Strategic Board |
|---|---|---|
| SCALE | NO | YES |
| EVOLVE | MAYBE (Note 1) | YES (Note 1) |
| STRAT TSK | NO | YES (Note 2) |
| OPS TSK | YES | YES (Note 2) |
| OVERLOAD SEP | NO | YES (Note 2) |
| CLEAR ISOC REL | n.a. | n.a. |
| DIR CONTROL | n.a. | n.a. |
| CULTURE | YES | YES |
| WORK SEP | YES | YES |
| IASA EXP | NO | MAYBE (Note 3) |
Note 1: Given that the IASA is being reorganised, we acknowledge that the current structure is capable of evolving. However, the operational focus and overload in the current arrangements are making this harder than is necessary. Change requires action from outside of the IASA, rather than being a normal task within the IASA to evolve their own model. A strategic board that is not deeply involved in the operations should be able to look at evolution more easily. Similarly, a dedicated advisory council can help determine community concerns, and might be able to do this even better than a board. However, lines of authority between a strategic board and advisory council would need to be clearly delineated.
Note 2: There may be a difference between the strategic board with and without an advisory council, in how overload situations and the separation of different tasks goes. The existence of an advisory council alleviates some workload on board or staff, particularly in dealing with community opinion determination, freeing the board to do its strategic work and staff to concentrate on operations and execution.
Note 3: Setting expectations is difficult merely based on an oganisational model, see Note 2 under Section 6.2.2.
There are two different classes of financially-relevant changes. First, both the ISOC interface change and staff changes will imply changes in what is being accounted for in budgets and reports, even in cases where the actual work or the number of people stays the same. That is, depending on the chosen overall organisation model, some items that are currently in ISOC budget may move to become IETF budget items, but the total amount of expenditure stays the same. Note that the IETF already accounts for the expenses related to key IETF support staff (e.g., IAD, communications, etc).
Secondly,there are some actual increases in required financial resources. We expect all the alternatives to lead to somewhat higher funding needs, and in fact shifting more work to staff from volunteers is one of the goals. For the staff changes, the primary position actually being added is having both Executive Director and Operations Director, instead of one IAD. We've already had a Legal Counsel and roles similar to the Director of Fundraising and Communications Director. These chances coincide with other personnel changes in IASA, as the experienced, long-term IAD is retiring. Even from a learning curve point of view more people will be needed, but in this case it also makes sense to have the organisation be less dependent on one central person.
Given the learning curve effect, and a new organisation, it is expected that the role of the Legal Counsel will also increase, e.g., in terms of reviewing contracts.
It is important to ensure that IETF funding is arranged in a manner that is satisfactory to the IETF and ISOC communities. Further comments and observations are welcome.
Depending on the chosen option, volunteers are needed for either different roles than today (the board) or for both different roles and more volunteers (the board and the advisory council).
It is for further study whether current IETF leadership (e.g., IAB Chair) should continue to be part of these boards or councils.
While there are some initial conclusions in the analysis in the previous sections, clearly more work is needed. In particular, we request and welcome thoughts and contributions from the IETF community, particularly regarding any potential missed options or the implications of options being considered here.
This text is the work of the design team, but greatly influenced by discussions in the IETF community. The team would in particular like to thank Alissa Cooper, Andrew Sullivan, Ray Pelletier, Ted Hardie, Gonzalo Camarillo, Brian Carpenter, Lucy Lynch, Stephen Farrell, Dave Crocker, Jon Peterson, Alexa Morris, Michael Richardson, Olaf Kolkman, Kathy Brown, and Melinda Shore for interesting discussions in this problem space.
| [I-D.arkko-ietf-iasa-thoughts] | Arkko, J., "Thoughts on IETF Administrative Support Activities (IASA)", Internet-Draft draft-arkko-ietf-iasa-thoughts-00, March 2017. |
| [I-D.daigle-iasa-retrospective] | Daigle, L., "After the first decade: IASA Retrospective", Internet-Draft draft-daigle-iasa-retrospective-01, June 2017. |
| [I-D.hall-iasa20-workshops-report] | Hall, J. and J. Mahoney, "Report from the IASA 2.0 Virtual Workshops", Internet-Draft draft-hall-iasa20-workshops-report-00, March 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. |