summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8718.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8718.txt')
-rw-r--r--doc/rfc/rfc8718.txt532
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