RFC 8718 | Venue Selection | February 2020 |
Lear | Best Current Practice | [Page] |
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.¶
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 (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.¶
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:¶
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.¶
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:¶
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:¶
IETF meeting Venues are not selected or declined with the explicit purposes of:¶
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.¶
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 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.¶
The following requirements relate to the Venue city.¶
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:¶
The following criteria relate to technical meeting needs.¶
The following criteria relate to IETF Hotels.¶
The following criteria relate to food and beverage.¶
The following considerations are desirable, but they are not as important as the preceding requirements and thus should not be traded-off for them.¶
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.¶
This document has no IANA actions.¶
This note proposes no protocols and therefore introduces no new protocol insecurities.¶
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.¶
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.¶
The following people provided substantial text contributions to this memo. Specifically, Fred Baker originated this work.¶