GENWiki

Internet Engineering Task Force (IETF) S. Krishnan Request for Comments: 8719 Kaloom BCP: 226 February 2020 Category: Best Current Practice ISSN: 2070-1721

       High-Level Guidance for the Meeting Policy of the IETF

Abstract

 This document describes a meeting location policy for the IETF and
 the various stakeholders required to realize this policy.

Status of This Memo

 This memo documents an Internet Best Current Practice.

 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).  Further information on
 BCPs is available in 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/rfc8719.

Copyright Notice

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

Table of Contents

 1.  Introduction
 2.  The 1-1-1-* Meeting Policy
 3.  Implementation of the Policy
 4.  Procedure for Initiating Proposals for Exploratory Meetings
 5.  Re-evaluation and Changes to This Policy
 6.  References
   6.1.  Normative References
   6.2.  Informative References
 Acknowledgments
 Author's Address

1. Introduction

 The work of the IETF is primarily conducted on working group (WG)
 mailing lists, while face-to-face WG meetings mainly provide a high-
 bandwidth mechanism for working out unresolved issues.  The IETF
 currently strives to have a 1-1-1 meeting policy where the goal is to
 distribute the meetings equally between North America, Europe, and
 Asia (see "Meeting Location Distribution" (slides 14 and 15) of
 [IETFMEET] for details).  These are the locations from which most of
 the IETF participants have come in the recent past.  This meeting
 rotation is mainly aimed at distributing the travel effort for the
 existing IETF participants who physically attend meetings and for
 distributing the timezone difficulty for those who participate
 remotely.  This policy has been neither defined precisely nor
 documented in an IETF consensus document until now.  This BCP RFC is
 meant to serve as a consensus-backed statement of this policy.

