Technical Programs

• Evolvability, Deployability, & Maintainability (EDM)
• Environmental impacts of Internet Technology (EIMPACT)

Lifetime of a Program

Technical programs are usually created based on an identified problem or gap. As such, a technical program should be closed if 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@ietf.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 topic 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 hen 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@ietf.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.