doc: Add RFC documents

1 files changed, 532 insertions, 0 deletions

diff --git a/doc/rfc/rfc8718.txt b/doc/rfc/rfc8718.txt
new file mode 100644
index 0000000..9aad9e5
--- /dev/null
+++ b/doc/rfc/rfc8718.txt
@@ -0,0 +1,532 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                      E. Lear, Ed.
+Request for Comments: 8718                                 Cisco Systems
+BCP: 226                                                   February 2020
+Category: Best Current Practice                                         
+ISSN: 2070-1721
+
+
+              IETF Plenary Meeting Venue Selection Process
+
+Abstract
+
+   The IETF Administration Support Activity (IASA) is responsible for
+   arranging the selection and operation of the IETF plenary meeting
+   venue.  This memo specifies IETF community requirements for meeting
+   venues, including hotels and meeting space.  It also directs the IASA
+   to make available additional process documents that describe the
+   current meeting selection process.
+
+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/rfc8718.
+
+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.  Venue Selection Objectives
+     2.1.  Core Values
+     2.2.  Venue Selection Non-objectives
+   3.  Meeting Criteria
+     3.1.  Mandatory Criteria
+     3.2.  Important Criteria
+     3.3.  Other Considerations
+   4.  Documentation Requirements
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  Privacy Considerations
+   8.  Normative References
+   9.  Informative References
+   Acknowledgements
+   Contributors
+   Author's Address
+
+1.  Introduction
+
+   The IETF Administrative Support Activity (IASA) [RFC8711] is
+   responsible for arranging the selection and operation of the IETF
+   plenary meeting venue.  The purpose of this document is to guide the
+   IASA in their selection of regions, cities, facilities, and hotels.
+   The IASA should apply this guidance at different points in the
+   process in an attempt to faithfully meet the requirements of the IETF
+   community.  We specify a set of general criteria for venue selection
+   and several requirements for transparency and community consultation.
+
+   It remains the responsibility of the IASA to apply their best
+   judgment.  The IASA accepts input and feedback during the
+   consultation process and later (for instance, when there are changes
+   in the situation at a chosen location).  The community is encouraged
+   to provide direct feedback about the IASA's performance to the IETF
+   Administration LLC, the Nominations Committee (NOMCOM), or the
+   Internet Engineering Steering Group (IESG).  Any reviews of IASA
+   decisions remain subject to the provisions of Section 4.7 of
+   [RFC8711] (BCP 101).
+
+   The following four terms describe the places for which the IETF
+   contracts services:
+
+   Venue:
+      An umbrella term for the city, meeting resources, and guest room
+      resources.
+
+   Facility:
+      The building that houses meeting rooms and associated resources.
+      It may also house an IETF Hotel.
+
+   IETF Hotels:
+      One or more hotels, in close proximity to the Facility, where the
+      IETF guest room block allocations are negotiated and where network
+      services managed by the IASA (e.g., the "IETF" SSID) are in use.
+
+   Overflow Hotels:
+      One or more hotels, usually in close proximity to the Facility,
+      where the IETF has negotiated a group room rate for the purposes
+      of the meeting.  Of particular note is that Overflow Hotels are
+      not usually connected to the IETF network and do not use network
+      services managed by the IASA.
+
+   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.
+
+2.  Venue Selection Objectives
+
+2.1.  Core Values
+
+   Some IETF values pervade the selection process.  These are often
+   applicable to multiple requirements listed in this document.  At a
+   minimum, they include the following:
+
+   Why we meet:
+      We meet to pursue the IETF's mission [RFC3935].  This is partly
+      done by advancing the development of Internet-Drafts and RFCs.  We
+      also seek to facilitate attendee participation in multiple topics
+      and to enable cross-pollination of ideas and technologies.
+
+   Inclusiveness:
+      We would like to facilitate the on-site or remote participation of
+      anyone who wants to be involved.  Widespread participation
+      contributes to the diversity of perspectives represented in the
+      working sessions.
+
+      Every country has limits on who it will permit within its borders.
+      However, the IETF seeks to:
+
+      1.  Minimize situations in which onerous entry regulations
+          inhibit, discourage, or prevent participants from attending
+          meetings; failing that, meeting locations are to be
+          distributed such that onerous entry regulations are not always
+          experienced by the same attendees; and
+
+      2.  Avoid meeting in countries with laws that effectively exclude
+          people on the basis of race, ethnicity, religion, gender,
+          sexual orientation, national origin, citizenship, or gender
+          identity.
+
+   Where we meet:
+      We meet in different global locations, in order to spread the
+      difficulty and cost of travel among active participants, balancing
+      travel time and expense across participants based in various
+      regions.  Our regional location policy is articulated in
+      [RFC8719].
+
+   Internet Access:
+      As an organization, we write specifications for the Internet, and
+      we use it heavily.  Meeting attendees need unfiltered access to
+      the general Internet and their corporate networks.  "Unfiltered
+      access", in this case, means that all forms of communication are
+      allowed.  This includes, but is not limited to, access to
+      corporate networks via encrypted VPNs from the meeting Facility
+      and Hotels, including Overflow Hotels.  We also need open network
+      access available at high enough data rates, at the meeting
+      Facility, to support our work, which includes support of remote
+      participation.  Beyond this, we are the first users of our own
+      technology.  Any filtering may cause a problem with that
+      technology development.  In some cases, local laws may require
+      some filtering.  We seek to avoid such locales without reducing
+      the pool of cities to an unacceptable level by stating a number of
+      criteria below, one mandatory and others important, to allow for
+      the case where local laws may require filtering in some
+      circumstances.
+
+   Focus:
+      We meet to have focused technical discussions.  These are not
+      limited to scheduled breakout sessions, although of course those
+      are important.  They also happen over meals or drinks, through a
+      specific type of non-session that we call a "Bar BOF", or in side
+      meetings.  Environments that are noisy or distracting prevent or
+      reduce the effectiveness of these sessions and are therefore less
+      desirable as a meeting Facility [RFC6771].
+
+   Economics:
+      Meeting attendees participate as individuals.  While many are
+      underwritten by employers or sponsors, many are self-funded.  In
+      order to reduce participation costs and travel effort, we
+      therefore seek locations that provide convenient budget
+      alternatives for food and lodging, and that minimize travel
+      segments from major airports to the Venue.  Within reason, one's
+      budget should not be a barrier to accommodation.
+
+   Least Astonishment and Openness:
+      Regular participants should not be surprised by meeting Venue
+      selections, particularly when it comes to locales.  To avoid
+      surprise, the venue selection process, as with all other IETF
+      processes, should be as open as practicable.  It should be
+      possible for the community to engage in discussion early to
+      express its views on prospective selections, so that the community
+      and the IASA can exchange views as to appropriateness long before
+      a venue contract is considered.
+
+2.2.  Venue Selection Non-objectives
+
+   IETF meeting Venues are not selected or declined with the explicit
+   purposes of:
+
+   Politics:
+      Endorsing or condemning particular countries, political paradigms,
+      laws, regulations, or policies.
+
+   Maximal attendance:
+      While the IETF strives to be as inclusive as possible, both online
+      and in person, maximal meeting attendance in and of itself is not
+      a goal.  It would defeat a key goal of meeting if active
+      contributors with differing points of view did not have the
+      opportunity to resolve their disagreements, no matter how full the
+      rooms.
+
+   Tourism:
+      Variety in site-seeing experiences.
+
+3.  Meeting Criteria
+
+   This section contains the criteria for IETF meetings.  It is broken
+   down into three subsections: mandatory criteria (Section 3.1),
+   important criteria (Section 3.2), and other considerations
+   (Section 3.3), each as explained below.
+
+3.1.  Mandatory Criteria
+
+   If criteria in this subsection cannot be met, a particular location
+   is unacceptable for selection, and the IASA MUST NOT enter into a
+   contract.  Should the IASA learn that a location can no longer meet a
+   mandatory requirement after having entered into a contract, it will
+   inform the community and address the matter on a case-by-case basis.
+
+   *  The Facility MUST provide sufficient space in an appropriate
+      layout to accommodate the number of participants, leadership, and
+      support staff expected to attend that meeting.
+
+   *  The Facility and IETF Hotels MUST provide wheelchair access to
+      accommodate the number of people who are anticipated to require
+      it.
+
+   *  It MUST be possible to provision Internet Access to the Facility
+      and IETF Hotels 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.
+
+3.2.  Important Criteria
+
+   The criteria in this subsection are not mandatory, but they are still
+   highly significant.  It may be necessary to trade-off one or more of
+   these criteria against others.  A Venue that meets more of these
+   criteria is, on the whole, preferable to another that meets fewer of
+   these criteria.  Requirements classed as Important can also be
+   balanced across Venue selections for multiple meetings.  When a
+   particular requirement in this section cannot be met but the Venue is
+   selected anyway, the IASA MUST notify the community at the time of
+   the venue announcement.  Furthermore, it may be appropriate for the
+   IASA to assist those who, as a result, have been inconvenienced in
+   some way.
+
+3.2.1.  Venue City Criteria
+
+   The following requirements relate to the Venue city.
+
+   *  Travel to the Venue is acceptable based on cost, time, and burden
+      for participants traveling from multiple regions.  It is
+      anticipated that the burden borne will generally be shared over
+      the course of multiple years.
+
+   *  The Venue is assessed as favorable for obtaining a host and
+      sponsors.  That is, the Meeting is in a location in which it is
+      possible and probable to find a host and sponsors.
+
+   *  Travel barriers to entry, including visa requirements, are likely
+      to be such that an overwhelming majority of participants who wish
+      to do so can attend.  The term "travel barriers" is to be read
+      broadly by the IASA in the context of whether a successful meeting
+      can be had.
+
+   *  Economic, safety, and health risks associated with this Venue are
+      acceptable.
+
+   *  The selection of the venue comports with the practices described
+      in [RFC8719].
+
+3.2.2.  Basic Venue Criteria
+
+   The following requirements relate to the Venue and Facilities.
+
+   The IETF operates internationally and adjusts to local requirements.
+   Facilities selected for IETF meetings SHALL have provided written
+   assurance that they are in compliance with local health, safety, and
+   accessibility laws and regulations, and that they will remain in
+   compliance throughout our stay.
+
+   In addition:
+
+   *  There are sufficient places (e.g., a mix of hallways, bars,
+      meeting rooms, and restaurants) for people to hold ad hoc
+      conversations and group discussions in the combination of spaces
+      offered by the facilities, hotels, and bars/restaurants in the
+      surrounding area, within walking distance (5-10 minutes).
+
+   *  The cost of guest rooms, meeting space, meeting food and beverage
+      is affordable, within the norms of business travel.
+
+   *  The Facility is accessible, or reasonable accommodations can be
+      made to allow access, by people with disabilities.
+
+3.2.3.  Technical Meeting Needs
+
+   The following criteria relate to technical meeting needs.
+
+   *  The Facility's support technologies and services -- network,
+      audio-video, etc. -- are sufficient for the anticipated activities
+      at the meeting, or the Facility is willing to add such
+      infrastructure, or these support technologies and services might
+      be provided by a third party, all at no -- or at an acceptable --
+      cost to the IETF.
+
+   *  The IETF Hotels directly provide, or else permit and facilitate,
+      the delivery of a high performance, robust, unfiltered, and
+      unmodified Internet service for the public areas and guest rooms;
+      this service is to be included in the cost of the room.
+
+3.2.4.  Hotel Needs
+
+   The following criteria relate to IETF Hotels.
+
+   *  The IETF Hotels are within close proximity to each other and the
+      Facility.
+
+   *  The guest rooms at the IETF Hotels are sufficient in number to
+      house one-third or more of projected meeting attendees.
+
+   *  Overflow Hotels can be placed under contract, within convenient
+      travel time to and from the Facility and at a variety of guest
+      room rates.
+
+   *  The Facility environs include budget hotels within convenient
+      travel time, cost, and effort.
+
+   *  The IETF Hotels are accessible by people with disabilities.  While
+      we mandate wheelchair accessibility, other forms are important and
+      should be provided for to the extent possible based on anticipated
+      needs of the community.
+
+   *  At least one IETF Hotel or the Facility has a space for use as a
+      lounge, conducive to planned and ad hoc meetings and chatting, as
+      well as a space for working online.  There are tables with
+      seating, convenient for small meetings with laptops.  These can be
+      at an open bar or casual restaurant.  Preferably the lounge area
+      is centrally located, permitting easy access to participants.
+
+3.2.5.  Food and Beverage
+
+   The following criteria relate to food and beverage.
+
+   *  The Facility environs, which include both on-site as well as areas
+      within a reasonable walking distance or conveniently accessible by
+      a short taxi ride or by local public transportation, have
+      convenient and inexpensive choices for meals that can accommodate
+      a wide range of dietary requirements.
+
+   *  A range of attendees' health-related and religion-related dietary
+      requirements can be satisfied with robust and flexible on-site
+      service or through access to an adequate grocery store.
+
+   *  The Facility environs include grocery shopping that will
+      accommodate a wide range of dietary requirements, within a
+      reasonable walking distance or conveniently accessible by a short
+      taxi, bus, or subway ride from the Facility and IETF Hotels.
+
+3.3.  Other Considerations
+
+   The following considerations are desirable, but they are not as
+   important as the preceding requirements and thus should not be
+   traded-off for them.
+
+   *  We have something of a preference for an IETF meeting to be under
+      "One Roof"; that is, qualified meeting space and guest rooms are
+      available in the same facility.
+
+   *  It is desirable for Overflow Hotels to provide reasonable,
+      reliable, unfiltered Internet service for the public areas and
+      guest rooms, and for this service be included in the cost of the
+      room.
+
+   *  It is desirable to enter into a multi-event contract with the
+      Facility and IETF Hotels or associated hotel chains in case such a
+      contract will reduce administrative costs, reduce direct attendee
+      costs, or both.
+
+   *  When we are considering a city for the first time, it is
+      particularly desirable to have someone familiar with both the
+      locale and the IETF participate in the site visit.  Such a person
+      can provide guidance regarding safety, location of local services,
+      the best ways to get to and from the Venue, and local customs, as
+      well as how our requirements are met.
+
+4.  Documentation Requirements
+
+   The IETF Community works best when it is well informed.  This memo
+   does not specify processes nor who has responsibility for fulfilling
+   our requirements for meetings.  Nevertheless, both of these aspects
+   are important.  Therefore, the IASA SHALL publicly document and keep
+   current both a list of roles and responsibilities relating to IETF
+   meetings, as well as the selection processes they use in order to
+   fulfill the requirements of the community.
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  Security Considerations
+
+   This note proposes no protocols and therefore introduces no new
+   protocol insecurities.
+
+7.  Privacy Considerations
+
+   Different places have different constraints on individual privacy.
+   The requirements in this memo are intended to provide for some
+   limited protections.  As meetings are announced, the IASA SHALL
+   inform the IETF of any limitations to privacy they have become aware
+   of in their investigations.  For example, participants would be
+   informed of any regulatory authentication or logging requirements.
+
+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>.
+
+   [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>.
+
+9.  Informative References
+
+   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
+              BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
+              <https://www.rfc-editor.org/info/rfc3935>.
+
+   [RFC6771]  Eggert, L. and G. Camarillo, "Considerations for Having a
+              Successful "Bar BOF" Side Meeting", RFC 6771,
+              DOI 10.17487/RFC6771, October 2012,
+              <https://www.rfc-editor.org/info/rfc6771>.
+
+   [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>.
+
+Acknowledgements
+
+   Contributions came from Jari Arkko, Scott Bradner, Alissa Cooper,
+   Dave Crocker, Jordi Palet Martinez, Andrew Sullivan, and other
+   participants in the MTGVENUE Working Group.  Those listed in this
+   section or as contributors may or may not agree with the content of
+   this memo.
+
+Contributors
+
+   The following people provided substantial text contributions to this
+   memo.  Specifically, Fred Baker originated this work.
+
+   Fred Baker
+
+   Email: fred.ietf@gmail.com
+
+
+   Ray Pelletier
+
+   Email: Rpelletier13@gmail.com
+
+
+   Laura Nugent
+   Association Management Solutions
+
+   Email: lnugent@amsl.com
+
+
+   Lou Berger
+   LabN Consulting, L.L.C.
+
+   Email: lberger@labn.net
+
+
+   Ole Jacobsen
+   The Internet Protocol Journal
+
+   Email: olejacobsen@me.com
+
+
+   Jim Martin
+   INOC
+
+   Email: jim@inoc.com
+
+
+Author's Address
+
+   Eliot Lear (editor)
+   Cisco Systems
+   Richtistrasse 7
+   CH-CH-8304 Wallisellen
+   Switzerland
+
+   Phone: +41 44 878 9200
+   Email: lear@cisco.com