2. The 1-1-1-* Meeting Policy

 Given that the majority of the current meeting participants come from
 North America, Europe, and Asia [CONT-DIST], the IETF policy is that
 the meetings should primarily be held in those regions.  That is, the
 meeting policy (let's call this the "1-1-1" policy) is that meetings
 should rotate between North America, Europe, and Asia.  Note that the
 boundaries between those regions have been purposefully left
 undefined.  It is important to note that such rotation and any
 effects to distributing travel pain should be considered from a long-
 term perspective.  While a potential cycle in an IETF year may be a
 meeting in North America in March, a meeting in Europe in July, and a
 meeting in Asia on November, the 1-1-1 policy does not imply such a
 cycle, as long as the distribution to these regions over multiple
 years is roughly equal.  There are many reasons why meetings might be
 distributed differently in a given year.  Meeting locations in
 subsequent years should seek to rebalance the distribution, if
 possible.

 While this meeting rotation caters to the current set of IETF
 participants, it is important to recognize that due to the dynamic
 and evolving nature of participation, there may be significant
 changes to the regions that provide a major share of participants in
 the future.  Therefore, the 1-1-1-* meeting policy is a slightly
 modified version of the aforementioned 1-1-1 meeting policy that
 allows for additional flexibility in the form of an exploratory
 meeting (denoted with an "*").  Exploratory meetings can be used to
 experiment with exceptional meetings without extensively impacting
 the regular meetings.  For example, these exploratory meetings can
 include meetings in other geographical regions, virtual meetings, and
 additional meetings beyond the three regular meetings in a calendar
 year.

 The timing and frequency of future exploratory meetings will be based
 on IETF consensus as determined by the IETF chair.  Once a meeting
 proposal is initiated, the IESG will make a decision in consultation
 with the IETF Administrative Support Activity (IASA) [RFC8711] to
 ensure that the proposal can be realistically implemented.  The final
 decision will be communicated back to the community to ensure that
 there is adequate opportunity to comment.

    |  NOTE: There have not been a large number of meetings that would
    |  qualify as exploratory meetings under the 1-1-1 policy (with
    |  IETF 95 in Buenos Aires and IETF 47 in Adelaide being the
    |  exceptional instances).  IETF 27 (Amsterdam) and IETF 54
    |  (Yokohama) were earlier examples of exploratory meetings that
    |  pioneered Europe and Asia as regular IETF destinations.

3. Implementation of the Policy

 IASA should understand the policy written in this document to be the
 aspiration of the IETF community.  Similarly, any exploratory meeting
 decisions will also be communicated to the IASA to be implemented.
 The actual selection of the venue would be performed by the IASA
 following the process described in [RFC8718].

 As mentioned in [RFC8718], the IASA will also be responsible for the
 following:

• assisting the community in the development of detailed meeting

criteria that are feasible and implementable, and

• providing sufficient transparency in a timely manner concerning

planned meetings so that community feedback can be collected and

    acted upon.

 Given that the geographical location of the venue has a significant
 influence on the venue selection process, it needs to be considered
 at the same level as the other Important Criteria specified in
 Section 3.2 of [RFC8718] (including potentially trading-off the
 geographical region to meet other criteria and notifying the
 community if the geographical region requirement cannot be met).

4. Procedure for Initiating Proposals for Exploratory Meetings

 Someone who is interested in pursuing an exploratory venue proposes
 it on the IETF discussion list or on a future discussion list
 expressly set up and announced for this purpose.  The community gets
 to comment on the venue and offer their opinions.  If the IETF chair
 determines that there is community consensus to pursue the venue
 further, the venue will be put up for discussion on the venue-
 selection mailing list <https://www.ietf.org/mailman/listinfo/venue-
 selection>.  This would allow the interested party(ies) to refine
 their proposal based on insightful feedback regarding the logistics
 of the venue from those tasked with evaluating it.  Once the venue
 selection process takes place, the final decision will be
 communicated back to the community to ensure that there is adequate
 opportunity to comment.

5. Re-evaluation and Changes to This Policy

 Given the dynamic nature of participant distribution in the IETF, it
 is expected that this policy will need to be periodically evaluated
 and revised to ensure that the stated goals continue to be met.  The
 criteria that are to be met need to be agreed upon by the community
 prior to initiating a revision of this document (e.g., try to mirror
 draft author distribution over the preceding five years).

6. References

6.1. Normative References

 [RFC8711]  Haberman, B., Hall, J., and J. Livingood, "Structure of
            the IETF Administrative Support Activity, Version 2.0",
            BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
            <https://www.rfc-editor.org/info/rfc8711>.

6.2. Informative References

 [CONT-DIST]
            IETF, "Number of attendees per continent across meetings",
            <https://datatracker.ietf.org/stats/meeting/continent/>.

 [IETFMEET] Hinden, B. and R. Pelletier, "IAOC Report IETF79",
            November 2010,
            <https://www.ietf.org/proceedings/79/slides/plenaryw-
            3.pdf>.

 [RFC8718]  Lear, E., Ed., "IETF Plenary Meeting Venue Selection
            Process", BCP 226, RFC 8718, DOI 10.17487/RFC8718,
            February 2020, <https://www.rfc-editor.org/info/rfc8718>.

Acknowledgments

 The author would like to thank Jari Arkko, Alia Atlas, Fred Baker,
 Brian Carpenter, Alissa Cooper, Dave Crocker, Spencer Dawkins,
 Stephen Farrell, Tobias Gondrom, Eric Gray, Bob Hinden, Ole Jacobsen,
 Olaf Kolkman, Eliot Lear, Andrew Malis, Yoav Nir, Ray Pelletier,
 Melinda Shore, John Klensin, Charles Eckel, Russ Housley, Andrew
 Sullivan, Eric Rescorla, Richard Barnes, Cullen Jennings, Ted Lemon,
 Lou Berger, John Levine, Adam Roach, Mark Nottingham, Tom Petch,
 Randy Bush, Roni Even, Julien Meuric, Lloyd Wood, Alvaro Retana, and
 Martin Vigoureux for their ideas and comments to improve this
 document.

Author's Address

 Suresh Krishnan
 Kaloom

 Email: suresh@kaloom.com

Internet Engineering Task Force (IETF) M. Duke Request for Comments: 9137 F5 Networks, Inc. BCP: 226 October 2021 Category: Best Current Practice ISSN: 2070-1721

          Considerations for Cancellation of IETF Meetings

Abstract

 The IETF ordinarily holds three in-person meetings per year to
 discuss issues and advance the Internet.  However, various events can
 make a planned in-person meeting infeasible.  This document provides
 criteria to aid the IETF Administration LLC (IETF LLC), the Internet
 Engineering Steering Group (IESG), and the Chair of the Internet
 Research Task Force (IRTF) in deciding to relocate, virtualize,
 postpone, or cancel an in-person IETF meeting.

Status of This Memo

 This memo documents an Internet Best Current Practice.

 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).  Further information on
 BCPs is available in 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/rfc9137.

Copyright Notice

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

Table of Contents

 1.  Introduction
 2.  Conventions
 3.  Decision Criteria and Roles
   3.1.  IETF LLC
   3.2.  The IESG and the Chair of the IRTF
 4.  Remedies
   4.1.  Relocation
   4.2.  Virtualization
   4.3.  Postponement
   4.4.  Cancellation
 5.  Refunds
 6.  Security Considerations
 7.  IANA Considerations
 8.  Normative References
 Acknowledgments
 Author's Address

