IETF Plenary Meeting Venue Selection Process
RFC 8718

Document Type RFC - Best Current Practice (February 2020; No errata)
Also known as BCP 226
Last updated 2020-03-09
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Pete Resnick
Shepherd write-up Show (last changed 2017-12-20)
IESG IESG state RFC 8718 (Best Current Practice)
Consensus Boilerplate Yes
Telechat date
Responsible AD Alissa Cooper
Send notices to (None)
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions


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
Show full document text