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: [email protected]

You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.