| Internet-Draft | IETF Meeting Venue Requirements Review | October 2023 |
| Daley & Turner | Expires 14 April 2024 | [Page] |
Following a review of the IETF meeting venue requirements, this document proposes updates to RFC 8718 “IETF Plenary Meeting Venue Selection Process”, clarifies how the IETF Administration Support Activity (IASA) should interpret some elements of RFC 8718, and proposes a replacement meeting rotation policy, thereby obsoleting RFC 8719 "High-Level Guidance for the Meeting Policy of the IETF".¶
Discussion of this draft takes place on the mtgvenue mailing list, which has its home page at <https://www.ietf.org/mailman/listinfo/mtgvenue>.¶
The source code and an issues list for this draft can be found at <https://github.com/JayDaley/draft-daley-gendispatch-venue-requirements>.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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 14 April 2024.¶
Copyright (c) 2023 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.¶
IETF meeting venues are researched, negotiated, booked and managed in accordance with [RFC8718] “IETF Plenary Meeting Venue Selection Process” and [RFC8719] "High-Level Guidance for the Meeting Policy of the IETF". 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 our 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.¶
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. 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 "*").¶
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 "*").¶
[RFC8719] further sets out 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.¶
The view of the community appears to have shifted since RFC 8719 was written, towards a less rigid policy for IETF meeting rotation, with the key goal of avoiding excessive geographic concentration, and with greater discretion being given to the IASA. This is partly because, since 2020, the IASA has established two practices to ensure community input into the choice of meeting venues:¶
This document obsoletes [RFC8719] and sets the IETF Meeting Policy as follows:¶
The IETF meets onsite three times a year. The core regions for IETF meetings are North America, Europe and Asia, and the non-core regions are Africa, the Caribbean, Central America, the Middle East, Oceania and South America. For the avoidance of doubt, North America includes the US, Canada and Mexico, and meetings cannot be held in Antarctica. These meetings rotate geographically at the discretion of the IASA with the following restrictions:¶
[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.¶
What happens in practice is that the IASA books a venue that conforms to one of two separate configurations:¶
A "one roof" venue of a hotel with the meeting space in the hotel or directly attached.¶
The advantages of this configuration are:¶
The disadvantages are:¶
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:¶
The disadvantages are:¶
While a "one-roof" venue is preferred, there are a limited number of hotels (and therefore cities) with large enough meeting space and sufficient rooms to accommodate us. To meet in cities that do not have suitable "one-roof" venues, the IASA needs to work with convention centers. If it did not take this approach then many cities and potentially some countries would be practically excluded as meeting venues.¶
It should also be noted that a "one-roof" venue shifts the costs of the meeting more onto participants than a convention center, where the costs are shifted more towards 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".¶
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 other facility without a directly attached hotel, the “close proximity” requirement for the IETF Hotels should be taken to mean that the time it takes to walk from the IETF Hotels to the meeting space should be no longer than ten minutes, and 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.¶
[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.¶
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 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.¶
Where the IASA can get a large room block, it is finding that hotels are less willing to provide good discounts and so room pricing is not always on a par with other nearby hotels, with 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 leads to wasted effort.¶
To address this, this document updates Section 3.2.4 of [RFC8718] 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”.¶
Section 1 of [RFC8718] defines "Overflow Hotels" as follows:¶
One or more hotels, usually in close proximity to the Facility, where the IASA has negotiated a group room rate for the purposes of the meeting.¶
The concept is further expanded in [RFC8718], Section 3.2.4:¶
Overflow Hotels can be placed under contract, within convenient travel time to and from the Facility and at a variety of guest room rates¶
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 under-utilization of IETF contracted room blocks, exposing the IASA to financial risk and 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.¶
To address this, 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.¶
Section 3.2.2 of [RFC8718] and 3.2.4 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 has been a long-standing feature of IETF meetings. It is described in the The Tao of the IETF (https://www.ietf.org/about/participate/tao/) as a dedicated room with extended opening hours beyond the normal hours of IETF meetings, Ethernet connectivity, a printer and a staffed helpdesk.¶
Both the Lounge and the Terminal Room are regularly but lightly used, 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 hiring 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.¶
To address this, is updated as follows: [RFC8718]¶
Section 3.2.2 is updated so that the bullet on ad-hoc meeting space now reads:¶
There are sufficient, easily accessible places within the Facility for people to hold ad hoc conversations and group discussions.¶
Section 3.2.4 is updated so that the bullet on the lounge now reads:¶
There are sufficient places within the Facility suitable for people to work online on their own devices.¶
[RFC8718] provides the following mandatory criteria:¶
- It MUST be possible to provision Internet Access to the Facility and IETF Hotels¶
This is further defined as "unfiltered" as follows:¶
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.¶
There is a wide spectrum of activities that may be considered "filtering", and not all of those are likely to be unacceptable to IETF participants. 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 https://en.wikipedia.org/wiki/Internet_censorship_in_New_Zealand. Discussions with the community indicate that a meeting in such a country would not be considered a breach of the meeting criterion above.¶
To address this, Section 2.1 of [RFC8718] is updated to include the following as part of the core value relating to Internet Access:¶
Neither the Facility network, the IETF Hotels network, nor any upstream providers may impose technical constraints that affect the ability of meeting attendees (whether remote or onsite) to participate in the meeting or development of Internet protocols. That means that some filtering (e.g. for DoS protection, or locally mandated blocking of access to known CSAM sites) may be acceptable, but that broad, non-transparent filtering (e.g. port blocking or extensive government censorship of VPNs, web sites or email providers) are not acceptable. Where any filtering is unavoidable, or recommended by the IETF meeting NOC, the mechanisms used should be openly described as soon as is practical (e.g. before the meeting if local mandates are imposed, or during a meeting if in response to some attack/events).¶
This memo includes no request to IANA.¶
This document should not affect the security of the Internet.¶
Thanks to all of the contributors: Laura Nugent, Stephanie McCammon, Alexa Morris, Greg Wood, Lars Eggert and Jason Livingood. Special thanks to Stephen Farrell for the text updating relating to Internet filtering.¶