Internet Architecture Board

RFC2850

IAB Technical Programs and Administrative Support Groups

Home»Activities»IAB Technical Programs and Administrative Support Groups

IAB Technical Programs and Administrative Support Groups are structured approaches managed and maintained by the IAB in order to support the IAB in more effectively executing its chartered responsibilities (see RFC2850 Section 2.1); in particular improving the long-term perspective on the Internet informed by technical and architectural considerations.

Below describes first some history of IAB programs and subsequently the general working method for both, Technical Programs and Administrative Support Groups.

A current list of active Technical Programs and Administrative Support Groups can be found in the datatracker: https://datatracker.ietf.org/program/

History

Traditionally the IAB has taken an interest in a number of architectural areas. Among the architectural areas, in no particular order:

  • IPv6 and its adoption and transitional coexistence with IPv4 given the realities of an IPv4-dominated Internet;
  • DNS health and security;
  • Web security;
  • The realities of maintaining the end-to-end and layered architecture;
  • Prevention of unwanted traffic;
  • The security and stability of the routing system; and
  • Internationalization of the Internet and balance with localization and retention of a global network.

These are some areas that require long-term perspective and may involve various activities and deliverables. For instance, such complex area may require a separate activity for scoping the work (BOFs, presentations, position papers), progressing the work, or stimulating the charter development of new work in the IETF. Such effort may further involve collaboration with other organisations.

The IAB started organizing the work in such areas in the form of programs to enable long term activities scoped and managed by the IAB, although for the actual work the IAB may form a team with specific expertise needed for the activity, which may not be within the IAB. Structuring work in this way has several objectives:

  • minimise dependency on the current IAB composition and specific expertise and competencies of its members;
  • minimise dependency on the tenure of IAB members;
  • increase bandwidth by shifting responsibilities of IAB members from doing the actual work to organising and delegating work, and providing guidance;
  • shift the IAB focus from the specifics of an activity to the development of the vision and maintenance of the big picture, to selecting priority areas and carrying out respective efforts.
  • improve visibility of the activities the IAB is busy with and provide an opportunity to the community to provide feedback on the content and priority of specific activities.

Recently the IAB further refined the process of establishing and managing programs and thereby realized a need to distinguish Technical Programs from Administrative Support Groups.

Types of Programs

The IAB so far organized its longer-term work in programs. However, some of those are mostly administrative (e.g., the liaison oversight program, the IANA program, plenary planning program, and also the RSOC), others are more focused on technical aspects, such as privsec and StackEvo in the past and then e.g. model-t.

Administrative programs provide a set of experts that help the IAB to address their oversight or administrative responsibilities, often by delegating these responsibilities to the program members. The goal is to have a stable set of experts that may either be continuously working (e.g., having frequent meetings on their own) or are available on request (maybe comparable to some directorates). Administrative programs are usually set up to exist for a long time.

Technical programs are usually created based on a then-current technical/architectural concern. Technical programs also tend to meet at IETF meetings but meetings are more need-based and potentially less or more frequent depending on the topic. The main goal of technical programs is to raise awareness and discussion of the specific concern in the community. This may be done by holding workshops, support the IAB in writing documents, or also just group discussion that then may respectively impact what the program members do within the community. Technical programs are expected to be closed when the identified concern is addressed or when sufficient awareness has been built in the broader community.

Problems with Openness, Awareness, and Membership Management

In the past IAB programs were (mostly) by-invitation closed groups that often used closed mailing lists to do the meat of their work. Membership was manage by the program lead, mostly on an a-hoc basis. Even though more open per-program mailing lists existed, many active program participants were unaware of their existence and they were not used. This lead to a situation were many IETF participants were entirely unaware of the existence of technical IAB programs, nor able to contribute.

The refactoring into Technical Programs and Administrative Support Groups enables Technical Programs to be more open with broader participation and as such also increases the legitimacy of any results produced, while Administrative Support Groups provide dedicated expertise and continuity to the IAB in selected administrative tasks that e.g. might also require a certain level of confidentially.

