What are BoFs?

Birds of a Feather sessions (BOFs) are essentially initial discussions about a specific topic that interests the IETF community. These usually happen at IETF meetings, and for people who want to hold a BoF, they need to request it well before the meeting. The bar for establishing a BoF is very high - this has led to an abundance of IETF "side meetings" where the approval process for having a session is not nearly as difficult as it is for a BoF.

Anyone interested can submit a BOF proposal to the Internet Engineering Steering Group (IESG). Proposals need to be in by the BOF submission deadline for each meeting, and the IESG approves it (or, not) before the IETF meeting agenda is published.

While some BOFs end up forming a working group, others are just for getting a sense of the IETF community's thoughts on a topic without any plans to create a working group.

RFC 2418 Section 2.4 provides guidance and details about proposing a Birds of a Feather session, particularly in the context of "IETF Working Group Guidelines and Procedures".

RFC 5434, as its title suggests, provides "Considerations for Having a Successful Birds-of-a-Feather (BOF) Session".

RFC 6771 provides guidelines on how to have a side meeting to work on a possible proposal for new work in the IETF.

In general, BoFs are a good way to see topics that are emerging for standardization in the IETF. The BoFs ofteen provide a way for participants to be aware of new areas for standardization and new technologies that are candidates for interoperability.

BoFs at the Vancouver (IETF 120) IETF meeting

The current agenda for the IETF 120 meeting to be held in Vancouver in July 2024 includes five agenda items listed as BoFs:

1. alldispatch - not really a Bof - Monday, July 22 from 9:30am - 11:30am

2. sconepro - Secure Communication of Network Properties - Tuesday, July 23rd from 9:30am - 11:30am

3. diem - Digital Emblems - Wednesday, July 24 from 9:30am - 11:30am

4. green - Getting Ready for Energy-Efficient Networking - Wednesday, July 24 from 1:00pm - 3:00pm

5. nasr - Network Attestation for Secure Routing - Thursday, July 25 from 9:30am - 11:30am

alldispatch

alldispatch is a BoF in the general area which does not adopt drafts, but instead provides a direction for the authors of a draft to ensure that the draft gets further consideration at the IETF. The first alldispatch session took place at IETF 119 and was not particularly a rousing success. The alldispatch session was meant to be IETF-wide and not specific to any particular area in the IETF. The six results that are possible after a discussion in all dispatch are:

1. Direct the work to an existing WG

2. Propose a new focused WG

3. Recommendation to hold a full BOF

4. Publish as AD-sponsored (assuming AD is willing)

5. Additional discussion or community development required (e.g., with a new non-WG mailing list)

6. Work is not appropriate for IETF

alldispatch Chairs

Jim Fenton, Rifaat Shekh-Yusef, Shuping Peng

alldispatch at IETF 120

The agenda for alldispatch at IETF 120 is not yet available. Slides, presentations, and individual drafts are also not yet available. We are aware that a replacement for BCP83 may be on the agenda. It's also possible that one of the improvements to alldispatch proposed by Carsten Bormann will be discussed.

alldispatch links

• alldispatch Datatracker page is https://datatracker.ietf.org/group/alldispatch/about/.

• Mailing list archive for [email protected] is here.

• alldispatch wiki is here

• alldispatch IETF 120 meeting materials will eventually be here.

• alldispatch IETF 120 is currently scheduled for Monday, July 22 from 9:30am - 11:30am (subject to change).

sconepro

sconepro is a BoF in the new Web and Internet Transport area. It met at IETF 119. sconepro stands for Secure Communication of Network Properties. The sconepro objective is to optimize user QoE for streaming media/video services through network assisted application-level self-adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs). The problem statement for sconepro comes mostly from Google and Meta.

sconepro is very active with seven individual drafts already submitted to the datatracker:

draft-tomar-sconepro-privacy-01 SCONEPRO Privacy Properties and Incentives for Abuse

draft-tomar-sconepro-ecn-01 SCONEPRO Need for Defining A New On-Path Signaling Mechanism

draft-eddy-sconepro-api-02 APIs To Expose SCONEPRO Metadata to Applications

draft-joras-sconepro-video-opt-requirements-00 SCONEPRO Video Optimization Requirements

draft-tan-sconepro-netneutrality-00 SCONEPRO Net Neutrality

