Internet-Draft IETF Meeting Venue Requirements Review March 2023
Daley & Turner Expires 11 September 2023 [Page]
Internet Engineering Task Force
8718 (if approved)
Intended Status:
J. Daley, Ed.
IETF Administration LLC
S. Turner
IETF Administration LLC

IETF Meeting Venue Requirements Review


This document sets out a series of recommendations and proposals to the IETF Community from the IETF Administration LLC following a review of the IETF meeting venue requirements.

Editorial Note

Discussion of this draft takes place on the gendispatch mailing list, which has its home page at <>.

The source code and an issues list for this draft can be found at <>.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 September 2023.

Table of Contents

1. Introduction

IETF meeting venues are researched, negotiated, booked and managed in accordance with RFC 8718 “IETF Plenary Meeting Venue Selection Process” [RFC8718]. While this RFC was 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 our current model for IETF meetings.

The IETF Administration LLC has reviewed the venue selection in light of these developments, primarily informed by its close engagement with the Secretariat staff who work on venue selection, and has identified a number of problems and possible solutions, some of which it recommends to the community and some of which it proposes.

Taken together, the changes strip back much of the detail around venue requirements and allow for a greater variety of venue models and thereby support a greater range of possible venues.

2. Summary of Recommendations and Proposals

  1. We recommend replacing the "close proximity" requirement with a "time to walk" requirement somewhere between 5-15 minutes.
  2. We recommend replacing the "one-third" requirement for rooms in the IETF Hotels with a "sufficient to meet projected demand" requirement.
  3. We propose to no longer provide a Terminal Room and direct people to the Lounge instead.
  4. We recommend that the community reopen the discussion on Internet filtering at venues and provide us with better guidance by considering four key questions.

We finish with a discussion on the merits of returning to the same venues that are known to work well vs maximizing the number of different venues, and therefore countries, that we visit.

3. Issues, Analysis, Recommendations and Proposals

3.1. The "IETF Hotels" / "One Roof" Model

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

These are distinct from the “overflow hotels”, which are arranged but not reserved, can be some distance from the meeting space, and do not receive the IETF network.

[RFC8718] provides the following mandatory criteria:

  • It MUST be possible to provision Internet Access to the Facility and IETF Hotels

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

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

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.

3.1.2. Current Practice

What happens in practice is that we book a single IETF Hotel (aka a main hotel), with enough rooms reserved for one third of projected attendees. Most of the time this is under the same roof as the meeting space because hotels often tie their meeting space to the size of the guest bedroom block. In other words, in order to be able to book sufficient meeting space in a “one roof” venue, we need to reserve a large room block.

The IETF network is made available in the IETF Hotel, covering the guest bedrooms and the main common areas. Even when we are not under one roof, we nearly always aim for a single hotel to fulfill the requirements of the IETF Hotels. The IETF has only installed the IETF network into more than one hotel on a very small number of occasions.

There are a number of advantages to having a single IETF Hotel:

  1. It simplifies the negotiation and installation of the hotel network. Very few hotels have any experience of a third party installing a network and so the negotiation is often as much work as the installation.
  2. One large room block is more likely to result in a lower room price and hotel commissions paid to the IETF.
  3. For the core group of IETF participants (and staff) that normally stay in the IETF hotel or close by, there is a strong sense of community.

When this hotel is under the same roof as the facility then there are further advantages:

  1. It is usually easier and more flexible to work with a single point of contact instead of several (convention centers with separate contacts for AV, F&B, and space).
  2. It can be much cheaper than working with a separate convention center.
  3. Group discussions can more naturally move from the facility to the hotel.

3.1.3. Developments

As noted earlier, there have been a number of developments that have affected the efficacy of our current model.

The most recent of these developments was the COVID driven cancellations and lockdowns that 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 order to secure a booking, as they aim to protect themselves from any similar sudden loss of income. For example, many hotels are now requiring payment in full in advance for guest room blocks from conference organizers.

The current high global inflation and uncertain economic outlook adds to the risk averse stance of hotel and convention centers.

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 on price and availability.

Taking a more long-term perspective, the nature of Internet access for travelers has changed significantly over the years and the trajectory is much the same. In most of the countries that we visit, local SIM cards with a sufficient data limit are readily available at a reasonable price. The VPN industry has exploded with many commercial offerings and many corporations providing a VPN for staff. In addition, IETF-developed protocols like DoH and MASQUE have made protecting DNS and web traffic quite easy. Hotel Internet Access

When the NOC adds the IETF network to a hotel, the general approach is to bring in new external connectivity via one of a number of mechanisms and then work with the existing hotel infrastructure to configure a new SSID on the hotel APs that avoids as much of the hotel captive portal equipment as possible.

