IETF Venue Review: IETF Meeting Venue Requirements Review

Internet Engineering Task Force (IETF)                     J. Daley, Ed.
Request for Comments: 9712                                     S. Turner
BCP: 226                                         IETF Administration LLC
Updates: 8718, 8719                                         January 2025
Category: Best Current Practice
ISSN: 2070-1721


                 IETF Meeting Venue Requirements Review

Abstract

   Following a review of the IETF meeting venue requirements, this
   document updates RFC 8718 ("IETF Plenary Meeting Venue Selection
   Process"), clarifies how the IETF Administration Support Activity
   (IASA) should interpret some elements of RFC 8718, and specifies a
   replacement exploratory meeting process, thereby updating RFC 8719
   ("High-Level Guidance for the Meeting Policy of the IETF").

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

Copyright Notice

   Copyright (c) 2025 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 Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction
   2.  Summary of Changes to RFCs 8718 and 8719
   3.  The Meeting (Rotation) Policy and Exploratory Meetings
     3.1.  Current Policy
     3.2.  Discussion
     3.3.  Resolution: Replacement of the Process for an Exploratory
           Meeting
   4.  Hotels and the Facility
     4.1.  The "One-Roof" Preference
       4.1.1.  Current Policy
       4.1.2.  Discussion
       4.1.3.  Resolution: Clarification of Interpretation
     4.2.  Number of Rooms Reserved
       4.2.1.  Current Policy
       4.2.2.  Discussion
       4.2.3.  Resolution: Update to RFC 8718
     4.3.  Overflow Hotels
       4.3.1.  Current Policy
       4.3.2.  Discussion
       4.3.3.  Resolution: Clarification of Interpretation
     4.4.  Ad Hoc Space including the Lounge and Terminal Room
       4.4.1.  Current Policy
       4.4.2.  Discussion
       4.4.3.  Resolution: Update to RFC 8718
   5.  IANA Considerations
   6.  Security Considerations
   7.  References
     7.1.  Normative References
   Contributors
   Authors' Addresses

1.  Introduction

   IETF meeting venues are researched, negotiated, booked, and managed
   in accordance with "IETF Plenary Meeting Venue Selection Process"
   [RFC8718] and "High-Level Guidance for the Meeting Policy of the
   IETF" [RFC8719].  While these RFCs were published in 2020, the
   substantive work was completed in 2018, and since then, there have
   been a number of developments that have affected the efficacy of the
   current model for IETF meetings.

   The IASA has reviewed the venue selection in light of these
   developments, primarily informed by the staff who work on venue
   selection, and has identified a number of issues to be addressed by a
   combination of updates to those RFCs and clarifications of
   interpretation.

2.  Summary of Changes to RFCs 8718 and 8719

   This document makes the following changes to [RFC8718] and [RFC8719]:

   1.  Updates the meeting (rotation) policy specified in [RFC8719] with
       a new process for the selection of exploratory meetings.

   2.  Clarifies the interpretation of "close proximity" as used in
       [RFC8718].

   3.  Updates the room block requirement specified in [RFC8718] from
       "one-third or more of projected meeting attendees" to a more
       flexible "sufficient rooms to meet the expected demand".

   4.  Clarifies that the IASA should interpret any reference to
       "Overflow Hotels" in [RFC8718] as an entirely optional feature
       that the IASA can choose to provide at its own discretion.

   5.  Updates the ad hoc space specified in various parts of [RFC8718]
       to better match the community requirements, as expressed in post-
       meeting surveys.

3.  The Meeting (Rotation) Policy and Exploratory Meetings

3.1.  Current Policy

   The current meeting (rotation) policy is set as the "1-1-1-*" policy
   in [RFC8719]:

   |  [...] the meeting policy (let's call this the "1-1-1" policy) is
   |  that meetings should rotate between North America, Europe, and
   |  Asia.

   and

   |  [...] the 1-1-1-* meeting policy is a slightly modified version of
   |  the aforementioned 1-1-1 meeting policy that allows for additional
   |  flexibility in the form of an exploratory meeting (denoted with an
   |  "*").

   Furthermore, Section 4 of [RFC8719] describes the process for
   agreeing on an exploratory meeting, which includes the requirement
   for a participant to nominate the city, the community to discuss it,
   and the IETF chair to determine if there is consensus for the city to
   be considered suitable.

3.2.  Discussion

   Community consensus is a very high bar, much higher than is required
   for a meeting in Asia, Europe, or North America.  For those ordinary
   meetings, the IASA considers community feedback but is ultimately the
   decision maker and can choose to go ahead with a meeting in a
   particular city even if there is no community consensus on the
   suitability of that city for an IETF meeting.  Furthermore, it has
   been demonstrated by the low attendance at some exploratory meetings
   that community consensus is orthogonal to the viability of meeting in
   a particular city.

3.3.  Resolution: Replacement of the Process for an Exploratory Meeting

   This document replaces Section 4 of [RFC8719] and sets the new
   process as follows:

   Exploratory meetings may be scheduled by the IASA following its
   normal processes, including those for assessing the suitability of a
   particular city, consulting with the IETF community, and deferring to
   the IESG if there is any concern that the core objective from
   [RFC8718] of 'why we meet' might not be met.

   The IASA should ensure that the frequency of exploratory meetings is
   such that it does not redefine the concept of 'exploratory' and that
   the distribution of exploratory meetings does not disproportionately
   impact meetings in the 1-1-1 regions.

4.  Hotels and the Facility

4.1.  The "One-Roof" Preference

4.1.1.  Current Policy

   [RFC8718] defines "IETF Hotels" as:

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

   It also provides the following important criteria (only listing those
   directly relevant):

   |  *  The IETF Hotels are within close proximity to each other and
   |     the Facility.

   Additionally, [RFC8718] contains this preference:

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

4.1.2.  Discussion

   What happens in practice is that the IASA books a venue that conforms
   to one of two separate configurations:

   1.  A "One-Roof" venue of a hotel with the meeting space in the hotel
       or directly attached.

       The advantages of this configuration are:

       *  With a large enough room block, the meeting space is generally
          free.

       *  For those IETF participants (and staff) that normally stay in
          the IETF hotel, there is a strong sense of community.

       *  It is usually easier and more flexible to work with a single
          point of contact instead of several (e.g., convention centers
          have separate contacts for Audio/Visual services, Food/
          Beverage services, and meeting space).

       *  It can be much cheaper for the IASA than working with a
          separate convention center.

       *  Group discussions can move more naturally from the Facility to
          the hotel.

       *  It is easier to negotiate network changes to the hotel as part
          of an overall network package.

       *  Someone can walk from their room to the meeting space in a few
          minutes, staying indoors the whole time.

       The disadvantages are:

       *  There are a limited number of hotels (and therefore cities)
          with large enough meeting space and sufficient rooms.

       *  The room rates at conference hotels are often on the high
          side, which can be more expensive for IETF participants.

   2.  A meeting space not co-located with a hotel (normally a
       convention center) but where there are hotels within a short
       walk.

       The advantages of this configuration are:

       *  It makes many more cities available as potential venues.

       *  It provides more options for local hotels.

       *  It enables the IASA to negotiate a lower room rate than
          otherwise as convention centers generally have a range of
          hotels nearby.

       The disadvantages are:

       *  Convention centers are much more difficult to negotiate with
          and are less flexible.

       *  The IASA has to pay for the meeting space.

       *  For those IETF participants (and staff) that normally stay in
          the IETF hotel, the sense of community is diminished.

       *  The choice of a main hotel and negotiation for the network at
          that hotel are more complicated.

   To meet in cities that do not have suitable "One-Roof" venues, the
   IASA needs to work with convention centers.  If this approach is not
   taken, then many cities and potentially some countries will be
   practically excluded as meeting venues.

   It should also be noted that a "One-Roof" venue shifts the costs of
   the meeting onto participants whereas a convention center shifts the
   costs onto the IASA.

   Despite "One Roof" being expressed as a preference in [RFC8718],
   there are some in the community who consider it as the only way to
   meet the requirement for "close proximity".

4.1.3.  Resolution: Clarification of Interpretation

   To address this concern, the IASA should interpret the "close
   proximity" requirement of [RFC8718] as follows:

        Where the meeting space is a convention center or another
        facility without a directly attached hotel, the "close
        proximity" requirement for the IETF Hotels should mean that the
        time it takes to walk from the IETF Hotels to the meeting space
        should be no longer than ten minutes, and it should be a safe
        walk including early in the morning and late at night.

   It should be noted that Section 3.2.2 of [RFC8718] already uses a
   walkability test of 5-10 minutes for a similar purpose.

4.2.  Number of Rooms Reserved

4.2.1.  Current Policy

   [RFC8718] includes the following requirement as an important
   criterion:

   |  *  The guest rooms at the IETF Hotels are sufficient in number to
   |     house one-third or more of the projected meeting attendees.

4.2.2.  Discussion

   COVID-driven cancellations and lockdowns have badly affected the
   hospitality industry overall.  Hotels and convention centers are now
   much more cautious about the terms of their bookings and much less
   willing to invest in securing a booking, as they aim to protect
   themselves from any similar sudden loss of income.  For example, many
   hotels are now requiring conference organizers to provide full
   payment in advance for guest room blocks.

   Where the IASA can get a large room block, it is finding that hotels
   are less willing to provide good discounts, so room pricing is not
   always on a par with other nearby hotels that have a smaller number
   of available rooms.

   Then there is the impact of the now ubiquitous offering of short-term
   apartment rental sites.  These sites are significant competitors to
   hotels for traveler accommodation both in price and availability.

   The net result is that the IASA is reserving more hotel rooms than
   are being used, which exposes it to unnecessary risk as they are
   required to financially guarantee certain levels of occupancy, and
   this leads to wasted effort.

4.2.3.  Resolution: Update to RFC 8718

   To address this issue, this document updates Section 3.2.4 of
   [RFC8718] by replacing the total room block requirement for IETF
   Hotels from "one-third or more of projected meeting attendees" to a
   more flexible "sufficient rooms to meet the expected demand".

4.3.  Overflow Hotels

4.3.1.  Current Policy

   Section 1 of [RFC8718] defines "Overflow Hotels" as follows:

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

   The concept is further expanded in Section 3.2.4 of [RFC8718]:

   |  Overflow Hotels can be placed under contract, within convenient
   |  travel time to and from the Facility and at a variety of guest
   |  room rates

4.3.2.  Discussion

   The IASA has historically contracted with Overflow Hotels including
   those at other price points from the IETF Hotels.  They were very
   underutilized by attendees, reflecting the general underutilization
   of IETF contracted room blocks and exposing the IASA to financial
   risk with little benefit to participants.  As a result, the use of
   Overflow Hotels has reduced, and they are rarely contracted.
   However, due to the way they are incorporated into [RFC8718], there
   are still many who believe these are, or should be, a normal feature
   of IETF meetings.

4.3.3.  Resolution: Clarification of Interpretation

   To address this issue, the IASA should interpret any reference to
   Overflow Hotels as an entirely optional feature that the IASA can
   choose to provide at its own discretion.

4.4.  Ad Hoc Space including the Lounge and Terminal Room

4.4.1.  Current Policy

   Sections 3.2.2 and 3.2.4 of [RFC8718] include the following
   requirements as important criteria:

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

   While not a formal requirement, a terminal room (described as a
   dedicated room with extended opening hours beyond the normal hours of
   IETF meetings), Ethernet connectivity, a printer, and a staffed help
   desk have been long-standing features of IETF meetings.

4.4.2.  Discussion

   Both the lounge and the terminal room are used regularly but lightly,
   i.e., far below capacity.  The reason for this is explained in the
   feedback to post-meeting surveys: Most participants want an
   immediately accessible ad hoc meeting space, which is best provided
   by plenty of hallway seating.  The IASA has responded to this
   feedback by adopting a new practice of bringing in additional in-
   hallway seating whenever that provided by the venue is insufficient.

   Dedicated rooms, such as the lounge or terminal room, or external
   facilities "within walking distance (5-10 minutes)" are unsuitable
   for the majority of participant needs, though there remains a need
   for quiet places to work between sessions.

4.4.3.  Resolution: Update to RFC 8718

   To address this issue, [RFC8718] is updated as follows:

   1.  Section 3.2.2 of [RFC8718] is updated so that the entry on ad hoc
       meeting space (first bullet) now reads:

       |  There are sufficient, easily accessible places within the
       |  Facility for people to hold ad hoc conversations and group
       |  discussions.

   2.  Section 3.2.4 of [RFC8718] is updated so that the entry on the
       lounge (sixth bullet) now reads:

       |  There are sufficient places within the Facility suitable for
       |  people to work online on their own devices.

5.  IANA Considerations

   This document has no IANA actions.

6.  Security Considerations

   This document should not affect the security of the Internet.

7.  References

7.1.  Normative References

   [RFC8718]  Lear, E., Ed., "IETF Plenary Meeting Venue Selection
              Process", BCP 226, RFC 8718, DOI 10.17487/RFC8718,
              February 2020, <https://www.rfc-editor.org/info/rfc8718>.

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

Contributors

   Thanks to the following people for their contributions to this
   document: Laura Nugent, Stephanie McCammon, Alexa Morris, Greg Wood,
   Lars Eggert, and Jason Livingood.

Authors' Addresses

   Jay Daley (editor)
   IETF Administration LLC
   1000 N. West Street, Suite 1200
   Wilmington, DE 19801
   United States of America
   Email: jay@staff.ietf.org


   Sean Turner
   IETF Administration LLC
   1000 N. West Street, Suite 1200
   Wilmington, DE 19801
   United States of America
   Email: sean@sn3rd.com