IETF Plenary Meeting Venue Selection Process (original) (raw)

Introduction The IETF Administrative Support Activity (IASA) 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 (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 when, and only when, they appear in all capitals, as shown here.

Venue Selection Objectives

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 . 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.

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 .

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.

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.

Meeting Criteria This section contains the criteria for IETF meetings. It is broken down into three subsections: mandatory criteria,important criteria , and other considerations, each as explained below.

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.

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.

Venue City Criteria The following requirements relate to the Venue city.

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:

Technical Meeting Needs The following criteria relate to technical meeting needs.

Hotel Needs The following criteria relate to IETF Hotels.

Food and Beverage The following criteria relate to food and beverage.

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.

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.

IANA Considerations This document has no IANA actions.

Security Considerations This note proposes no protocols and therefore introduces no new protocol insecurities.

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.