draft-rwbr-sconepro-flow-metadata-01 Flow Metadata for Collaborative Host/Network Signaling

draft-brw-sconepro-rate-policy-discovery-01 Discovery of Network Rate-Limit Policies (NRLPs)

There is a draft charter even though it hasn't been sent to the mailing list. You can find the charter here.

sconepro Chairs

Cullen Fluffy Jennings, Martin Thomson

sconepro at IETF 120

The agenda for sconepro at IETF 120 is not yet available. Slides, presentations, and individual drafts are also not yet available. Presumably some of the drafts listed above will be up for discussion. Also, presumably, the draft charter will be up for discussion as well.

sconepro Links

• sconepro Datatracker page is https://datatracker.ietf.org/group/sconepro/about/.

• Mailing list archive for [email protected] is here.

• sconepro GitHum is here.

• sconepro IETF 120 meeting materials will eventually be here.

• sconepro IETF 120 is currently scheduled for Tuesday, July 23 from 9:30am - 11:30am (subject to change)

diem

diem is a brand new BoF and the Vancouver IETF will host its first meeting. diem stands for Digital Enblems. International law uses various symbols to show special protections, like the blue helmets for UN peacekeepers, the blue and white shield for UNESCO, and the Red Cross for the International Committee of the Red Cross, all covered by the Geneva Conventions. Journalists with "Press" emblems also get special protections on the battlefield, thanks to Article 79 of Protocol I of the Geneva Conventions and UN Security Council Resolution 2222. Symbols of national governments and international organizations protect things like diplomatic pouches and couriers under the Vienna Convention on Diplomatic Relations. Other marks are protected against misuse by agreements like the Paris Convention, the Madrid Protocol, and the TRIPS agreement.

But these physical symbols have their limits and don't really work in the digital world. This BoF addressesthe issues for digital symbols and lists the needs from various stakeholders for a digital emblem that fixes the problems of physical ones and ensures digital assets are protected under international law.

I can find a single "problem statement" for the BoF here. A search on the Datatracker for "diem" leads to no results (which seems crazy to me because diem is an IESG approved BoF).

diem Chairs

Russ Housley

diem at IETF 120

There is almost no information about the diem BoF available at this time. The agenda for diem at IETF 120 is not yet available. Slides, presentations, and individual drafts are also not yet available.

diem Links

• diem Datatracker page is https://datatracker.ietf.org/group/diem/about/.

• Mailing list archive for [email protected] is here.

• diem IETF 120 meeting materials are not yet available but should eventually be here.

• diem IETF 120 is currently scheduled for Wednesday, July 24 from 9:30am - 11:30am (subject to change)

green

green is also a brand new BoF and the Vancouver IETF will host its first meeting. green stands for Getting Ready for Energy-Efficient Networking. The suggested scope of a future, green working group would be:

The GREEN WG is chartered to concentrate on the following short-term deliverables:

• Defining terms and definitions related to energy metrics. Where possible, terms and definitions in existing RFCs will be reused.

• Developing YANG models to enable controling, monitoring and reporting of energy usage through metrics and attributes at component, device, and network levels.

• Providing YANG models to control and optimize energy usage in network devices, and across the network, including energy saving capabilities.

• Documenting both the energy consumption metrics and their associated YANG data models, along with guidance on how to use and interpret them.

• Developing or selecting a framework to collect, aggregate, and consume the above mentioned metrics and attributes developed in the WG from existing and new devices of almost every kind.

To stay focused, the Working Group will not address energy-related issues in every networking area. Some topics are already be covered in other venues while others may not be mature enough or present major shortcomings (e.g., have well-documented but unresolved security threats). The following topics are not within the scope of the Working Group:

• Routing protocols and algorithms, including those that consider energy factors.

• Benchmarking methodology for power consumption in networking devices.

• The carbon accounting and reporting protocol to measure, manage, and report their greenhouse gas emissions and other sustainability-related data.

• Methodologies for asessing environmental sustainability and related performance for the network devices.

• Methodologies for understanding the impact of energy efficiency optimization on service quality.

• Regulatory, compliance, and corporate responsibility related matters.

The people working on the BoF have been holding regular meetings and you can find the minutes of those meetings here.

green Chairs

