idnits 2.17.1 draft-richardson-shmoo-how-many-fine-dinners-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (19 October 2020) is 1278 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8174' is defined on line 299, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 shmoo Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Best Current Practice 19 October 2020 5 Expires: 22 April 2021 7 How often and how long should IETF virtual meetings be? 8 draft-richardson-shmoo-how-many-fine-dinners-01 10 Abstract 12 This document recommends a model for IETF virtual meetings that 13 emphasizes new work, community building and cross-area concerns. 15 This document recommends virtual meetings be planned a reduced amount 16 of overlap among sessions, with short sessions with generous gaps. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 22 April 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. IETF 107 experience . . . . . . . . . . . . . . . . . . . 2 53 1.2. IETF 108 experience . . . . . . . . . . . . . . . . . . . 3 54 2. Suggestions for future meetings . . . . . . . . . . . . . . . 3 55 2.1. Principles for for Recommendations . . . . . . . . . . . 3 56 2.2. Recommendations on meeting structure . . . . . . . . . . 4 57 2.2.1. Encourage Virtual Interim meetings for ongoing 58 work . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2.2. Allow IETF Virtual meeting week to focus on 60 community-wide activities . . . . . . . . . . . . . . 5 61 2.2.3. Number of Tracks for virtual meetings . . . . . . . . 5 62 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 IETF107 was the first pandemic IETF virtual meeting held in March 72 2020. IETF108 was the second pandemic IETF virtual meeting held in 73 July 2020. 75 1.1. IETF 107 experience 77 IETF107 consisted of a light week with no more than about 4-hours of 78 sessions over Monday to Thursday. There were multiple tracks 79 simultaneously, but not more three sessions at any one time. 80 Priority was given to newly formed WGs that had not yet met, to Birds 81 of a Feather session, and to cross-community sessions including 82 specifically "dispatch" sessions. 84 These sessions were done with XXXX (webex? right?) 86 The timezone was approximately "Vancouver"-ish. Most sessions 87 started in late morning, which turned into mid-evening in Europe 88 (going into midnight), and middle of the night in Asia. 90 All other WGs were assigned a day in the weeks following IETF107 from 91 March 30 to April 30. The WGs were asked to pick a time (and time 92 zone) convenient to them, and they scheduled webex meetings on 93 "ietf.webex.com", although a few WG chairs decided to use "Zoom". 94 Many meetings occured in the North-America/Europe optimal time slot 95 of 1500UTC ("10am EDT"). 97 Despite the "pick a time", a small number of WGs managed to pick 98 times when other WGs were meeting, and there were in fact collisions. 100 IETF 107 would be best described as a marathon rather than a sprint. 102 1.2. IETF 108 experience 104 IETF108 consisted of a very heavy week. 106 Eight simultaneous tracks were scheduled, although with slightly 107 shorter meeting times of 50 minutes and 100 minutes. The plenary 108 occured at the normal Wednesday afternoon time, and other constants 109 like "saag" being on Thurdsay afternoon were also maintained. 111 The day started in late-morning "Madrid" (Central Enropean) time and 112 ended before dinner time. The longest break was a 30 minute break 113 after the first session. Other breaks were in the 10 minute range. 115 This accomodated East-coast North-Americans, but Pacific coast 116 participants had to get up for 4am. The schedule accomodated those 117 in Asia slightly better, but it was still middle of the night in New- 118 Zealand for all but the first sessions. 120 All WG sessions used meetecho with additional features having been 121 added to support things like humming, and some slightly better queue 122 management. 124 Many participants experienced a typical number of conflicts. See, 125 for instance https://mailarchive.ietf.org/arch/msg/suit/ 126 OcyNDcssHW8NUrCxGMzCJMX73_M/ 128 Some WGs declined to schedule meetings at IETF108. This was due to a 129 combination of scheduling, timezones and the fee to attend. WGs that 130 did this usually had a healthy and regular set of virtual interim 131 meetings that were ongoing. 133 IETF 108 would be best described as a sprint. 135 2. Suggestions for future meetings 137 2.1. Principles for for Recommendations 139 There is great utility in having all of the IETF members present and 140 available together. Doing this in-person has many great benefits 141 (and many costs internal and external), not enumerated here. 143 An unconstrained meeting with few conflicts and a few empty slots in 144 each individual schedule maximizes the benefit of the togetherness. 145 Some call it Working-Group "tourism", others call it "impromptu 146 cross-area review", but there are significant benefits to having 147 "bored" participants with time on their hands wander into a WG to 148 which they have little knowledge. 150 To be fair, there is some significant negative experience with mic 151 comments like, "I haven't read the document, but..." 153 Yes, often these comments _do_ lead to significant amounts of 154 friction. Time wasted at the mic explaining that that were covered 155 in the document. 157 Sometimes, though, they lead to an understanding that two WGs are 158 facing the same issues, and that they should work together. And 159 getting this understanding is really quite valuable. 161 This is _PARTICULARLY_ the case for new work (BOFs), and for the 162 first few meetings of a newly formed WG. One of the important thing 163 for many individuals to internalize what the boundaries of the new 164 work is, and what the overlap with the work they are doing is. This 165 often comes about from the discussions that go around slide ware, to 166 seeing who else cares about this work, and why. 168 Heavily conflicted (physical) meeting schedules have been a growing 169 issue, with the result that many people do not have the time (due to 170 conflicts), or the energy (due to exhaustion) to pay attention to the 171 new work. 173 2.2. Recommendations on meeting structure 175 2.2.1. Encourage Virtual Interim meetings for ongoing work 177 This document therefore recommends that the IETF encourage a healthy 178 growth of virtual interim meetings which are: 180 1. heavily focused. 182 2. frequent participant-time-zone optimized 184 3. typically occur at twice-monthly to monthly intervals appropriate 185 for getting work done. 187 2.2.2. Allow IETF Virtual meeting week to focus on community-wide 188 activities 190 While the IETF mission statement is very outcome focused, that 191 doesn't mean that every activity needs to be only outcome focused. I 192 think that the IETF "plenary" meeting times should be arranged to not 193 just permit, but encourage cross-working-group participation. 195 This document suggests that the IETF virtual meeting week be focused 196 on: 198 1. governance and meta-activites like IESG, IAB, NOMCOM 200 2. *DISPATCH activities 202 3. BOFs for new work 204 4. newly formed WG meetings, 206 5. maybe WGs who have gone through some major milestone, and are for 207 instance, rechartering 209 Rather than attempt to compress the schedule down so that the time 210 between the beginning of the day and the end of the day is as short 211 as possible, we should instead arrange the schedule with generous 212 break intervals to accomodate adhoc 1:1 or rather-small-group 213 meetings. 215 That is, the "hallway session" needs some time and space to be 216 useful. 218 In particular, having some gaps where a person can reasonably expect 219 to track down someone else to chat about a specific thing, or just to 220 catch up. 222 We used to stimulate the "hallway" discussion using cookies and 223 beverages. 225 Often this is the best way to talk though DISCUSSes among ADs and 226 document authors. 228 Those that used the gather.town system, found it was exceptionally 229 useful for this. 231 2.2.3. Number of Tracks for virtual meetings 233 This document recommends that we have fewer tracks. Somewhere 234 between two and four. 236 That is, like IETF108 and more like IETF107. A few more tracks, and 237 slightly longer days. 239 This document does not recommend that the schedule be adjusted to 240 accomodate all the time zones. Because of where the Pacific Ocean 241 is, that pretty much always puts noon somewhere near Greenwich. 243 The 1-1-1-* process should mean that the locale chosen for the 244 cancelled physical meeting defines the time zone. Participants 245 should be expected to "travel" to that time zone: many physical trips 246 take 24 to 36 hours of airplane time, and asking participants to take 247 a similiar amount of time to adjust their body clocks is not 248 unreasonable. 250 Once a year, the participants will find they have to do almost no 251 adjustment, when the meeting is "near" them. 253 Meetings should be restricted to between a 4 and 7 day period though, 254 which gives them some time to adjust before "returning" to work the 255 next week. 257 Historical meetings have accomodated in excess of 200 hours of 258 session time. (Eight hours/day X 4.5 days X eight tracks = 288 259 hours, minus some for the plenary). 261 The virtual meeting should restrict itself to approximately 100 hours 262 of session time. 6 sessions of 50 minutes, with ~30 minute breaks 263 between, over 4 tracks, and over 4 days gives 90 hours of session 264 time. This calculation does not count time for a plenary where there 265 is only one track. This formula is intended to be a guideline only. 267 Note that for many, conflicts mean that they have to view the session 268 after the fact via Youtube. While the "play back at 2x speed" can be 269 effective for some listeners, this can result in significant number 270 of extra hours of time for the meeting. 272 Rather than compete for available plenary-week WGs slots, WGs should 273 compete to demonstrate that they don't need a slot. 275 Having a plenary-week slot should mean that additional "supervision" 276 is required :-) Either because the WG is very new, or because the WG 277 is old and has lost it's way. 279 3. Security Considerations 281 The excessive use of caffeine and sugar to adjust jet lag may have 282 health effects on the participants. In addition, there is some 283 possibility that decisions made under such influence might negatively 284 affect the security of the Internet. Multiple reviews after periods 285 of "sober second thought" should catch any such poor decisions. 287 4. IANA Considerations 289 This document makes no requests to IANA. 291 5. Acknowledgements 293 YOUR NAME HERE. 295 6. Changelog 297 7. Normative References 299 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 300 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 301 May 2017, . 303 Author's Address 305 Michael Richardson 306 Sandelman Software Works 308 Email: mcr+ietf@sandelman.ca