The current way of working for both approaches if further described below.

Technical programs

Life Time of a program

Technical programs are usually created based on an identified problem or gap. As such a technical program should be closed is that problem solved, the gap closed, or at least sufficient awareness has been raised in the community to acknowledge the problem or gap.

Technical programs are rather short lived in their nature – potentially longer than an IAB term but limited to a couple of years. If no active work is being undertaken in a program, the program can be closed anytime by the lead (usually in agreement with the community and core participants). In addition, program reviews serve as a check to determine if there is still work to do for the IAB and the IAB might decide to close a program.

IAB programs Don’t Create Standards or Conduct Research

The fundamental goal of a technical program should be to raise awareness of an issue or question relating to the Internet architecture, or to consider whether there is a question to be answered in a particular area. programs help the IAB to frame questions. They do not directly work to develop protocols, requirements, or use cases for new protocols, systems, or frameworks. Furthermore, programs should not be scoped around an open research question without a solution, but rather around concrete problems or architectural short-comings that might have existing solutions but need more awareness in the community.

If a program concludes that there is research to be done to answer those questions, that suggests that an IRTF activity should be considered; if it concludes that engineering or standards are required, that suggests that a BoF should be considered to transition the work to the IETF.

IAB programs cannot publish RFCs. programs provide input to the IAB discussions on a topic, and the IAB may choose to publish an RFC that takes that input into account, but an IAB program cannot directly publish, or propose to publish, an RFC.

Establishment of new Technical programs

Only IAB members can formally propose new technical programs and the IAB needs to agree to formation. Community members can of course encourage the IAB to consider forming a new program.

Before a technical program is formally established by the IAB, the IAB member(s) proposing the program should provide a program description and gauge community interest by requesting public feedback on the proposed scope. This can be done by requesting a new open mailing list or discussion on architecture-discuss@iab.org, or even perhaps by starting with a few virtual or in-person meetings when appropriate.

The initial program description should describe the issue or question relating to the Internet architecture that the programs will work on and, if possible at that point of time, goals the programs wants to achieve. The programs description can be refined anytime with approval by the IAB. Usually updates are done at the review.

The IAB needs to agree to both – start a new technical program or to setup the required mailing list, but a formal vote is not required – agreement of those present at an IAB meeting and confirmed on the IAB mailing list without objection (e.g., in minutes) is sufficient.

New technical programs will be reviewed after 6 months by the IAB. As such when forming a new program IAB members should mainly consider if the topics is of interest for the IAB and that there are no strong concerns about the IAB working on a specific topic. The program description and more detailed actions can however be refined after the first 6 months. Or if a technical program was not able make progress within this initial time frame, the program should be closed after review. Especially if the program was fully inactive or if participants were not to agree on a clear scope and goals, immediate closure should be considered. However, if active discussion by email or in form or meetings/calls is happening but no concrete output was generated so far that should be considered as progress. Most importantly the program should aim to converge to concrete goals and next step within these initial 6 months.

Lead and IAB liaison

Typically, a technical program is led by an IAB member. Often the IAB member proposing a new program will also be the initial lead of the program.

The objective of the program lead is to facilitate activities within the program, provide an oversight and ensure continuity. The lead doesn’t need to have specific expertise in the area, but must have good general understanding of the issues from technical, business, and or policy perspective.

However, with approval of the IAB, the program lead can also be a non-IAB member. This makes sense if needed to support continuity, e.g. when the current lead leaves the IAB but is still actively committed to the program, or if the scope of the program requires expertise that is currently not covered by the IAB, including the potential case where a person judging community consensus is required.

If a non-IAB member is serving as lead, the IAB in addition selects an IAB liaison providing a bridge for communication to and from the IAB as well as administrative support from the IAB if needed.

The lead or liaison is further expected to bring the IAB perspective to the work.

Participation

All technical programs must provide a way for the community to engage in the discussion and provide feedback on activities or guidelines the program develops. As such transparency of the work of the program should be provided by publishing minutes and/or holding entirely open meetings.

