RFC 9712

IETF Meeting Venue Requirements Review 🎀

Abstract 💖

Okay bestie, this one is all about the IETF's meeting venues 🏨✨. After looking closely at the venue requirements, this document updates RFC 8718 ("IETF Plenary Meeting Venue Selection Process"). It also clarifies how the IETF Administration Support Activity (IASA) should interpret some parts of RFC 8718, and it specifies a replacement exploratory meeting process, which updates RFC 8719 ("High-Level Guidance for the Meeting Policy of the IETF") 🦋.

Status of This Memo 📜

This memo documents an Internet Best Current Practice 🌸.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on BCPs, check Section 2 of RFC 7841 🧚.

For the current status of this document, any errata, and how to give feedback, go to 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) as in effect on the date of publication. Please read these carefully, because 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 they 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 get researched, negotiated, booked, and managed under "IETF Plenary Meeting Venue Selection Process" [RFC8718] and "High-Level Guidance for the Meeting Policy of the IETF" [RFC8719] 🏢. Those RFCs came out in 2020, but the real work on them was finished in 2018. Since then, a bunch of things have happened that changed how well the current model for IETF meetings actually works 😭.

The IASA looked at venue selection again with all of that in mind 👀. The staff who handle venue selection gave most of the input. The IASA found a number of issues to fix, and it plans to fix them with a mix of updates to those RFCs and clarifications of how they should be interpreted 💜.

2. Summary of Changes to RFCs 8718 and 8719 🍓

Here's what this document changes in [RFC8718] and [RFC8719], in order:

1. It updates the meeting (rotation) policy from [RFC8719] with a new process for picking exploratory meetings 🧭.
2. It clarifies what "close proximity" means in [RFC8718] 📏.
3. It swaps the room block requirement in [RFC8718], which was "one-third or more of projected meeting attendees", for a more flexible "sufficient rooms to meet the expected demand" 🛏️.
4. It clarifies that the IASA should read any mention of "Overflow Hotels" in [RFC8718] as an entirely optional feature. The IASA can choose to provide one at its own discretion 🎈.
5. It updates the ad hoc space described in several parts of [RFC8718] so it better matches what the community wants, as shown in post-meeting surveys 📊✨.

3. The Meeting (Rotation) Policy and Exploratory Meetings 🌍

3.1. Current Policy

The current meeting (rotation) policy is the "1-1-1-*" policy in [RFC8719] 🔁. Here's how it's described:

[...] 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 "*").

Also, Section 4 of [RFC8719] explains how to agree on an exploratory meeting. It requires a participant to nominate the city, the community to discuss it, and the IETF chair to decide whether there's consensus that the city is suitable 🗳️.

3.2. Discussion

Community consensus is a super high bar 🚧. It's way higher than what's needed for a meeting in Asia, Europe, or North America. For those ordinary meetings, the IASA considers community feedback, but the IASA is ultimately the decision maker. It can go ahead with a meeting in a particular city even without community consensus on whether that city is suitable 💁‍♀️.

Also, the low attendance at some exploratory meetings showed that community consensus is orthogonal to whether a meeting in a particular city is viable 📉. Not me noticing that the two don't even depend on each other 😌.

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

This document replaces Section 4 of [RFC8719] and sets the new process like this:

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 make sure that exploratory meetings don't happen so often that they redefine what "exploratory" means 🔍. It should also make sure that exploratory meetings don't pile up on the 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" like this:

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 gives this important criterion, which I'm only listing because it's directly relevant:

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

[RFC8718] also includes 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 🗺️

In practice, the IASA books a venue that fits one of two separate setups 🎪.

1. A "One-Roof" venue, which is a hotel with the meeting space in the hotel or directly attached to it 🏩.

The good stuff about this setup:

• With a big enough room block, the meeting space is generally free 🆓.
• People who normally stay at the IETF hotel get a strong sense of community 🫶.
• It's usually easier and more flexible to work with one point of contact instead of several. For example, convention centers have separate contacts for Audio/Visual services, Food/Beverage services, and meeting space 📞.
• It can be way cheaper for the IASA than working with a separate convention center 💸.
• Group discussions can move more naturally from the Facility to the hotel 🗣️.
• It's easier to negotiate network changes with the hotel as part of an overall network package 🌐.
• Someone can walk from their room to the meeting space in a few minutes, and they never have to go outdoors 🚶‍♀️.

The not-so-good stuff:

• There are a limited number of hotels (and therefore cities) with large enough meeting space and enough rooms 🥲.
• Conference hotel room rates are often on the high side, which can get expensive for IETF participants 💳.

2. A meeting space that isn't co-located with a hotel, which is normally a convention center, but where there are hotels within a short walk 🚉.

The good stuff about this setup:

• It makes many more cities available as potential venues 🌆.
• It gives more options for local hotels 🏘️.
• It lets the IASA negotiate a lower room rate than it otherwise could, because convention centers generally have a range of hotels nearby 🤑.

The not-so-good stuff:

• Convention centers are much harder to negotiate with and are less flexible 😤.
• The IASA has to pay for the meeting space 💰.
• People who normally stay at the IETF hotel get a diminished sense of community 🥀.
• Choosing a main hotel and negotiating the network at that hotel are more complicated 🧩.

To meet in cities that don't have suitable "One-Roof" venues, the IASA needs to work with convention centers. If the IASA doesn't take that approach, many cities and potentially some countries will be practically excluded as meeting venues 🌏💔.

It's also worth noting that a "One-Roof" venue shifts the costs of the meeting onto participants, while a convention center shifts the costs onto the IASA ⚖️.

Even though [RFC8718] calls "One Roof" a preference, some people in the community see it as the only way to meet the requirement for "close proximity" 🤔.

4.1.3. Resolution: Clarification of Interpretation 🎀

To deal with that concern, the IASA should interpret the "close proximity" requirement of [RFC8718] like this:

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's also worth noting 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 💬

okay so COVID cancellations and lockdowns absolutely wrecked the hospitality industry 😭 Hotels and convention centers are way more cautious about their booking terms now, and way less willing to invest in locking one in, because they want protection from another sudden loss of income. For example, a lot of hotels now want conference organizers to pay the full amount in advance for guest room blocks 💸

Where the IASA can get a large room block, it's finding that hotels are less willing to give good discounts. So room pricing isn't always on a par with nearby hotels that have fewer rooms available 🙈

Then there's the now ubiquitous offering of short-term apartment rental sites 🏠 These are big competitors to hotels for traveler accommodation, both on price and availability. no cap, they're eating into the market 💅

The net result? The IASA is reserving more hotel rooms than are actually being used. That exposes it to unnecessary risk, since it's required to financially guarantee certain levels of occupancy, and it 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", with 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 ones at other price points from the IETF Hotels. They were very underutilized by attendees. That mirrors the general underutilization of IETF contracted room blocks, and it exposes the IASA to financial risk with little benefit to participants 😬 So the use of Overflow Hotels has dropped, and they're rarely contracted now. Still, because of the way they're built into [RFC8718], plenty of people 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 get used regularly, but lightly, i.e., far below capacity. The reason is in the feedback from post-meeting surveys: most participants want an immediately accessible ad hoc meeting space, and plenty of hallway seating is the best way to give them that 🪑 The IASA has responded by adopting a new practice of bringing in additional in-hallway seating whenever what the venue provides 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. There still 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. Honestly, that's the most serious thing we can say about it, and it's a big deal 🙏

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