From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8718.txt | 532 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 532 insertions(+) create mode 100644 doc/rfc/rfc8718.txt (limited to 'doc/rfc/rfc8718.txt') 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, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8719] Krishnan, S., "High-Level Guidance for the Meeting Policy + of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719, + February 2020, . + +9. Informative References + + [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", + BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, + . + + [RFC6771] Eggert, L. and G. Camarillo, "Considerations for Having a + Successful "Bar BOF" Side Meeting", RFC 6771, + DOI 10.17487/RFC6771, October 2012, + . + + [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, + . + +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 -- cgit v1.2.3