Automatic Minutes Generation

Status of This Memo

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 https://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 10 April 2026.¶

Copyright Notice

Copyright (c) 2025 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Recorded minutes of meetings are an essential tool for documenting the decisions reached at those meetings [YESMINISTER]:¶

• It is characteristic of all committee discussions and decisions that every member has a vivid recollection of them and that every member’s recollection of them differs violently from every other member’s recollection. Consequently, we accept the convention that the official decisions are those and only those which have been officially recorded in the minutes by the officials¶

For this reason Section 3.1 of [RFC2418] duly requires that working group sessions be minuted:¶

• All working group sessions (including those held outside of the IETF meetings) shall be reported by making minutes available. These minutes should include the agenda for the session, an account of the discussion including any decisions made, and a list of attendees. The Working Group Chair is responsible for insuring that session minutes are written and distributed, though the actual task may be performed by someone designated by the Working Group Chair. The minutes shall be submitted in printable ASCII text for publication in the IETF Proceedings, and for posting in the IETF Directories and are to be sent to: minutes@ietf.org¶

Common practice in most WGs is for a volunteer WG participant to take minutes. Predictably, this leads to suboptimal outcomes, with volunteers struggling to keep up with the conversation and lack of clarity about what precisely needs to be minuted (full narrative minutes? just important points? just decisions?). This can be evidenced by the varied level of details in the minutes of different working groups in the proceedings.¶

Minute takers, especially those relatively new to the IETF, often struggle to keep track of who is speaking. Moreover, being a minute taker interferes with the ability to participate in discussions. This results in marginalizing the participation of those who volunteer and chairs often struggle to find minute takers for this reason.¶

In the 25+ years since RFC 2418, the technical and operational practices of the IETF have changed in ways that change the nature of the minutes problem:¶

• Sessions are routinely video and audio recorded, with those recordings posted publicly.¶

• The recordings are automatically transcribed.¶

• The speaker queue is managed via software, providing data to support automated recognition of who is speaking.¶

• Agendas and minutes are managed via software tooling rather than via humans reading email.¶

The combination of these changes makes it possible to produce adequate minutes without requiring real-time note taking by a participant in the meeting. This document describes some appropriate practices and requests the IETF LLC to make the necessary updates to the IETF datatracker to automate those practices.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Automating Minutes Collection

RFC 2418 requires that minutes contain the following items:¶

• The agenda for the session¶

• A list of attendees¶

• An account of the discussion including any decisions made¶

In practice, chairs rarely submit the first two but they are already stored in datatracker, but instead just submit the freeform minutes. No change is needed for these.¶

As noted above, transcripts are already available and by definition provide an account of the discussion and capture any decisions. This document encourages chairs to use the transcript as the basis for minutes.¶

The IETF LLC is requested to update the IETF tooling as follows to facilitate automatic minutes creation, as follows:¶

• After the conclusion of the meeting, automatically retrieve the transcript and make it available to the chairs as candidate minutes. Chairs can either approve the minutes, correct or annotate them as they see fit, and publish them.¶

• Make the automatically-generated transcript available for download from the proceedings page in the datatracker.¶

• Augment the transcript generation function to add the speaker's identity as determined by the state of the microphone queue (for local participants) or the active speaker (for remote participants).¶

In addition, there is a need for working group chair training to ensure the consistency of minutes across working groups. i.e. The chairs should manage the queue in such a manner that the head of the queue accurately reflects the active speaker.¶

4. Security Considerations

Because the transcript is automatically generated, an attacker might attempt to produce input which would cause the transcript to incorrectly reflect the actual meeting, via adversarial input attacks [ADVERSARIALSPEECH]. This is mitigated by (1) having the chairs review the transcript (2) the existence of session recordings which can be directly reviewed.¶

5. IANA Considerations

This document has no IANA actions.¶

6. References

Authors' Addresses