Technical programs should have at least two IAB members participating (one being the lead or liaison). Current IAB members are free to join any program and may leave or stay in the program when they leave the IAB. IAB programs support IAB activities and if there is no interest indicated by the current IAB in the specific topic that the programs is addressing, that’s a strong indication that a program should be closed.

In addition technical programs usually have a dedicated core team of people who are committed to actively work on the program activities, typically in the order of 10-15 people. There is no maximum limit, however, it seems less desirable to have an overly large set of people compared to the work force needed for a certain topic.

The core team can maybe be see similar to a permanent design team, which can be tasked by the program to consider a certain problem and then presents potential solutions to the group for discussion. As such the core team is expected to not only provide feedback but actually drive part of the work and explicitly commit to that and the time needed for it. As in the case of review teams or directorates, having an explicit list of volunteers helps to support progress and might also help some people to get their commitment recognised in order to secure time and budget for it.

Creating a core team is not intended to exclude others. Contributions and active participation by anybody in the community is welcome. The program lead is responsible to update the core team to reflect active participation and commitment, however, any listing in not expected to be continuously updated but rather at specific check points such as the review.

When new programs are announced on the architecture-discuss@iab.org list, interested parties can approach the program lead to get involved. In addition, IAB members may reach out directly to experts to get the involvement as needed to work successfully on the respective topic or problem.

At each review the current list of core participants should be evaluated as well in order to ensure the right expertise and work force is still committed to the (potentially) adapted program goals. Further checking the number of active core people at each review will also provide an indication if the program is still viable or should be closed.

Mailing lists

All programs must have an open mailing list.

Programs can also have additional mailing lists that are used for coordination of specific tasks or a specific group of people. But most discussion should happen on the open list. Any non-public list should mainly be used for administrative purposes. As such it is not expected that programs will create many closed lists or if those lists are created they might only be used for a specific task or short term activity.

All meetings should be announced on the open program list and minutes of all meetings must be sent to the open program list.

Information shared on non-open mailing list should not be shared publicly without explicit approval by the person who has provided this information. However, a high-level summary of a discussion is usually not seen as confidential, except explicitly stated.

Meetings and Workshops

IAB programs have flexibility in how they work. Programs may organise different kind of meetings, and possible models include frequent calls, one time workshops or a workshop series, as well as BoF-like meetings to gather boarder community input, or smaller side meetings co-located with face-to-face IETF meetings.

Technical programs have no fixed or maximum duration, but it is generally expected that they will work at a pace that allows them to complete their work within the term of the IAB members driving the activity.

Generally it is recommended to open meetings for everybody in the community to join. Open meetings should be announced on relevant mailing list(s). For certain tasks or more administrative questions meetings in small groups, design-team-like, might be adequate as well. Minutes for such meetings must also be provided publicly on the program mailing list.

Meetings around IETF face-to-face meetings may or may not consume one of the “normal” IETF agenda slots, or can e.g., be arranged as a breakfast or evening meeting. Meetings, that are held as part of the IETF agenda, must be registered as an IAB session on the IETF BoF wiki (to support scheduling but also raise awareness).

Programs may target a workshop to generate broader input and have more time for discussion. This is especially valuable for new programs. A program could even potentially operate as a series of stand-alone workshops, perhaps co-locating with some other community events, if that were useful in order to encourage participation by an appropriate community.

To hold a workshop the program will propose a workshop to the IAB, and the IAB will decide and organise such workshops following the usual IAB process.

For IAB workshops interested parties are usually required to provide some statement of interest to be invited to participate. This enables the workshop organisers to keep the discussion focused and prepare accordingly. However, everybody who has provided a statement that is in scope for the respective workshop should be invited.

Similar as for all IAB workshops, a report will be published as RFC on the IAB stream as public record of the discussion and activities at the workshop.

Reporting and Review

Technical programs are expected to report back to the community in the IAB Open Meeting or on the arch-discuss mailing list. The frequency and level of detail of such reporting is to be defined by the IAB, but it is expected that each program will report back at least once per year.