1. Introduction

 Among the highlights of the IETF calendar are in-person general
 meetings, which happen three times a year at various locations around
 the world.

 Various major events may affect the suitability of a scheduled in-
 person IETF meeting, though this may not be immediately obvious for
 some events.  Examples of such events include the following:

• A meeting venue itself may unexpectedly close or otherwise be

unable to meet IETF meeting requirements due to a health issue,

    legal violation, or other localized problem.

• A natural disaster could degrade the travel and meeting

infrastructure in a planned location and make it unethical to

    further burden that infrastructure with a meeting.

• War, civil unrest, or a public health crisis could make a meeting

unsafe and/or result in widespread national or corporate travel

    bans.

• An economic crisis could sharply reduce resources available for

travel, resulting in lower expected attendance.

• Changes in visa policies or other unexpected governmental

restrictions might make the venue inaccessible to numerous

    attendees.

 This document provides criteria to aid the IETF Administration LLC
 (IETF LLC), the Internet Engineering Steering Group (IESG), and the
 Chair of the Internet Research Task Force (IRTF) in deciding to
 relocate, virtualize, postpone, or cancel an in-person IETF meeting.

2. Conventions

 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.

 In this document, the term "venue" refers to both the facility that
 houses the sessions and the official meeting hotel(s), as defined in
 [RFC8718].

3. Decision Criteria and Roles

 The IETF LLC assesses whether an in-person meeting is logistically
 and financially viable in light of events and assembles information
 about various travel restrictions that might impact attendance.  The
 IESG and the Chair of the IRTF assess if the projected attendance is
 sufficient for a viable in-person meeting.

3.1. IETF LLC

 The IETF LLC is responsible for assessing the suitability of a venue
 for an IETF meeting and is responsible for any reassessment in
 response to a major event that leaves the prior conclusion in doubt.
 If such an event occurs more than fourteen weeks before the start of
 the scheduled meeting, it is deemed a non-emergency situation.  Later
 events, up to and including the week of a meeting itself, are deemed
 emergency situations.

 In non-emergency situations, if the IETF LLC determines the scheduled
 meeting clearly cannot proceed (e.g., the venue has permanently
 closed), then it MUST share the reason(s) with the community and MUST
 consult on its proposed remedy.  In less clear cases, the IETF LLC
 SHOULD conduct a formal reassessment process that includes:

• Consulting with the community on the timetable of the decision

process.

• Consulting with the community on criteria to assess the impact of

new developments.

• Publishing an assessment report and recommended remedy.

• Seeking approval of the IESG and the Chair of the IRTF for the

recommendation.

 In emergency situations, which lack the time for a consultation
 process, this document provides criteria that have IETF consensus and
 that the IETF LLC MUST apply in its assessment.

 The IETF LLC will collect information about the likely impact to in-
 person attendance of national travel advisories, national and
 corporate travel bans, availability of transportation, quarantine
 requirements, etc., and report the results to the IESG and the Chair
 of the IRTF.

 These criteria, some of which are derived from Section 3 of
 [RFC8718], apply to venues that are re-evaluated due to an emergency:

• Local safety guidelines allow the venue and hotels to host a

meeting with the expected number of participants and staff.

• It is possible to provision Internet access to the venue that

allows those attending in person to utilize the Internet for all

    their IETF, business, and day-to-day needs; in addition, there
    must be sufficient bandwidth and access for remote attendees.
    Provisions include, but are not limited to, native and unmodified
    IPv4 and IPv6 connectivity and global reachability; there may be
    no additional limitation that would materially impact their
    Internet use.  To ensure availability, it MUST be possible to
    provision redundant paths to the Internet.

• A reasonable number of food and drink establishments are open and

available within walking distance to provide for the expected

    number of participants and staff.

• Local health and public safety infrastructure expects to have

adequate capacity to support an influx of visitors during the

    meeting week.

 Finally, the IETF LLC MUST assess the impact on its own operations,
 including:

• The number of critical support staff, contractors, and volunteers

who can be at the venue.

• The financial impact of continuing a meeting or implementing any

of the possible remedies.

 The IETF LLC SHOULD cancel an in-person meeting and explore potential
 remedies if it judges a meeting to be logistically impossible or
 inconsistent with its fiduciary responsibilities.

 In the event of considerations this document does not foresee, the
 IETF LLC should protect the health and safety of attendees and staff,
 as well as the fiscal health of the organization, with approval from
 the IESG and the Chair of the IRTF.  The IESG should pursue a later
 update of this document.