Hotel WiFi has improved significantly, both in bandwidth and quality, and there appear to be fewer hotels doing silly things such as trying to intercept SSL connections. However, the experience of the NOC in working with hotel networks, a broader experience than just working with the IETF hotels, is that there remain a large number of problems with hotel WiFi. For example, the following issues have been encountered by the NOC:

  • Access points installed inside elevators to provide a better experience in the elevators
  • Access points configured to rotate their channel at a frequency of less than a minute.
  • Captive portals that only allow for a small number of IPv6 connections because anything more must be a mistake.
  • Networks with plenty of external bandwidth but such a low-powered captive portal setup that effective bandwidth per user is below usable.

In conclusion, while hotel WiFi has improved significantly, it remains entirely unpredictable as to how it will hold up when used by a large number of engineers with unusual traffic profiles.

3.1.4. Practical Concerns

This model limits our choice of venue as it tends to exclude “one roof” venues that have sufficient meeting space but insufficient rooms, and to exclude those venues where there is a convention center that is suitable for us, with a choice of nearby hotels that in total have sufficient rooms to accommodate us, but none of the hotels individually is big enough to meet our requirements for a single IETF Hotel. In both cases, it is not the policy that excludes them but the practicalities of implementing the policy.

The large room block strategy is losing its appeal due a number of factors.

As noted above, hotels are increasingly wary of reserving large blocks of rooms as they used to do, for a number of reasons.

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

We are reserving more hotel rooms than are being used and the anecdotal evidence is that this is down to more people making individual arrangements using short-term rental sites. This is exposing us to unnecessary risk as we are required to financially guarantee certain levels of occupancy, and is leading to wasted effort. It also means that we are not receiving the anticipated commission income from hotels, which would anyway be lower than pre-COVID due to the financial caution of hotels.

Finally, despite the effort that goes into providing the network in the IETF Hotel, it should be noted that we understand very little about how it is used.

3.1.5. Recommendations and Proposals

We make the following recommendations:

  1. To replace the "close proximity" requirement for the IETF Hotels with a "time to walk" requirement, that aims to limit the time it takes to walk from the hotel(s) to the meeting space and to each other. We make no proposal as to the length of time other than to note it should not be any less than five minutes nor more than fifteen minutes (see for context and to generate a walking time polygon for your city of choice) and that Section 3.2.2 of [RFC8718] already uses a walkability test of 5-10 minutes for a similar purpose.
  2. To replace the requirement for the total room block in the IETF Hotels from "one-third of the projected attendees" to a more flexible "sufficient rooms to meet the expected demand". Short-term apartment rental companies only operate in some countries, so the number of rooms booked will need to vary depending on our assessment of the availability of alternative forms of accommodation. Note, this excludes the number of rooms reserved in the overflow hotels, which are not guaranteed and which do not benefit from the IETF network.

We propose:

  1. For the NOC to monitor the usage of the IETF network in the IETF Hotels in order to understand it better. This would provide the data for a review of the hotel network and what, if any, changes are needed. We leave the details of what monitoring takes place to the NOC and community to decide.

3.2. The Lounge, Terminal Room and Ad-hoc Space

3.2.1. Current Policy

[RFC8718] includes 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.