As described above, new IAB technical programs will be reviewed after 6 months. While barriers to start new programs for IAB members should be low, this initial review should be used to refine the program description or close early if not showing success.

The IAB will review each technical program once every year to decide if the program should be continued (in its current form) and potentially also adapt the scope or group of core participants or other aspects of a program.

The criteria for IAB review of a program will vary from case to case. It is desirable, but not necessary, to have the criteria written and agreed by the IAB and the program participants.

Program reviews can happen during an IETF meeting, at the IAB retreat, in IAB business calls (or the reserved slot), or in dedicated calls if needed for any reason. The review will be open to observers based on usual rules of the type of meeting where the review done. No matter which meeting will be chosen, the minutes of the review should be published and feedback should be sent to the open program mailing list.

Administrative Support Groups

Administrative Support Groups are groups with dedicated membership, most similar to directorates, that act as an arm of the IAB, assisting the IAB in discharging its responsibilities [RFC 2850]. The IAB decides to open or close Administrative Support Groups based on their needs described in a short statement of intent.

Membership and mailing list

Administrative Support Groups have a dedicated membership with at least one IAB member which will act as the lead or liaison. Membership might consist of a fixed number of total members, or may just have a fixed number for the participation of IAB members, or participation may be open to all IAB members. Usually these groups have non-IAB members as well, but may also consists only of a small subgroup of IAB, in order to clearly distribute responsibilities in maintaining a long-term task of the IAB, e.g. as could be done for the organisation of the technical plenary.

The lead of Administrative Support Activity is usually performed by an IAB member but, depending on the respective activity, may also explicitly be requested to be hold by a non-IAB member, e.g. to more clearly separate responsibilities, e.g in case of RSOC.

Membership is determined by the IAB and periodically reviewed. While the IAB will reevaluate the IAB members (and potentially the needed number of IAB members) yearly, usually at the March IETF meeting when the new IAB is seated, other members may have a longer fixed membership term, based on the needs of the respective activity. Membership is renewed by the IAB, potentially based on community feedback. If membership of a member is not renewed (as the member does not want to take another term or based on feedback) and a new member is to be selected, the IAB may run a call for volunteers, depending on the respective expertise needed, and should ask for community feedback before approval.

Only members of an Administrative Support Activity are subscribed to the mailing list, however, anybody in the community should be able send to the group’s mailing list in order to provide feedback. Announcements by an Administrative Support Activity can be sent directly to other mailings by the chair (e.g. architecture-discuss@iab.org or ietf@ietf.org), or the group can request the IAB to make certain announcements if needed (e.g. on the ietf-announce@ietf.org list).

Meetings

Administrative Support Groups can hold frequent meetings/calls or only meet on demand based on the nature of the respective activity the groups is responsible for. The group may produce minutes and may make these minutes public after approval of the whole group.

Reporting

Administrative Support Groups must periodically share results with the IAB (e.g. once per month or at minimum once a year). These results should be made public as part of IAB meeting minutes, depending upon the purpose of the group and the nature of the results.

Expectations about confidentiality

Since Administrative Support Groups act as extensions of the IAB, IAB members may share summaries of IAB discussions when these summaries are relevant and sharing will be helpful. These summaries should only contain an overview of the discussion and will not include information that the IAB considers private. IAB members should not share details of IAB discussions with non-IAB members.

The members of an Administrative Support Groups should assume that any materials or discussions may be shared with the IAB, although the IAB may request that specific materials NOT be shared (for example, the IAB chose not to see the materials that the RFC Series Oversight Committee gathered during its search for an RFC Editor).

Any information provided, from any source, should be treated as if it were confidential to the IAB itself. This information should not be shared outside the members of the Administrative Support Groups and the IAB, unless the permission to share was explicitly received. This also applies to presentations and similar written materials.

When it is helpful to do so, the group may approve sharing information informally with non-group members, in order to benefit from experience and/or expertise held by non-group members. The program must make the decision to share this information explicitly, and must set expectations about confidentiality when sharing this information.