3.2. The IESG and the Chair of the IRTF

 If the IETF LLC assesses there are no fundamental logistical or
 financial obstacles to holding a meeting in an emergency situation,
 the IESG and the Chair of the IRTF assess if projected attendance is
 high enough to achieve the benefit of an in-person meeting.  The IESG
 and the Chair of the IRTF SHOULD cancel the in-person meeting if that
 benefit is insufficient.

 The IESG and the Chair of the IRTF are discouraged from relying on a
 simple head count of expected meeting attendance.  Even dramatically
 smaller meetings with large remote participation may be successful.
 In addition to the IETF LLC's estimate, the IESG and the Chair of the
 IRTF might consider:

• Are many working groups and research groups largely unaffected by

the restrictions, so that they can operate effectively?

• Is there a critical mass of key personnel at most working group

meetings to leverage the advantages of in-person meetings, even if

    many participants are remote?

4. Remedies

 If a meeting cannot be held at the scheduled time and place, the IETF
 LLC, IESG, and Chair of the IRTF have several options.  The remedies
 in this section should be considered in light of four principles
 (presented in no particular order):

• Hold the scheduled sessions of a meeting in some format.

• Provide benefits of in-person interactions when possible.

• Avoid exorbitant additional travel expenses due to last-minute

flight changes, etc.

• Ensure sufficient time and resources to adequately prepare an

alternative.

 The following remedies are listed in approximate declining order of
 preference.

4.1. Relocation

 For attendees, the least disruptive response is to retain the meeting
 week but move it to a more-accessible venue.  To the maximum extent
 possible, this will be geographically close to the original venue.
 In particular, the IETF LLC SHOULD meet the criteria in [RFC8718] and
 [RFC8719].

 Relocation that requires new air travel arrangements for attendees
 SHOULD NOT occur less than one month prior to the start of the
 meeting.

4.2. Virtualization

 The second option, and one that has fewer issues with venue
 availability, is to make a meeting fully online.  This requires
 different IETF processes and logistical operations that are outside
 the scope of this document.

4.3. Postponement

 Although it is more disruptive to the schedules of participants, the
 next best option is to delay a meeting until a specific date, at the
 same venue, at which conditions are expected to improve.  The new end
 date of a meeting must be at least 30 days before the beginning of
 the following IETF meeting, and a meeting MUST begin no earlier than
 30 days after the postponement announcement.

 Due to scheduling constraints at the venue, this will usually not be
 feasible.  However, it is more likely to allow attendees to recover
 at least some of their travel expenses than other options.

 Note that it is possible to both postpone and relocate a meeting,
 though this has the disadvantages of both.

4.4. Cancellation

 The IETF LLC, IESG, and Chair of the IRTF may cancel a meeting
 entirely in the event that worldwide conditions make it difficult for
 attendees to even attend online.  Not holding a meeting at all can
 have wide implications, such as effects on the nomination process and
 seating of new officers.

 Cancellation is likely the only practical alternative when
 emergencies occur immediately before or during a meeting, so that
 there is no opportunity to make other arrangements.

5. Refunds

 The IETF SHOULD NOT reimburse registered attendees for unrecoverable
 travel expenses (airfare, hotel deposits, etc.).

 However, there are several cases where full or partial refund of
 registration fees are appropriate:

• Cancellation SHOULD result in a full refund to all participants.

It MAY be prorated if some portion of the sessions completed

    without incident.

• Upon postponement, the IETF LLC SHOULD offer refunds to registered

attendees who claim they cannot attend at the newly scheduled

    time.  Attendees can opt out of receiving a refund.

• When a meeting is virtualized, the IETF LLC MUST offer to refund

registered attendees the difference between their paid

    registration fee and the equivalent fee for an online meeting.
    The IETF LLC SHOULD offer refunds to registered attendees who do
    not wish to attend an online meeting.

• The IETF LLC SHOULD offer refunds to attendees whose government

forbids, or has issued a safety advisory against, visits to the

    host venue, even if the in-person meeting will continue.  It
    SHOULD NOT refund cancellations due to employer policy or personal
    risk assessments.

 These provisions intend to maintain trust between the IETF and its
 participants.  However, under extraordinary threats to the solvency
 of the organization, the IETF LLC may suspend them.

6. Security Considerations

 This document introduces no new concerns for the security of Internet
 protocols.

7. IANA Considerations

 This document has no IANA actions.

8. 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>.

 [RFC8718]  Lear, E., Ed., "IETF Plenary Meeting Venue Selection
            Process", BCP 226, RFC 8718, DOI 10.17487/RFC8718,
            February 2020, <https://www.rfc-editor.org/info/rfc8718>.

 [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>.

Acknowledgments

 Jay Daley provided extensive input to make this document more usable
 by the IETF LLC.  Many members of the IESG and the SHMOO Working
 Group also provided useful comments.

Author's Address

 Martin Duke
 F5 Networks, Inc.

 Email: martin.h.duke@gmail.com