idnits 2.17.1 draft-ietf-shmoo-cancel-meeting-04.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 (10 June 2021) is 1050 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 shmoo M. Duke 3 Internet-Draft F5 Networks, Inc. 4 Intended status: Best Current Practice 10 June 2021 5 Expires: 12 December 2021 7 Considerations for Cancellation of IETF Meetings 8 draft-ietf-shmoo-cancel-meeting-04 10 Abstract 12 The IETF holds three in-person meetings per year to discuss and 13 understand issues. However, various emergencies can make a planned 14 in-person meeting infeasible. This document provides criteria for 15 making this judgment. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the mailing list 22 (shmoo@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/browse/shmoo/. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/martinduke/draft-ietf-shmoo-cancel-meeting. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 12 December 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Decision Criteria and Roles . . . . . . . . . . . . . . . . . 3 64 3.1. IETF LLC . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. IESG and IRTF Chair . . . . . . . . . . . . . . . . . . . 5 66 4. Remedies . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Relocation . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Virtualization . . . . . . . . . . . . . . . . . . . . . 6 69 4.3. Postponement . . . . . . . . . . . . . . . . . . . . . . 6 70 4.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Refunds . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 76 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 8 77 B.1. Since draft-ietf-shmoo-cancel-meetings-03 . . . . . . . . 8 78 B.2. Since draft-ietf-shmoo-cancel-meetings-02 . . . . . . . . 8 79 B.3. Since draft-ietf-shmoo-cancel-meetings-01 . . . . . . . . 8 80 B.4. Since draft-ietf-shmoo-cancel-meetings-00 . . . . . . . . 9 81 B.5. Since draft-duke-shmoo-cancel-meetings-01 . . . . . . . . 9 82 B.6. Since draft-duke-shmoo-cancel-meetings-00 . . . . . . . . 9 83 B.7. Since draft-duke-remote-meetings-00 . . . . . . . . . . . 9 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 Among the highlights of the IETF calendar are in-person general 89 meetings, which happen three times a year at various locations around 90 the world. 92 Various major events may affect the suitability of a scheduled in- 93 person IETF meeting, though for some this may not be immediately 94 obvious. For example: 96 * A meeting venue itself may unexpectedly close or otherwise be 97 unable to meet IETF meeting requirements due to a health issue, 98 legal violation, or other localized problem. 100 * A natural disaster could degrade the travel and meeting 101 infrastructure in a planned location and make it unethical to 102 further burden that infrastructure with a meeting. 104 * War, civil unrest, or public health crisis could make a meeting 105 unsafe and/or result in widespread national or corporate travel 106 bans. 108 * An economic crisis could sharply reduce resources available for 109 travel. 111 * Changes in visa policy or other unexpected governmental 112 restrictions might make the venue inaccessible to numerous 113 attendees. 115 This document provides criteria to aid the IETF Administration LLC 116 (LLC) in deciding to postpone, move, or cancel an in-person IETF 117 meeting. 119 2. Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 In this document, the term "venue" refers to both the facility that 128 houses the sessions and the official meeting hotel(s). 130 3. Decision Criteria and Roles 132 The LLC assesses whether an in-person meeting is logistically and 133 financially viable in light of events, and assembles information 134 about various travel restrictions that might impact attendance. The 135 Internet Engineering Steering Group (IESG) and Internet Research Task 136 Force (IRTF) Chair assess if the projected attendance is sufficient 137 for a viable in-person meeting. 139 3.1. IETF LLC 141 The LLC is responsible for assessing the suitability of a venue for 142 an IETF meeting and is responsible for any reassessment in response 143 to a major event that leaves the prior conclusion in doubt. If such 144 an event occurs more than twelve weeks before the start of the 145 scheduled meeting, it is deemed a non-emergency situation. Later 146 events, up to and including the week of a meeting itself, are deemed 147 an emergency situation. 149 In non-emergency situations, if the LLC determines the scheduled 150 meeting clearly cannot proceed (e.g., the venue has permanently 151 closed), then it MUST consult with the community on the reason(s) and 152 its proposed remedy. In less clear cases, the LLC SHOULD conduct a 153 formal reassessment process that includes: 155 * Consulting with the community on the process timetable. 157 * Consulting with the community on criteria to assess the impact of 158 new developments. 160 * Consulting with the community on the form of the assessment 161 report. 163 * Publishing an assessment report and recommended remedy. 165 * Seeking approval of the IESG for the recommendation. 167 In emergency situations, which lack the time for a consultation 168 process, this document provides criteria that have IETF consensus and 169 which the LLC MUST apply in its assessment. 171 The LLC will collect information about the likely impact to in-person 172 attendance of national travel advisories, national and corporate 173 travel bans, quarantine requirements, etc. and report the results to 174 the IESG. 176 These criteria, some of which are derived from Section 3 of 177 [RFC8718], apply to venues that are re-evaluated due to an emergency: 179 * Local safety guidelines allow the venue and hotels to host a 180 meeting with the expected number of participants and staff. 182 * It MUST be possible to provision Internet Access to the Facility 183 and IETF Hotels that allows those attending in person to utilize 184 the Internet for all their IETF, business, and day-to-day needs; 185 in addition, there must be sufficient bandwidth and access for 186 remote attendees. Provisions include, but are not limited to, 187 native and unmodified IPv4 and IPv6 connectivity, and global 188 reachability; there may be no additional limitation that would 189 materially impact their Internet use. To ensure availability, it 190 MUST be possible to provision redundant paths to the Internet. 192 * A reasonable number of food and drink establishments are open and 193 available within walking distance to provide for the expected 194 number of participants and staff. 196 * Local health and public safety infrastructure should expect to 197 have adequate capacity to support an influx of visitors during the 198 meeting week. 200 Finally, the LLC MUST assess the impact on its own operations, 201 including: 203 * The number of critical support staff and contractors who can be at 204 the venue. 206 * The financial impact of continuing a meeting, or implementing any 207 of the possible remedies. 209 The LLC SHOULD cancel a meeting if it judges a meeting to be 210 logistically impossible or inconsistent with its fiduciary 211 responsibilities. 213 In the event of considerations this document does not foresee, the 214 LLC should protect the health and safety of attendees and staff, as 215 well as the fiscal health of the organization, with approval from the 216 IESG and a plan to seek a later update of this document. 218 3.2. IESG and IRTF Chair 220 If the LLC assesses there are no fundamental logistical or financial 221 obstacles to holding a meeting in an emergency situation, the IESG 222 and IRTF Chair assess if projected attendance is high enough to 223 achieve the benefit of an in-person meeting. 225 The IESG is discouraged from relying on a simple head count of 226 expected meeting attendance. Even dramatically smaller meetings with 227 large remote participation may be successful. In addition to the 228 LLC's estimate, the IESG might consider: 230 * Are many working groups and research groups largely unaffected by 231 the restrictions, so that they can operate effectively? 233 * Is there a critical mass of key personnel at most working group 234 meetings to leverage the advantages of in-person meetings, even if 235 many participants are remote? 237 4. Remedies 239 If a meeting cannot be held at the scheduled time and place, the LLC 240 and IESG have several options. The remedies in this section should 241 be considered in light of four principles, presented in no particular 242 order: 244 * Hold the scheduled sessions of a meeting in some format. 246 * Provide benefits of in-person interactions when possible. 248 * Avoid exorbitant additional travel expenses due to last minute 249 flight changes, etc. 251 * Ensure the available time and resources allow the alternative to 252 be adequately prepared. 254 4.1. Relocation 256 For attendees, the least disruptive response is to retain the meeting 257 week but move it to a more accessible venue. To the maximum extent 258 possible, this will be geographically close to the original venue. 259 In particular, the LLC SHOULD strive to meet the criteria in 260 [RFC8718] and [RFC8719]. 262 Relocation that requires new air travel arrangements for attendees 263 SHOULD NOT occur less than one month prior to the start of the 264 meeting. 266 4.2. Virtualization 268 The second option, and one that has fewer issues with venue 269 availability, is to make a meeting fully remote. This requires 270 different IETF processes and logistical operations that are outside 271 the scope of this document. 273 4.3. Postponement 275 Although it is more disruptive to the schedules of participants, the 276 next best option is to delay a meeting until a specific date, at the 277 same venue, at which conditions are expected to improve. The new end 278 date of a meeting must be at least 30 days before the beginning of 279 the following IETF meeting, and a meeting must begin no earlier than 280 1 month after the postponement announcement. 282 Due to scheduling constraints at the venue, this will usually not be 283 feasible. However, it is more likely to allow attendees to recover 284 at least some of their travel expenses than other options. 286 Note that it is possible to both postpone and relocate a meeting, 287 though this has the disadvantages of both. 289 4.4. Cancellation 291 As a last resort, the LLC and IESG may cancel a meeting entirely. 292 This is a last resort in the event that worldwide conditions make it 293 difficult for attendees to even attend remotely. Not holding a 294 meeting at all can have wide implications, such as the nomination 295 process and seating of new officers. 297 Cancellation is likely the only practical alternative when 298 emergencies occur immediately before or during a meeting, so that 299 there is no opportunity to make other arrangements. 301 5. Refunds 303 The IETF SHOULD NOT reimburse registered attendees for unrecoverable 304 travel expenses (airfare, hotel deposits, etc). 306 However, there are several cases where full or partial refund of 307 registration fees is appropriate: 309 * Cancellation SHOULD result in a full refund to all participants. 310 It MAY be prorated if some portion of the sessions completed 311 without incident. 313 * Upon postponement, the LLC SHOULD offer refunds to registered 314 attendees who claim they cannot attend at the newly scheduled 315 time. 317 * When a meeting becomes remote, the LLC SHOULD attempt to recover 318 whatever venue-related payments, past or future, it can and rebate 319 this to registered attendees, up to a maximum of their total cost 320 of registration. 322 * The LLC SHOULD offer refunds to attendees whose nation of 323 residence forbids, or has issued a safety advisory against, visits 324 to the host venue, even if the in-person meeting will continue. 325 It SHOULD NOT refund cancellations due to employer policy or 326 personal risk assessments. 328 These provisions intend to maintain trust between the IETF and its 329 participants. However, under extraordinary threats to the solvency 330 of the organization, the LLC may suspend them. 332 6. Security Considerations 334 This document introduces no new concerns for the security of internet 335 protocols. 337 7. IANA Considerations 339 There are no IANA requirements. 341 8. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 349 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 350 May 2017, . 352 [RFC8718] Lear, E., Ed., "IETF Plenary Meeting Venue Selection 353 Process", BCP 226, RFC 8718, DOI 10.17487/RFC8718, 354 February 2020, . 356 [RFC8719] Krishnan, S., "High-Level Guidance for the Meeting Policy 357 of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719, 358 February 2020, . 360 Appendix A. Acknowledgments 362 Appendix B. Change Log 364 B.1. Since draft-ietf-shmoo-cancel-meetings-03 366 * Clarifications from AD review 368 B.2. Since draft-ietf-shmoo-cancel-meetings-02 370 * Added IRTF to IESG responsibilities 372 * WGLC Nits 374 B.3. Since draft-ietf-shmoo-cancel-meetings-01 375 * Added refund principles for hybrid meetings 377 B.4. Since draft-ietf-shmoo-cancel-meetings-00 379 * Jay Daley's nits 381 * Distinguish the emergency and non-emergency process 383 * Eliminated USSTATE/UKFO references 385 * Clarified roles of LLC and IESG 387 B.5. Since draft-duke-shmoo-cancel-meetings-01 389 * Change to WG draft 391 B.6. Since draft-duke-shmoo-cancel-meetings-00 393 * Added mention of IRTF 395 * Discussed consensus on cancellation 397 B.7. Since draft-duke-remote-meetings-00 399 * Defined "venue" 401 * Added principles for selecting remedies and rewrote alternatives. 403 * Added local authority travel advisories 405 * Added some criteria from IETF 109 407 Author's Address 409 Martin Duke 410 F5 Networks, Inc. 412 Email: martin.h.duke@gmail.com