Jari Arkko and Adrian Farrell

green at IETF 120

There is already a draft agenda, which does not yet seem to have been sent to the mailing list:

green BoF proposed agenda:

• The usual administrivia (5 minutes)

• A chance for the AD to say what he expects from the meeting (5 minutes)

• An overview of the desires and objectives preferably from a network operator (15 minutes)

• An introduction to the topic from someone who knows how components use power (10 minutes)

• A summary of the sorts of things a working group do (25 minutes)

– Metrics, YANG, and consideration of EMAN work

– Coordination with E-impact

– Coordination with IVY

– Possible architectural models : centralized versus distributed

• A discussion (60 minutes)

– The draft charter

– Questions from the room

green Bof proposed speakers:

Tony Li is volunteer to present(Issue #53):

• "An introduction to the topic from someone who knows how components use power"

• "A centralized approach to network energy management" o Juniper Candidate to present (Tony Li)

• "A distributed approach to network energy management"

Marisol Palmero/Jan Lindblad are volunteer to present (subject to change speakers to other authors for the poweff/philatelist/sustainability-insights drafts)

• metrics

• framework

• considering to address GAPs considered part of new WG focus and outside of the EMAN work.

green Links:

• green Datatracker page is https://datatracker.ietf.org/group/green/about/.

• Mailing list archive for [email protected] is here.

• green GitHub is here.

• green IETF 120 meeting materials have been published here.

• green IETF 120 is currently scheduled for Wednesday, July 24 from 1:00pm - 3:00pm (subject to change)

nasr

nasr is also a brand new BoF with its first meeting in Vancouver at IETF 120. nasr stands for Network Attestation for Secure Routing. Endpoints typically get almost no information of the properties of the paths over which their traffic is carried, especially when the properties are security-related. Therefore, data security (confidentiality, integrity and authenticity) has been usually protected by traffic signing and encryption mechanisms.

However, clients with high security and privacy requirements are not satisfied with signing and encryption mechanisms only; they now request information of the trustworthiness or security properties of the network paths over which the traffic is carried, preferably to choose the desired properties. For example, some clients may require their data to traverse through trusted devices and trusted links only, in order to avoid data being exposed to insecure devices, causing leakage.

The Remote Attestation Procedures (RATS) working group developed procedures to establish a level of confidence in the trustworthiness of a device or a system. By providing objective, verifiable evidence and proof of a device’s trust or security properties, clients can expect the device function correctly and deterministically, as anticipated.

Network Attestation for Secure Routing (NASR) aims to create a robust system that provides objective, verifiable evidence of network path properties that can be used by routing technologies to steer traffic towards. Following the same RATS philosophy and building on top of it, NASR also aim to provide objective, verifiable evidence and proof of trust or security properties, but on a path level. Additionally, NASR also aim to provide verifiable proof that certain packets/flows traveled such paths. With NASR, clients can have the ability to be aware of, request and verify specific path properties, and have confidence that certain packets or flow indeed traversed the requested path.

There is an architecture draft and a terminology draft.

nasr Chairs:

Luigi Iannone, Nancy Cam-Winget

nasr at IETF 120

The draft agenda for NASR is:

• Secure Routing Path Considerations

– Meiling Chen

– 10 Minutes (Cumulative Time: 20 Minutes)

• Path Validation Application Scenarios

– Diego Lopez

– 10 Minutes (Cumulative Time: 30 Minutes)

• Path Characteristics Verification and Attestation Services

– Yutaka Oiwa

– 10 Minutes (Cumulative Time: 40 Minutes)

• Trusted connection service for enterprise customers with high security requirements

– Yu Fu

– 10 Minutes (Cumulative Time: 50 Minutes)

• Use Case Consolidation for NASR

– Liu Chunchi (Peter)

– 5 Minutes (Cumulative Time: 55 Minutes)

• Problem Statement

– Liu Chunchi (Peter)

– 10 Minutes (Cumulative Time: 65 Minutes)

• Proposed initial Architecture

– Michael Richardson

– 15 Minutes (Cumulative Time: 80 Minutes)

nasr Links

• nasr Datatracker page is https://datatracker.ietf.org/group/nasr/about/.

• Mailing list archive for [email protected] is here.

• nasr IETF 120 meeting materials are published here.