wdiff rfc9712.original rfc9712.txt

Internet Engineering Task Force (IETF) J. Daley, Ed.
Internet-Draft
Request for Comments: 9712 S. Turner
Updates: 8718 8718, 8719 (if approved) IETF Administration LLC
Intended status:
Category: Best Current Practice 13 August December 2024
Expires: 14 February 2025
ISSN: 2070-1721

IETF Meeting Venue Requirements Review
draft-daley-gendispatch-venue-requirements-03

Abstract

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

Editorial Note

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>. IETF" (RFC 8719).

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 memo documents an Internet Best Current Practice.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of six months RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 February 2025.
https://www.rfc-editor.org/info/rfc9712.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Summary of changes Changes to RFC8718 RFCs 8718 and RFC8719: . . . . . . . . . 3 8719
3. The Meeting (Rotation) Policy and Exploratory Meetings . . . 3
3.1. Current Policy . . . . . . . . . . . . . . . . . . . . . 3
3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Resolution: Replacement of the process Process for an exploratory
meeting . . . . . . . . . . . . . . . . . . . . . . . . . 4 Exploratory
Meeting
4. Hotels and the Facility . . . . . . . . . . . . . . . . . . . . . 5
4.1. The “One Roof” "One-Roof" Preference . . . . . . . . . . . . . . . . 5
4.1.1. Current Policy . . . . . . . . . . . . . . . . . . . 5
4.1.2. Discussion . . . . . . . . . . . . . . . . . . . . . 5
4.1.3. Resolution: Clarification of Interpretation . . . . . 7
4.2. Number of rooms reserved . . . . . . . . . . . . . . . . 7 Rooms Reserved
4.2.1. Current Policy . . . . . . . . . . . . . . . . . . . 7
4.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . 7
4.2.3. Resolution: Update to RFC 8718 . . . . . . . . . . . 8
4.3. Overflow Hotels . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Current Policy . . . . . . . . . . . . . . . . . . . 8
4.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . 8
4.3.3. Resolution: Clarification of Interpretation . . . . . 9
4.4. Ad-hoc Ad Hoc Space Including including the Lounge and Terminal Room . . . 9
4.4.1. Current Policy . . . . . . . . . . . . . . . . . . . 9
4.4.2. Discussion . . . . . . . . . . . . . . . . . . . . . 9
4.4.3. Resolution: Update to RFC 8718 . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10

1. Introduction

IETF meeting venues are researched, negotiated, booked booked, and managed
in accordance with [RFC8718] “IETF "IETF Plenary Meeting Venue Selection
Process” Process"
[RFC8718] and [RFC8719] "High-Level Guidance for the Meeting Policy of the IETF".
IETF" [RFC8719]. While these RFCs were published in 2020, the
substantive work was completed in 2018 2018, and since then then, there have
been a number of developments that have affected the efficacy of our 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 Changes to [RFC8718] RFCs 8718 and [RFC8719]: 8719

1. Updates the Meeting (Rotation) Policy of 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 of specified in [RFC8718] from “one-third
"one-third or more of the projected attendees” meeting attendees" to a more
flexible “sufficient "sufficient rooms to meet the expected demand”. demand".

4. Clarifies that the IASA should interpret any reference to
Overflow Hotels
"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] that specify ad-hoc space
to better match the community requirements 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. 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
| "*").

Furthermore, Section 4 of [RFC8719] further sets out 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 it,
and the IETF Chair 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 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 Process for an exploratory meeting 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 community, and deferring to
the IESG if there is any concern that the core objective from
[RFC8718] of 'why we meet’ 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” "One-Roof" Preference

4.1.1. Current Policy

[RFC8718] defines “IETF Hotels” "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" "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 (convention (e.g., convention centers with
have separate contacts for Audio/Visual services, Food/Beverages, 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 move 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 to
accommodate us.

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

2. A meeting space not co-located with a hotel, normally hotel (normally a
convention center, 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.

* Convention centers generally have a range of nearby hotels
enabling It enables the IASA to negotiate a lower room rate than
otherwise.
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.

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

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 is not taken, then many cities
and potentially some countries would will 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 whereas a convention center, where center shifts the
costs are shifted more towards onto the IASA.

Despite "one-roof" "one roof" being expressed as a preference in [RFC8718] [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 other another
facility without a directly attached hotel, the “close proximity” "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 it should be a safe walk,
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 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 to secure in securing a booking, as they aim to protect
themselves from any similar sudden loss of income. For example, many
hotels are now requiring payment in conference organizers to provide full
payment in advance for guest room
blocks from conference organizers. blocks.

Where the IASA can get a large room block, it is finding that hotels
are less willing to provide good discounts and discounts, so room pricing is not
always on a par with other nearby hotels, with 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, this issue, this document updates Section 3.2.4 of
[RFC8718] to
replace the requirement for by replacing the total room block in the requirement for IETF
Hotels from “one-third "one-third or more of the projected attendees” meeting attendees" to a
more flexible
“sufficient "sufficient rooms to meet the expected demand”. 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 IASA IETF has negotiated a group room rate for the purposes
| of the meeting.

The concept is further expanded in [RFC8718], Section 3.2.4: 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 under-utilization underutilization
of IETF contracted room blocks, blocks and exposing the IASA to financial
risk
and with little benefit to participants. As a result, the use of
overflow hotels has reduced reduced, and they are rarely contracted.
However, due to the way they are incorporated into [RFC8718] [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, 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 Ad Hoc Space Including including the Lounge and Terminal Room

4.4.1. Current Policy

Section

Sections 3.2.2 of [RFC8718] 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 Room (described as a
dedicated room with extended opening hours beyond the normal hours of
IETF meetings, meetings), Ethernet connectivity, a printer printer, and a staffed
helpdesk, has help
desk have been a long-standing feature features of IETF meetings.

4.4.2. Discussion

Both the Lounge and the Terminal Room are used regularly but lightly used, lightly,
i.e., far below capacity. The reason for this is explained in the
feedback to post-meeting surveys: most Most participants want an
immediately accessible ad-hoc 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 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, this issue, [RFC8718] is updated as follows: [RFC8718]

1. Section 3.2.2 of [RFC8718] is updated so that the bullet entry on ad-hoc 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 bullet 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 memo includes document has no request to IANA. 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 all of the contributors: Laura Nugent, Stephanie McCammon,
Alexa Morris, Greg Wood, Lars Eggert 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
Email: jay@staff.ietf.org

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