1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
|
Internet Engineering Task Force (IETF) M. Kühlewind
Request for Comments: 9400 Ericsson
Category: Informational M. Duke
ISSN: 2070-1721 Google
June 2023
Guidelines for the Organization of Fully Online Meetings
Abstract
This document provides guidelines for the planning and organization
of fully online meetings, regarding the number, length, and
composition of sessions on the meeting agenda. These guidelines are
based on the experience gained by holding online meetings during the
COVID-19 pandemic in 2020 and 2021.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
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 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
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' Addresses
1. Introduction
In 2020, the COVID-19 pandemic forced the IETF to convert all its
plenary meetings to online-only events. This document records the
experience gained by holding plenary meetings fully online and
proposes guidelines based on this experience. In general,
participant surveys indicated satisfaction with the organization of
these meetings.
Although these guidelines reflect lessons learned in 2020 and 2021,
the IETF is encouraged to continue to experiment with the format and
agenda of fully online meetings, using this document as a baseline.
Hybrid meetings (meaning meetings that have large remote
participation but also onsite participation) are out of scope.
However, some of the experience gained from fully online meetings
might also provide input for decisions regarding the organization of
hybrid meetings.
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 document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the term "plenary meeting" for the whole IETF
meeting that covers the IETF meeting week; this term is used to
distinguish the plenary meeting from other IETF meetings like
"interim meetings". The term "administrative plenary" is used for
the respective session during the IETF meeting week that is usually
hosted on Wednesday.
2. Some History
When the World Health Organization (WHO) declared a worldwide
pandemic in March 2020, the IETF canceled its plenary meeting and
organized an online replacement in less than 2 weeks. For this first
online-only meeting, the agenda was reduced to a set of sessions that
benefited most from cross-area participation, like BoFs, first-time
meetings of new working groups, and dispatch sessions. It also
included the administrative plenary to preserve the official handover
procedures that occur at March IETF meetings, as described in
[RFC8713].
With a reduced agenda, the meeting format was two sessions (about 4
hours) per day with a maximum of two parallel tracks. Other working
group meetings were scheduled as interims over the following 6 weeks.
The IESG published a purely advisory recommended schedule
[INTERIM-SCHEDULE] to reduce conflicts among those interims.
While satisfaction was high right after the meeting
[IETF107-FEEDBACK], some participants later indicated in mailing list
discussions that the period of intensive interims had a greater
impact on their calendar than a single plenary meeting week, and in
some meetings participation was reduced. Those interims tended to
occur at times convenient for the bulk of participants, which was
convenient for most but could exclude those in less common time
zones.
For the remainder of 2020 and 2021, the online schedule was switched
back to be similar to an in-person meeting (1- to 2-hour slots and
eight or nine parallel tracks). However, each day was limited to 5-6
hours in recognition that remote participation is more tiring.
All fully online meetings followed the time zone of the planned in-
person meeting location. As a 6-hour agenda has some flexibility
regarding the start time while still fitting within a previously used
8-hour in-person agenda, the start time was approximately noon, with
adjustments of an hour or so to mitigate the impact of early morning
hours in time zones with many participants. As selection of in-
person meeting sites was consistent with the 1-1-1 guideline as
documented in [RFC8719], this approach was intended to share the
burden across all common geographies roughly equally.
3. Guidelines for Online Meeting Planning
3.1. Time Zone Selection
The following algorithm was not used in 2020 or 2021, but it enables
most participants to avoid late-night sessions in two out of every
three fully online IETF plenary meetings. Basically, every fully
online meeting is for two regions of the three regions described in
[RFC8719], with one being roughly after sunrise and the other around
sundown. This has the trade-off that the third region is in the
middle of night.
The times are also seasonally adjusted to leverage differentials in
Daylight Saving Time. These time slots are as follows, 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
Note that the "Europe Night" slot covers the "early morning" slot for
Asia where most countries do not have Daylight Saving Time.
If Daylight Saving Practices change -- this change is under
consideration in multiple countries at the time of publication --
this table may need adjustment.
The intent of rotating between these three slots is to scatter
meetings throughout the course of the global day, to maximize the
ease of participants so that no attendee has to be consistently
inconvenienced, regardless of their location and what time of day is
optimal for their schedule. However, as participation is distributed
globally, it needs to be acknowledged that restricting the scheme to
three regions observes the intent of [RFC8719] but does not achieve
the goal of two non-late-night sessions for all participants 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 following table covers all
permutations of previous meetings held in person in Region A, B, or C
or remotely in 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:
1) Whenever a fully online meeting follows an in-person meeting, the
online meeting time is used that most disadvantages the
participants in the time zone where the in-person meeting was
held.
2) If multiple fully online meetings follow each other, the time
zone selection should be rotated based on the most recent time
zones in which the in-person meetings were held.
The final case occurs in the rare event that back-to-back in-person
plenary meetings occur in the same region. In this case, find the
most recent meeting that was in neither 'A' (if in person) nor 'A
Night' (if fully online). If this meeting was in person in region
'B', then 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
By 2021, fully online meetings were consistently held over 5 days
with roughly 6-hour meeting days. The day with the administrative
plenary, which concludes with multiple open mic sessions, sometimes
exceeded this limit.
Six hours of online meetings, with two 30-minute breaks, was a
compromise between the physical limits of attending an online meeting
in an inconvenient time zone and the demand for many sessions with a
manageable number of conflicts. The IETF 109 feedback
[IETF109-SURVEY] indicated broad satisfaction with a 5-day meeting
but only medium satisfaction with the overall length of each day.
The IETF did not seriously consider extending sessions into the
weekend before or after the main meeting week, although at IETF 108
and subsequent meetings the Hackathon occupied the entire week before
(see [RFC9311]).
3.3. Session/Break Length
For fully online meetings, there are typically fewer sessions per day
than for in-person meetings, to keep the overall meeting day to
roughly 6 hours. With fewer sessions, chairs were offered only two
options for session length (instead of three).
IETF 108, based on an indicated preference of the community,
scheduled 50- and 100-minute slots, with 10-minute breaks, in order
to keep the overall day length at 5 hours. This resulted in many
sessions going over time, which indicated 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, and a
significant improvement in satisfaction over IETF 108.
The longer breaks, while extending the day, provided adequate time
for meals, exercise, and "hallway" conversations using online tools.
3.4. Number of Parallel Tracks
In-person meetings are limited in the number of parallel tracks by
the number of meeting rooms, but online meetings are not. However,
more parallel tracks would increase the number of possible agenda
conflicts.
If the total number of requested sessions exceeds the capacity of the
usual eight parallel tracks, it is possible for a fully online
meeting to simply use more tracks. If the number and length of
meeting days are seen as fixed, this decision is implicitly made by
the working group chairs requesting a certain number of sessions and
length.
IETF 111 used nine parallel tracks for some of the sessions and
experienced slightly more conflicts in the agenda-scheduling process,
though there was no statistically significant increase in
dissatisfaction about conflicts in the survey [IETF111-SURVEY].
The IESG encouraged working group chairs to limit their session
requests and 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 about the
structure of that meeting (full meeting) compared to that of IETF
107, which hosted only a limited set of sessions followed by interims
in the weeks after. The structure of IETF 108 was preferred by 82%.
Respondents valued cross-participation and an intensive meeting week
for maintaining project momentum.
Furthermore, a well-defined meeting time, rather than spreading many
interims over the whole year, can make deconflicting with other non-
IETF meetings easier.
However, interim meetings can also help to reduce scheduling
conflicts during an IETF week and allow for a more optimal time slot
for the key participants. While interim meetings are less likely to
attract people with casual interest, they provide a good opportunity
for the most active participants of a group to have detailed
technical discussions and solve recorded issues efficiently.
4.2. Flexibility of Time Usage
This document recommends further experiments with reducing conflicts
by leveraging the increased flexibility of the online format.
An in-person meeting must fit all sessions into an acceptable length
for international travel (usually roughly a week), but online
meetings do not have that constraint.
Therefore, it would be possible to keep most regular working group
sessions within the usual 5 main meeting days but have some of the
more conflicted sessions in other dedicated time slots. As the
Hackathon for fully online meetings is usually held in the week
before the online plenary meeting [RFC9311], that week is already a
highly active week for many IETF participants and might provide an
opportunity to schedule a few selected sessions.
This might work especially well for sessions that are of high
interest to a large part of the community, such as BoFs and dispatch
meetings, and therefore 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 a reduction in scheduling conflicts but also a slight drop in
attendance of 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 indicates that online meetings support a more consistent
geographic distribution of participants than in-person meetings,
where participation often fluctuates based on the location.
However, online meetings do not provide an equivalent opportunity to
socialize. Despite significant investment in tools to foster hallway
conversations, many did not use those tools, whether due to ignorance
of them, dislike of the tools, or a preference for 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, although the overall number of draft
submissions remained stable; this decrease in new submissions might
have resulted from the loss of these interactions. Informal
conversations might be important to inspire new work.
4.4. Experiments
This document recommends further experiments with the meeting
structure. Often, only practical experience can answer open
questions. A given meeting SHOULD only experiment with one major
change at a time in order to be able to assess the outcome correctly.
Furthermore, the IESG SHOULD announce any such experiment well in
advance, so people can adjust to changes and potentially provide
feedback.
4.5. IANA Considerations
This document has no IANA actions.
4.6. Security Considerations
This document has no security considerations.
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
|