The only requirements for a Terminal Room are given in the The Tao of the IETF (, which describes it as a dedicated room with extended opening hours beyond the normal hours of IETF meetings, Ethernet connectivity, a printer and a staffed helpdesk.

3.2.2. Current Practice

The Lounge is a feature of every IETF meeting. It is regularly but lightly used, far below capacity.

The Terminal Room is a feature of every IETF meeting. It is regularly but lightly used, far below capacity. It meets most of the requirements from the Tao (, but the decision was taken some years ago to move the helpdesk to the reception area.

3.2.3. Developments

Almost everybody at an IETF meeting now has a laptop, tablet, or smartphone (if not all of these) and WiFi in those devices is ubiquitous. In the other places where people regularly work outside of the office (airport lounges, cafes, hotels, etc) cabled ethernet connections are a rarity.

The need to print such things as travel documents, event tickets, and the like, has dropped to virtually zero as all of these things have been replaced with apps on mobile devices.

3.2.4. Practical Concerns

Those people that use the Terminal Room rarely use any of the facilities provided; they are largely after a quiet place to work between working group meetings they plan to attend.

The demand for in-person technical support is low and almost all of the visits are for things that could be supported remotely via a support ticket. The IETF NOC team already responds to support tickets throughout the meeting and we specifically monitor the perceptions of our support response in our post-meeting surveys.

In practice, negotiating the requirements of the Terminal Room with the venues takes disproportionately long and its usage is too low to justify this work.

In our last two post-meeting surveys, comments have been made about the lack of ad-hoc space in and around the facility, and the positioning of the Terminal Room and Code Lounge:

  • "the rather limited number of chairs and lounge tables in front of the meeting rooms"
  • "less space for social interaction and the terminal room/code lounge was far away from the meetings"
  • "Terminal room: this should have been more readily accessible and not located on floor -3 in a room with no window"
  • "Hard to find breakout rooms and have the side conversations that are so critical to IETF sessions"

Increasing ad-hoc meeting space presents us with some challenges:

  1. Most venues include "pre-function" space but we tend to use that for our registration desk and related desks (e.g. IANA, RPC).
  2. There are many venues that could not support such space and if it became a strong requirement that would significantly reduce our choice.
  3. Of those venues that do have such space, our experience is that they often do not have the furniture and so we would need to rent it. This is not an insurmountable problem but does mean increasing our costs at a time we want to be reducing them.
  4. Fire restrictions often prevent us from using space that might appear to the observer to be otherwise free for us to use in this way.

Given the under-utilization of the Lounge it might make sense to reconfigure the meeting space to make the Lounge easier to access so that it can more easily be used as ad-hoc meeting space, but where we have tried that it has meant having the meeting rooms further apart and participants have complained about that.

3.2.5. Proposals

As the Terminal Room is not a requirement from [RFC8718] , it is within scope for the LLC to propose the following changes:

  1. To no longer have a Terminal Room. Anyone that wishes to use the Terminal Room will be directed to the Code Lounge instead.
  2. Drop the in-person helpdesk. Technical support will still be available via the support email and we will introduce a new Zulip channel for live support. On those rare occasions when in-person support is required, then an engineer will appear.
  3. Drop the requirement for an IETF provided printer. If people need to print then they will need to identify suitable facilities themselves. The registration desk may be able to provide pointers, but we are no longer guaranteeing that print services will be available.

Relatedly, the meeting planning team will be taking the following actions:

  1. Where the opportunity arises for us to provide greater ad-hoc space through rental of furniture, then we will consider this.
  2. We will experiment with the location of the Lounge and see what feedback we get from that.
  3. We will improve the messaging and signage around the lounge, encouraging people to use it as ad-hoc meeting space.

3.3. Internet Filtering

3.3.1. Current Policy

[RFC8718] has a lot to say about filtering:

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.


It MUST be possible to provision Internet Access to the Facility and IETF Hotels [...] 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.

3.3.2. Developments

The legal frameworks around filtering have grown more sophisticated and filtering technology has similarly developed.

Additionally, as noted above, VPN technology and other privacy-enhancing technologies have also developed rapidly.

Historically, the IETF has met in countries with significant Internet filtering and there is an expectation from the local communities in those countries that we revisit them.

3.3.3. Practical Concerns

In practice the requirements have proven difficult to interpret because they leave too many questions unanswered:

  1. Is any filtering acceptable? For example, some countries operate filters that are minimally invasive by redirecting and filtering traffic to a small number of high-risk sites and only for one specific illegal activity and it is not clear if we could meet in a country with such restrictions.
  2. If we can be reasonably sure that people can legally, technically and practically circumvent filtering through the use of VPNs (or VPNs + encrypted DNS, or MASQUE, or other) then does it matter what else is going on, on the local network?
  3. We have historically met in venues where unfiltered access was provided to the meeting space and IETF Hotels but not to overflow hotels. Is that acceptable going forward?
  4. There is much text in [RFC8718] about the importance of people being able to work in bars, cafes etc yet this is not considered when filtering is discussed. Should it be?

3.3.4. Recommendations

We recommend the community reopen the discussion on filtering and provide us better guidance on the key questions listed above.

It may be that these questions need to be answered on a case-by-case basis when we ask for community input on specific venues, but with better guidance we could provide better data for the community to consider and minimize wasted effort on venue research.

3.4. New Venues vs Known Good Venues

The factors that make a venue a good venue are numerous:

Revisiting known good venues has a number of advantages and disadvantages:

Visiting new venues also has a number of advantages and disadvantages, related to those above. However, these are not all equally important. In particular, there are two key issues - the availability and requirements for visas, which has a direct effect on the breadth of global participation, and the appeal to meeting hosts, which has a fundamental impact on the financial viability of IETF meetings.

[RFC8719] is silent on the question of these advantages and disadvantages and so the IETF LLC aims to find a balance between the two approaches. The community may wish us to take a different approach, or provide further guidance on how to balance these various factors.

4. Next Steps

Assuming that some changes are worth moving forward with, there are some options for how to progress those.

The first option is a replacement for [RFC8718] with the same level of detail as the existing document. That provides for clarity and certainty around the requirements and while it will inevitably need replacing as those requirements change, it is unlikely that this will be an obstacle to change.

The second option is a stripped back replacement for [RFC8718] that sets the key principles for the venue and leaves the details to the IETF LLC to interpret. This has the benefit of avoiding the importance of some meeting features being lost in the detail, as arguably has happened with the importance of ad-hoc meeting areas. However, this might not ensure sufficient community engagement and oversight of the interpretations of the principles.

5. IANA Considerations

This memo includes no request to IANA.

6. Security Considerations

This document should not affect the security of the Internet.

7. References

7.1. Normative References

Lear, E., Ed., "IETF Plenary Meeting Venue Selection Process", BCP 226, RFC 8718, DOI 10.17487/RFC8718, , <>.
Krishnan, S., "High-Level Guidance for the Meeting Policy of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719, , <>.


Thanks to all of the contributors: 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
Wilimington, DE 19801
United States of America
Sean Turner
IETF Administration LLC
1000 N. West Street, Suite 1200
Wilimington, DE 19801
United States of America