RFC 9400
Guidelines for the Organization of Fully Online Meetings
RFC 9400: Guidelines for the Organization of Fully Online Meetings 🎀
Okay bestie, RFC 9400 is literally called Guidelines for the Organization of Fully Online Meetings ✨ It's an IETF doc, so it's the Internet's standards crew sharing how to plan online-only meetings 💻 Here's the title-block tea:
- Authors: M. Kühlewind (Ericsson) and M. Duke (Google) 💜
- Category: Informational 🦋 (not a standard, just useful info)
- ISSN: 2070-1721
- Date: June 2023 🌸
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈
Abstract ✨
This doc gives you guidelines for planning fully online meetings, like how many sessions to have, how long they should run, and what goes into the agenda 📅 It's all based on what happened when the IETF held online meetings during COVID-19 in 2020 and 2021 🦠💅
Status of This Memo 📝
Bestie, this doc is not an Internet Standards Track spec. It's published just to share info 🧚
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 for that 🔍
For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9400 💌
Copyright Notice 🌈
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date 📜 Please actually read those, because they spell out your rights and restrictions for this doc. Any Code Components pulled out of this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 🔥
Table of Contents 🗂️
1. Introduction
1.1. Requirements Language
2. Some History
3. Guidelines for Online Meeting Planning
3.1. Time Zone Selection
3.1.1. Guidelines for Selection
3.2. Number of Days and Total Hours per Day
3.3. Session/Break Length
3.4. Number of Parallel Tracks
4. Additional Considerations and Recommendations
4.1. Full vs. Limited Agenda (and Interim Meetings)
4.2. Flexibility of Time Usage
4.3. Inclusivity and Socializing
4.4. Experiments
4.5. IANA Considerations
4.6. Security Considerations
5. References
5.1. Normative References
5.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction ✨
Okay so, in 2020 COVID-19 forced the IETF to turn all its plenary meetings into online-only events 😭 This doc records what that experience was like and proposes guidelines based on it 💅 Overall, participant surveys showed people were happy with how these meetings were organized 🥰
Even though these guidelines come from lessons learned in 2020 and 2021, the IETF is encouraged to keep experimenting with the format and agenda of fully online meetings, using this doc as a starting baseline 🦋
Hybrid meetings (meaning meetings with lots of remote participation and onsite participation) are out of scope 🙅♀️ That said, some of what we learned from fully online meetings might still help when deciding how to run hybrid ones 🧠
1.1. Requirements Language 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like here 🎀
This doc uses "plenary meeting" to mean the whole IETF meeting week 🗓️ That term helps tell it apart from other IETF meetings, like "interim meetings" 🦋 The "administrative plenary" is the session during the meeting week that's usually hosted on Wednesday 💜
2. Some History 📜
So when the World Health Organization (WHO) declared a worldwide pandemic in March 2020, the IETF canceled its plenary meeting and put together an online replacement in less than 2 weeks 😱 For that first online-only meeting, the agenda got trimmed down to the sessions that benefited most from cross-area participation 🫶 Think BoFs, first-time meetings of new working groups, and dispatch sessions ✨ It also kept the administrative plenary, so the official handover procedures from March IETF meetings could still happen, as described in [RFC8713] 🔁
With that smaller agenda, the meeting ran two sessions (about 4 hours) per day, with a max of two parallel tracks 🌸 The other working group meetings got scheduled as interims over the next 6 weeks 🗓️ The IESG put out a purely advisory recommended schedule [INTERIM-SCHEDULE] to help cut down on conflicts between those interims 🙏
Satisfaction was super high right after the meeting [IETF107-FEEDBACK] 🥰 But later, some participants said in mailing list discussions that the stretch of intense interims hit their calendars harder than one plenary week did 😩 In some meetings, participation actually dropped 📉 The interims also tended to land at times that were convenient for most of the crowd, which worked for most people but could leave out folks in less common time zones 🌍
For the rest of 2020 and 2021, the online schedule went back to looking like an in-person meeting, with 1- to 2-hour slots and eight or nine parallel tracks 🧩 But each day got capped at 5-6 hours, because remote participation is more tiring 😴 Honestly, that makes sense 💅
All fully online meetings followed the time zone of the planned in-person meeting location 🕐 A 6-hour agenda has some wiggle room on start time and still fits inside a previously used 8-hour in-person agenda, so the start time was about noon, shifting by an hour or so to ease the early mornings in time zones with lots of participants 🌅 Since in-person meeting sites were picked to follow the 1-1-1 guideline in [RFC8719], this approach was meant to spread the burden roughly equally across all common geographies 🌏💖
3. Guidelines for Online Meeting Planning 🗺️
3.1. Time Zone Selection ⏰
The algorithm below wasn't used in 2020 or 2021 🙈 But it lets most participants dodge late-night sessions in two out of every three fully online IETF plenary meetings 🌙 Basically, every fully online meeting is for two of the three regions described in [RFC8719], with one region getting roughly after-sunrise time and the other getting around sundown 🌅 The trade-off is that the third region ends up in the middle of the night 😬
The times are also seasonally adjusted to take advantage of differences in Daylight Saving Time 🍂❄️ Here are the slots in UTC, based on the Daylight Saving Practices at the time of publication 📅
+===============+=========================+=========================+
| Name | Times (Northern Summer) | Times (Northern |
| | | Winter) |
+===============+=========================+=========================+
| North America | 0500-1100 UTC | 0600-1200 UTC |
| Night | | |
+---------------+-------------------------+-------------------------+
| Asia Night | 1300-1900 UTC | 1400-2000 UTC |
+---------------+-------------------------+-------------------------+
| Europe Night | 2200-0400 UTC | 2200-0400 UTC |
+---------------+-------------------------+-------------------------+Table 1 🧁
Quick heads-up: the "Europe Night" slot covers the "early morning" slot for Asia, where most countries don't have Daylight Saving Time 🌏
If Daylight Saving Practices change (and that's being considered in multiple countries at the time of publication), this table may need an update 🔄
The whole point of rotating between these three slots is to scatter meetings across the global day 🌎 That way, no attendee has to be consistently inconvenienced, no matter where they are or what time of day works best for their schedule 💕 Real talk though: since participation is spread out globally, limiting the scheme to three regions follows the intent of [RFC8719], but it doesn't fully hit the goal of giving everyone two non-late-night sessions equally 😤
3.1.1. Guidelines for Selection 🎯
The IETF SHOULD select a start time from these three choices based on the prior three meetings 💅 The table below covers every permutation of previous meetings that were held in person in Region A, B, or C, or remotely during the nights of one of those regions 🗺️
+====================+==================+==============+===========+
| Three Meetings Ago | Two Meetings Ago | Last Meeting | Online |
| | | | Selection |
+====================+==================+==============+===========+
| Any | Any | In-Person A | A Night |
+--------------------+------------------+--------------+-----------+
| Any | Online A Night | Online B | C Night |
| | | Night | |
+--------------------+------------------+--------------+-----------+
| Online A Night | In-Person B | Online B | C Night |
| | | Night | |
+--------------------+------------------+--------------+-----------+
| In-Person A | In-Person B | Online B | A Night |
| | | Night | |
+--------------------+------------------+--------------+-----------+
| In-Person A | In-Person A | Online A | See below |
| | | Night | |
+--------------------+------------------+--------------+-----------+
| Online A Night | Online B Night | Online C | A Night |
| | | Night | |
+--------------------+------------------+--------------+-----------+Table 2 🍓
This table follows two basic guidelines 📋
- Whenever a fully online meeting follows an in-person meeting, use the online meeting time that most disadvantages the participants in the time zone where the in-person meeting was held 😬
- If multiple fully online meetings follow each other, the time zone selection should be rotated based on the most recent time zones where the in-person meetings were held 🔁
The final case is the rare one where back-to-back in-person plenary meetings happen in the same region 😱 In that situation, find the most recent meeting that was in neither 'A' (if in person) nor 'A Night' (if fully online) 🔍 If that meeting was in person in region 'B', the next meeting should be in 'B Night' 🌙 If it was remote in 'B Night', the next meeting should be in 'C Night' 💜
3.2. Number of Days and Total Hours per Day 🗓️
Okay so by 2021, fully online meetings were consistently held over 5 days with roughly 6-hour meeting days 💻. The administrative plenary day, which wraps up with multiple open mic sessions, sometimes went past this limit 😭.
Six hours of online meetings, with two 30-minute breaks, was the sweet spot 🍓. It balanced the real limits of showing up to an online meeting in an inconvenient time zone against the need for lots of sessions with a manageable number of conflicts. The IETF 109 feedback [IETF109-SURVEY] showed broad satisfaction with a 5-day meeting, but only medium satisfaction with how long each day was ✨.
The IETF never really seriously considered extending sessions into the weekend before or after the main meeting week 🙈. Still, starting at IETF 108 and in later meetings, the Hackathon took over the entire week before (see [RFC9311]) 🧚.
3.3. Session/Break Length 🎀
For fully online meetings, there are usually fewer sessions per day than in-person meetings, which keeps the whole meeting day at roughly 6 hours 🌸. With fewer sessions, chairs only got two options for session length instead of three 💅.
IETF 108 went with 50- and 100-minute slots and 10-minute breaks, based on what the community said it preferred, so the overall day could stay at 5 hours ⏰. Here's the tea: lots of sessions ran over time, which showed that 10 minutes for breaks is not practical 💀.
The survey after IETF 109 [IETF109-SURVEY] showed high satisfaction with 60/120-minute session lengths and 30-minute breaks 🦋. Satisfaction also improved a lot compared to IETF 108, which is iconic 👑.
The longer breaks did make the day longer, but they gave people enough time for meals, exercise, and "hallway" conversations using online tools 🫶.
3.4. Number of Parallel Tracks 🌈
In-person meetings are capped on parallel tracks by how many meeting rooms there are, but online meetings aren't capped like that 🏠. Still, more parallel tracks means more chances for agenda conflicts, so it's a balancing act ⚖️.
If the total number of requested sessions is bigger than the usual eight parallel tracks can handle, a fully online meeting can just use more tracks 🧩. If the number and length of meeting days are treated as fixed, then this choice is basically made for you by the working group chairs, who request a certain number of sessions and a certain length 📋.
IETF 111 used nine parallel tracks for some sessions and had slightly more conflicts during agenda scheduling 😬. But the survey [IETF111-SURVEY] showed no statistically significant increase in dissatisfaction about conflicts, so it wasn't a disaster 🙌.
The IESG encouraged working group chairs to limit their session requests and to use interim meetings aggressively for focused work 🔥.
4. Additional Considerations and Recommendations 💜
4.1. Full vs. Limited Agenda (and Interim Meetings) 🍰
The IETF 108 meeting survey [IETF108-SURVEY] asked people about the structure of that meeting (a full meeting) compared with IETF 107, which only hosted a limited set of sessions followed by interims in the weeks after ✨. The full structure of IETF 108 was preferred by 82% 🎉. Respondents valued cross-participation and an intensive meeting week for keeping project momentum going 🚀.
A well-defined meeting time also helps a lot, compared with spreading many interims over the whole year. It can make it easier to avoid clashing with other non-IETF meetings 📅.
Interim meetings do have their own perks, though 💖. They can help reduce scheduling conflicts during an IETF week and give the key participants a more optimal time slot. Interims are less likely to pull in people who are only casually interested, but they're a great chance for the most active participants in a group to have detailed technical discussions and resolve recorded issues efficiently 🫶.
4.2. Flexibility of Time Usage 🦋
This document recommends more experiments with reducing conflicts by taking advantage of the extra flexibility the online format gives us 🌟.
An in-person meeting has to fit all its sessions into a length that makes international travel acceptable (usually about a week) ✈️. Online meetings don't have that constraint, which is a major glow-up 💅.
So it would be possible to keep most regular working group sessions within the usual 5 main meeting days, while putting some of the more conflicted sessions in other dedicated time slots 🧁. The Hackathon for fully online meetings is usually held in the week before the online plenary meeting [RFC9311], which is already a super active week for many IETF participants. It might be a nice opportunity to schedule a few selected sessions 🎀.
This might work especially well for sessions that interest a large part of the community, like BoFs and dispatch meetings. Those are often hard to schedule during the main IETF week 😩.
At IETF 112, the IESG ran an experiment where the administrative plenary was scheduled on the Wednesday before the official session week 🧪. The experiment report [IETF112-EXPERIMENT] found that it led to fewer scheduling conflicts, but also a slight drop in attendance at the administrative plenary, partly due to insufficient awareness 🙈.
4.3. Inclusivity and Socializing 🌸
Participation in the fully online meetings in 2021 was high and had a stable per-country distribution, even though time zones were rotated 🌍. This suggests that online meetings support a more consistent geographic distribution of participants than in-person meetings, where participation often changes depending on the location 💜.
Online meetings still don't give an equivalent chance to socialize, though 😔. Despite significant investment in tools to foster hallway conversations, many people didn't use them. That might be because they didn't know about them, didn't like the tools, or simply preferred other activities at home (including sleep and food) over hallway interactions 🍕😴.
There was a decrease in submissions of new (-00) Internet-Drafts during 2020 and 2021, even though the overall number of draft submissions stayed stable 📉. This decrease in new submissions might have come from losing these interactions. Informal conversations might be important for inspiring new work ✨.
4.4. Experiments 🧪
This document recommends more experiments with the meeting structure 🔬. Honestly, only practical experience can answer a lot of open questions 💡. A given meeting SHOULD only experiment with one major change at a time, so that the outcome can be assessed correctly 🎯. The IESG SHOULD also announce any such experiment well in advance, so people can adjust to changes and potentially give feedback 📣.
4.5. IANA Considerations 📚
This document has no IANA actions.
4.6. Security Considerations 🔐
This document has no security considerations. No drama here, bestie 💅.
5. References 📖
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8719] Krishnan, S., "High-Level Guidance for the Meeting Policy
of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719,
February 2020, <https://www.rfc-editor.org/info/rfc8719>.5.2. Informative References
[IETF107-FEEDBACK]
Daley, J., "IETF 107 Virtual Meeting Survey", 17 April
2020, <https://www.ietf.org/media/documents/ietf-107-
survey-results.pdf>.
[IETF108-SURVEY]
Daley, J., "IETF 108 Meeting Survey", 13 August 2020,
<https://www.ietf.org/blog/ietf-108-meeting-survey/>.
[IETF109-SURVEY]
Daley, J., "IETF 109 Post-Meeting Survey", 7 December
2020,
<https://www.ietf.org/blog/ietf-109-post-meeting-survey/>.
[IETF111-SURVEY]
Daley, J., "IETF 111 post-meeting survey", 23 August 2021,
<https://www.ietf.org/blog/ietf-111-post-meeting-survey/>.
[IETF112-EXPERIMENT]
IESG, "IETF 112 Plenary Experiment Evaluation", 4 February
2022, <https://www.ietf.org/blog/ietf112-plenary-
experiment-evaluation/>.
[INTERIM-SCHEDULE]
Cooper, A., "Subject: Post-IETF-107 Recommended Virtual
Interim Schedule", message to the Working Group Chairs
mailing list, 13 March 2020,
<https://mailarchive.ietf.org/arch/msg/wgchairs/
l382SqKVVHoTzFw9kIYl2boM6_c/>.
[RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,
Confirmation, and Recall Process: Operation of the IETF
Nominating and Recall Committees", BCP 10, RFC 8713,
DOI 10.17487/RFC8713, February 2020,
<https://www.rfc-editor.org/info/rfc8713>.
[RFC9311] Eckel, C., "Running an IETF Hackathon", RFC 9311,
DOI 10.17487/RFC9311, September 2022,
<https://www.rfc-editor.org/info/rfc9311>.Acknowledgments ✨
Thanks to Brian Carpenter, Lars Eggert, Toerless Eckert, Charles Eckel, Jason Livingood, Sanjeev Gupta, Dale Worley, and Mark Nottingham for their reviews 🫶, and thanks to the many other people who provided input and suggestions on the time zone discussion! 💜
Authors' Addresses 💌
Mirja Kühlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com
Martin Duke
Google
Email: martin.h.duke@gmail.com📦 where this page comes from
- ietf: rfc9400 2023-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms