doc: Add RFC documents

1 files changed, 218 insertions, 0 deletions

diff --git a/doc/rfc/rfc8719.txt b/doc/rfc/rfc8719.txt
new file mode 100644
index 0000000..bb430cf
--- /dev/null
+++ b/doc/rfc/rfc8719.txt
@@ -0,0 +1,218 @@
+
+
+
+
+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