rfc9712.original   rfc9712.txt 
Internet Engineering Task Force J. Daley, Ed. Internet Engineering Task Force (IETF) J. Daley, Ed.
Internet-Draft S. Turner Request for Comments: 9712 S. Turner
Updates: 8718 8719 (if approved) IETF Administration LLC BCP: 226 IETF Administration LLC
Intended status: Best Current Practice 13 August 2024 Updates: 8718, 8719 January 2025
Expires: 14 February 2025 Category: Best Current Practice
ISSN: 2070-1721
IETF Meeting Venue Requirements Review IETF Meeting Venue Requirements Review
draft-daley-gendispatch-venue-requirements-03
Abstract Abstract
Following a review of the IETF meeting venue requirements, this Following a review of the IETF meeting venue requirements, this
document proposes updates to RFC 8718 “IETF Plenary Meeting Venue document updates RFC 8718 ("IETF Plenary Meeting Venue Selection
Selection Process”, clarifies how the IETF Administration Support Process"), clarifies how the IETF Administration Support Activity
Activity (IASA) should interpret some elements of RFC 8718, and (IASA) should interpret some elements of RFC 8718, and specifies a
proposes a replacement exploratory meeting process, thereby updating replacement exploratory meeting process, thereby updating RFC 8719
RFC 8719 "High-Level Guidance for the Meeting Policy of the IETF". ("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>.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 14 February 2025. 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 Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Summary of changes to RFC8718 and RFC8719: . . . . . . . . . 3 2. Summary of Changes to RFCs 8718 and 8719
3. The Meeting (Rotation) Policy and Exploratory Meetings . . . 3 3. The Meeting (Rotation) Policy and Exploratory Meetings
3.1. Current Policy . . . . . . . . . . . . . . . . . . . . . 3 3.1. Current Policy
3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Discussion
3.3. Resolution: Replacement of the process for an exploratory 3.3. Resolution: Replacement of the Process for an Exploratory
meeting . . . . . . . . . . . . . . . . . . . . . . . . . 4 Meeting
4. Hotels and Facility . . . . . . . . . . . . . . . . . . . . . 5 4. Hotels and the Facility
4.1. The “One Roof” Preference . . . . . . . . . . . . . . . . 5 4.1. The "One-Roof" Preference
4.1.1. Current Policy . . . . . . . . . . . . . . . . . . . 5 4.1.1. Current Policy
4.1.2. Discussion . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. Discussion
4.1.3. Resolution: Clarification of Interpretation . . . . . 7 4.1.3. Resolution: Clarification of Interpretation
4.2. Number of rooms reserved . . . . . . . . . . . . . . . . 7 4.2. Number of Rooms Reserved
4.2.1. Current Policy . . . . . . . . . . . . . . . . . . . 7 4.2.1. Current Policy
4.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Discussion
4.2.3. Resolution: Update to RFC 8718 . . . . . . . . . . . 8 4.2.3. Resolution: Update to RFC 8718
4.3. Overflow Hotels . . . . . . . . . . . . . . . . . . . . . 8 4.3. Overflow Hotels
4.3.1. Current Policy . . . . . . . . . . . . . . . . . . . 8 4.3.1. Current Policy
4.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . 8 4.3.2. Discussion
4.3.3. Resolution: Clarification of Interpretation . . . . . 9 4.3.3. Resolution: Clarification of Interpretation
4.4. Ad-hoc Space Including the Lounge and Terminal Room . . . 9 4.4. Ad Hoc Space including the Lounge and Terminal Room
4.4.1. Current Policy . . . . . . . . . . . . . . . . . . . 9 4.4.1. Current Policy
4.4.2. Discussion . . . . . . . . . . . . . . . . . . . . . 9 4.4.2. Discussion
4.4.3. Resolution: Update to RFC 8718 . . . . . . . . . . . 10 4.4.3. Resolution: Update to RFC 8718
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses
1. Introduction 1. Introduction
IETF meeting venues are researched, negotiated, booked and managed in IETF meeting venues are researched, negotiated, booked, and managed
accordance with [RFC8718] “IETF Plenary Meeting Venue Selection in accordance with "IETF Plenary Meeting Venue Selection Process"
Process” and [RFC8719] "High-Level Guidance for the Meeting Policy of [RFC8718] and "High-Level Guidance for the Meeting Policy of the
the IETF". While these RFCs were published in 2020, the substantive IETF" [RFC8719]. While these RFCs were published in 2020, the
work was completed in 2018 and since then there have been a number of substantive work was completed in 2018, and since then, there have
developments that have affected the efficacy of our current model for been a number of developments that have affected the efficacy of the
IETF meetings. current model for IETF meetings.
The IASA has reviewed the venue selection in light of these The IASA has reviewed the venue selection in light of these
developments, primarily informed by the staff who work on venue developments, primarily informed by the staff who work on venue
selection, and has identified a number of issues to be addressed by a selection, and has identified a number of issues to be addressed by a
combination of updates to those RFCs and clarifications of combination of updates to those RFCs and clarifications of
interpretation. interpretation.
2. Summary of changes to [RFC8718] and [RFC8719]: 2. Summary of Changes to RFCs 8718 and 8719
1. Updates the Meeting (Rotation) Policy of [RFC8719] with a new This document makes the following changes to [RFC8718] and [RFC8719]:
process for the selection of exploratory meetings.
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 2. Clarifies the interpretation of "close proximity" as used in
[RFC8718]. [RFC8718].
3. Updates the room block requirement of [RFC8718] from “one-third 3. Updates the room block requirement specified in [RFC8718] from
of the projected attendees” to a more flexible “sufficient rooms "one-third or more of projected meeting attendees" to a more
to meet the expected demand”. flexible "sufficient rooms to meet the expected demand".
4. Clarifies that the IASA should interpret any reference to 4. Clarifies that the IASA should interpret any reference to
Overflow Hotels in [RFC8718] as an entirely optional feature that "Overflow Hotels" in [RFC8718] as an entirely optional feature
the IASA can choose to provide at its own discretion. that the IASA can choose to provide at its own discretion.
5. Updates various parts of [RFC8718] that specify ad-hoc space to 5. Updates the ad hoc space specified in various parts of [RFC8718]
better match the community requirements as expressed in post- to better match the community requirements, as expressed in post-
meeting surveys. meeting surveys.
3. The Meeting (Rotation) Policy and Exploratory Meetings 3. The Meeting (Rotation) Policy and Exploratory Meetings
3.1. Current Policy 3.1. Current Policy
The current meeting rotation policy is set as the "1-1-1-*" policy in The current meeting (rotation) policy is set as the "1-1-1-*" policy
[RFC8719]: in [RFC8719]:
| [...] the meeting policy (let's call this the "1-1-1" policy) is | [...] the meeting policy (let's call this the "1-1-1" policy) is
| that meetings should rotate between North America, Europe, and | that meetings should rotate between North America, Europe, and
| Asia. the 1-1-1-* meeting policy is a slightly modified version of | Asia.
| the aforementioned 1-1-1 meeting policy that allows for additional
| flexibility in the form of an exploratory meeting (denoted with an
| "*").
and and
| [...] the 1-1-1-* meeting policy is a slightly modified version of | [...] the 1-1-1-* meeting policy is a slightly modified version of
| the aforementioned 1-1-1 meeting policy that allows for additional | the aforementioned 1-1-1 meeting policy that allows for additional
| flexibility in the form of an exploratory meeting (denoted with an | flexibility in the form of an exploratory meeting (denoted with an
| "*"). | "*").
Section 4 of [RFC8719] further sets out the process for agreeing on Furthermore, Section 4 of [RFC8719] describes the process for
an exploratory meeting, which includes the requirement for a agreeing on an exploratory meeting, which includes the requirement
participant to nominate the city, the community to discuss it and the for a participant to nominate the city, the community to discuss it,
IETF Chair to determine if there is consensus for the city to be and the IETF chair to determine if there is consensus for the city to
considered suitable. be considered suitable.
3.2. Discussion 3.2. Discussion
Community consensus is a very high bar, much higher than is required Community consensus is a very high bar, much higher than is required
for a meeting in Asia, Europe or North America. For those ordinary for a meeting in Asia, Europe, or North America. For those ordinary
meetings, the IASA considers community feedback but is ultimately the meetings, the IASA considers community feedback but is ultimately the
decision maker and can choose to go ahead with a meeting in a decision maker and can choose to go ahead with a meeting in a
particular city even if there is no community consensus on the particular city even if there is no community consensus on the
suitability of that city for an IETF meeting. Furthermore, it has suitability of that city for an IETF meeting. Furthermore, it has
been demonstrated by the low attendance at some exploratory meetings been demonstrated by the low attendance at some exploratory meetings
that community consensus is orthogonal to the viability of meeting in that community consensus is orthogonal to the viability of meeting in
a particular city. a particular city.
3.3. Resolution: Replacement of the process for an exploratory meeting 3.3. Resolution: Replacement of the Process for an Exploratory Meeting
This document replaces Section 4 of [RFC8719] and sets the new This document replaces Section 4 of [RFC8719] and sets the new
process as follows: process as follows:
Exploratory meetings may be scheduled by the IASA following its Exploratory meetings may be scheduled by the IASA following its
normal processes, including those for assessing the suitability of a normal processes, including those for assessing the suitability of a
particular city, consulting with the IETF community and deferring to particular city, consulting with the IETF community, and deferring to
the IESG if there is any concern that the core objective from the IESG if there is any concern that the core objective from
[RFC8718] of 'why we meet’ might not be met. [RFC8718] of 'why we meet' might not be met.
The IASA should ensure that the frequency of exploratory meetings is The IASA should ensure that the frequency of exploratory meetings is
such that it does not redefine the concept of 'exploratory' and that such that it does not redefine the concept of 'exploratory' and that
the distribution of exploratory meetings does not disproportionately the distribution of exploratory meetings does not disproportionately
impact meetings in the 1-1-1 regions. impact meetings in the 1-1-1 regions.
4. Hotels and Facility 4. Hotels and the Facility
4.1. The “One Roof” Preference 4.1. The "One-Roof" Preference
4.1.1. Current Policy 4.1.1. Current Policy
[RFC8718] defines “IETF Hotels” as: [RFC8718] defines "IETF Hotels" as:
| One or more hotels, in close proximity to the Facility, where the | One or more hotels, in close proximity to the Facility, where the
| IETF guest room block allocations are negotiated and where network | IETF guest room block allocations are negotiated and where network
| services managed by the IASA (e.g., the "IETF" SSID) are in use. | services managed by the IASA (e.g., the "IETF" SSID) are in use.
It also provides the following important criteria (only listing those It also provides the following important criteria (only listing those
directly relevant): directly relevant):
| * The IETF Hotels are within close proximity to each other and | * The IETF Hotels are within close proximity to each other and
| the Facility. | the Facility.
skipping to change at page 5, line 34 skipping to change at line 201
| * We have something of a preference for an IETF meeting to be | * We have something of a preference for an IETF meeting to be
| under "One Roof"; that is, qualified meeting space and guest | under "One Roof"; that is, qualified meeting space and guest
| rooms are available in the same facility. | rooms are available in the same facility.
4.1.2. Discussion 4.1.2. Discussion
What happens in practice is that the IASA books a venue that conforms What happens in practice is that the IASA books a venue that conforms
to one of two separate configurations: to one of two separate configurations:
1. A "one roof" venue of a hotel with the meeting space in the hotel 1. A "One-Roof" venue of a hotel with the meeting space in the hotel
or directly attached. or directly attached.
The advantages of this configuration are: The advantages of this configuration are:
* With a large enough room block, the meeting space is generally * With a large enough room block, the meeting space is generally
free. free.
* For those IETF participants (and staff) that normally stay in * For those IETF participants (and staff) that normally stay in
the IETF hotel, there is a strong sense of community. the IETF hotel, there is a strong sense of community.
* It is usually easier and more flexible to work with a single * It is usually easier and more flexible to work with a single
point of contact instead of several (convention centers with point of contact instead of several (e.g., convention centers
separate contacts for Audio/Visual services, Food/Beverages, have separate contacts for Audio/Visual services, Food/
and space). Beverage services, and meeting space).
* It can be much cheaper for the IASA than working with a * It can be much cheaper for the IASA than working with a
separate convention center. separate convention center.
* Group discussions can more naturally move from the facility to * Group discussions can move more naturally from the Facility to
the hotel. the hotel.
* It is easier to negotiate network changes to the hotel as part * It is easier to negotiate network changes to the hotel as part
of an overall network package. of an overall network package.
* Someone can walk from their room to the meeting space in a few * Someone can walk from their room to the meeting space in a few
minutes, staying indoors the whole time. minutes, staying indoors the whole time.
The disadvantages are: The disadvantages are:
* There are a limited number of hotels (and therefore cities) * There are a limited number of hotels (and therefore cities)
with large enough meeting space and sufficient rooms to with large enough meeting space and sufficient rooms.
accommodate us.
* The room rates at conference hotels are often on the high side * The room rates at conference hotels are often on the high
and it can be more expensive for IETF participants. side, which can be more expensive for IETF participants.
2. A meeting space not co-located with a hotel, normally a 2. A meeting space not co-located with a hotel (normally a
convention center, but where there are hotels within a short convention center) but where there are hotels within a short
walk. walk.
The advantages of this configuration are: The advantages of this configuration are:
* It makes many more cities available as potential venues. * It makes many more cities available as potential venues.
* It provides more options for local hotels. * It provides more options for local hotels.
* Convention centers generally have a range of nearby hotels * It enables the IASA to negotiate a lower room rate than
enabling the IASA to negotiate a lower room rate than otherwise as convention centers generally have a range of
otherwise. hotels nearby.
The disadvantages are: The disadvantages are:
* Convention centers are much more difficult to negotiate with * Convention centers are much more difficult to negotiate with
and less flexible. and are less flexible.
* The IASA has to pay for the meeting space. * The IASA has to pay for the meeting space.
* For those IETF participants (and staff) that normally stay in * For those IETF participants (and staff) that normally stay in
the IETF hotel, the sense of community is diminished. the IETF hotel, the sense of community is diminished.
* Choice of a main hotel and negotiation of the network for that * The choice of a main hotel and negotiation for the network at
hotel are more complicated. that hotel are more complicated.
While a "one-roof" venue is preferred, there are a limited number of To meet in cities that do not have suitable "One-Roof" venues, the
hotels (and therefore cities) with large enough meeting space and IASA needs to work with convention centers. If this approach is not
sufficient rooms to accommodate us. To meet in cities that do not taken, then many cities and potentially some countries will be
have suitable "one-roof" venues, the IASA needs to work with practically excluded as meeting venues.
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 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 meeting onto participants whereas a convention center shifts the
the costs are shifted more towards the IASA. costs onto the IASA.
Despite "one-roof" being expressed as a preference in [RFC8718] there Despite "One Roof" being expressed as a preference in [RFC8718],
are some in the community who consider it as the only way to meet the there are some in the community who consider it as the only way to
requirement for "close proximity". meet the requirement for "close proximity".
4.1.3. Resolution: Clarification of Interpretation 4.1.3. Resolution: Clarification of Interpretation
To address this concern, the IASA should interpret the "close To address this concern, the IASA should interpret the "close
proximity" requirement of [RFC8718] as follows: proximity" requirement of [RFC8718] as follows:
Where the meeting space is a convention center or other facility Where the meeting space is a convention center or another
without a directly attached hotel, the “close proximity” requirement facility without a directly attached hotel, the "close
for the IETF Hotels should be taken to mean that the time it takes proximity" requirement for the IETF Hotels should mean that the
to walk from the IETF Hotels to the meeting space should be no time it takes to walk from the IETF Hotels to the meeting space
longer than ten minutes, and a safe walk, including early in the should be no longer than ten minutes, and it should be a safe
morning and late at night. walk including early in the morning and late at night.
It should be noted that Section 3.2.2 of [RFC8718] already uses a It should be noted that Section 3.2.2 of [RFC8718] already uses a
walkability test of 5-10 minutes for a similar purpose. walkability test of 5-10 minutes for a similar purpose.
4.2. Number of rooms reserved 4.2. Number of Rooms Reserved
4.2.1. Current Policy 4.2.1. Current Policy
[RFC8718] includes the following requirement as an important [RFC8718] includes the following requirement as an important
criterion: criterion:
| * The guest rooms at the IETF Hotels are sufficient in number to | * The guest rooms at the IETF Hotels are sufficient in number to
| house one-third or more of the projected meeting attendees. | house one-third or more of the projected meeting attendees.
4.2.2. Discussion 4.2.2. Discussion
COVID-driven cancellations and lockdowns have badly affected the COVID-driven cancellations and lockdowns have badly affected the
hospitality industry overall. Hotels and convention centers are now hospitality industry overall. Hotels and convention centers are now
much more cautious about the terms of their bookings and much less much more cautious about the terms of their bookings and much less
willing to invest to secure a booking, as they aim to protect willing to invest in securing a booking, as they aim to protect
themselves from any similar sudden loss of income. For example, many themselves from any similar sudden loss of income. For example, many
hotels are now requiring payment in full in advance for guest room hotels are now requiring conference organizers to provide full
blocks from conference organizers. payment in advance for guest room blocks.
Where the IASA can get a large room block, it is finding that hotels 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 are less willing to provide good discounts, so room pricing is not
always on a par with other nearby hotels, with a smaller number of always on a par with other nearby hotels that have a smaller number
available rooms. of available rooms.
Then there is the impact of the now ubiquitous offering of short-term Then there is the impact of the now ubiquitous offering of short-term
apartment rental sites. These sites are significant competitors to apartment rental sites. These sites are significant competitors to
hotels for traveler accommodation both in price and availability. hotels for traveler accommodation both in price and availability.
The net result is that the IASA is reserving more hotel rooms than 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 are being used, which exposes it to unnecessary risk as they are
required to financially guarantee certain levels of occupancy, and required to financially guarantee certain levels of occupancy, and
leads to wasted effort. this leads to wasted effort.
4.2.3. Resolution: Update to RFC 8718 4.2.3. Resolution: Update to RFC 8718
To address this, this document updates Section 3.2.4 of [RFC8718] to To address this issue, this document updates Section 3.2.4 of
replace the requirement for the total room block in the IETF Hotels [RFC8718] by replacing the total room block requirement for IETF
from “one-third of the projected attendees” to a more flexible Hotels from "one-third or more of projected meeting attendees" to a
“sufficient rooms to meet the expected demand”. more flexible "sufficient rooms to meet the expected demand".
4.3. Overflow Hotels 4.3. Overflow Hotels
4.3.1. Current Policy 4.3.1. Current Policy
Section 1 of [RFC8718] defines "Overflow Hotels" as follows: Section 1 of [RFC8718] defines "Overflow Hotels" as follows:
| One or more hotels, usually in close proximity to the Facility, | One or more hotels, usually in close proximity to the Facility,
| where the IASA has negotiated a group room rate for the purposes | where the IETF has negotiated a group room rate for the purposes
| of the meeting. | of the meeting.
The concept is further expanded in [RFC8718], Section 3.2.4: The concept is further expanded in Section 3.2.4 of [RFC8718]:
| Overflow Hotels can be placed under contract, within convenient | Overflow Hotels can be placed under contract, within convenient
| travel time to and from the Facility and at a variety of guest | travel time to and from the Facility and at a variety of guest
| room rates | room rates
4.3.2. Discussion 4.3.2. Discussion
The IASA has historically contracted with overflow hotels including The IASA has historically contracted with Overflow Hotels including
those at other price points from the IETF Hotels. They were very those at other price points from the IETF Hotels. They were very
underutilized by attendees, reflecting the general under-utilization underutilized by attendees, reflecting the general underutilization
of IETF contracted room blocks, exposing the IASA to financial risk of IETF contracted room blocks and exposing the IASA to financial
and with little benefit to participants. As a result, the use of risk with little benefit to participants. As a result, the use of
overflow hotels has reduced and they are rarely contracted. However, Overflow Hotels has reduced, and they are rarely contracted.
due to the way they are incorporated into [RFC8718] there are still However, due to the way they are incorporated into [RFC8718], there
many who believe these are, or should be, a normal feature of IETF are still many who believe these are, or should be, a normal feature
meetings. of IETF meetings.
4.3.3. Resolution: Clarification of Interpretation 4.3.3. Resolution: Clarification of Interpretation
To address this, the IASA should interpret any reference to Overflow To address this issue, the IASA should interpret any reference to
Hotels as an entirely optional feature that the IASA can choose to Overflow Hotels as an entirely optional feature that the IASA can
provide at its own discretion. choose to provide at its own discretion.
4.4. Ad-hoc Space Including the Lounge and Terminal Room 4.4. Ad Hoc Space including the Lounge and Terminal Room
4.4.1. Current Policy 4.4.1. Current Policy
Section 3.2.2 of [RFC8718] and 3.2.4 include the following Sections 3.2.2 and 3.2.4 of [RFC8718] include the following
requirements as important criteria: requirements as important criteria:
| * There are sufficient places (e.g., a mix of hallways, bars, | * There are sufficient places (e.g., a mix of hallways, bars,
| meeting rooms, and restaurants) for people to hold ad hoc | meeting rooms, and restaurants) for people to hold ad hoc
| conversations and group discussions in the combination of | conversations and group discussions in the combination of
| spaces offered by the facilities, hotels, and bars/restaurants | spaces offered by the facilities, hotels, and bars/restaurants
| in the surrounding area, within walking distance (5-10 | in the surrounding area, within walking distance (5-10
| minutes). | minutes).
| |
| * At least one IETF Hotel or the Facility has a space for use as | * At least one IETF Hotel or the Facility has a space for use as
| a lounge, conducive to planned and ad hoc meetings and | a lounge, conducive to planned and ad hoc meetings and
| chatting, as well as a space for working online. There are | chatting, as well as a space for working online. There are
| tables with seating, convenient for small meetings with | tables with seating, convenient for small meetings with
| laptops. These can be at an open bar or casual restaurant. | laptops. These can be at an open bar or casual restaurant.
| Preferably the lounge area is centrally located, permitting | Preferably the lounge area is centrally located, permitting
| easy access to participants. | easy access to participants.
While not a formal requirement, a Terminal Room, described as a While not a formal requirement, a terminal room (described as a
dedicated room with extended opening hours beyond the normal hours of dedicated room with extended opening hours beyond the normal hours of
IETF meetings, Ethernet connectivity, a printer and a staffed IETF meetings), Ethernet connectivity, a printer, and a staffed help
helpdesk, has been a long-standing feature of IETF meetings. desk have been long-standing features of IETF meetings.
4.4.2. Discussion 4.4.2. Discussion
Both the Lounge and the Terminal Room are regularly but lightly used, Both the lounge and the terminal room are used regularly but lightly,
far below capacity. The reason for this is explained in the feedback i.e., far below capacity. The reason for this is explained in the
to post-meeting surveys: most participants want an immediately feedback to post-meeting surveys: Most participants want an
accessible ad-hoc meeting space, which is best provided by plenty of immediately accessible ad hoc meeting space, which is best provided
hallway seating. The IASA has responded to this feedback by adopting by plenty of hallway seating. The IASA has responded to this
a new practice of hiring in hallway seating whenever that provided by feedback by adopting a new practice of bringing in additional in-
the venue is insufficient. hallway seating whenever that provided by the venue is insufficient.
Dedicated rooms, such as the Lounge or Terminal Room, or external Dedicated rooms, such as the lounge or terminal room, or external
facilities "within walking distance (5-10 minutes)" are unsuitable facilities "within walking distance (5-10 minutes)" are unsuitable
for the majority of participant needs, though there remains a need for the majority of participant needs, though there remains a need
for quiet places to work between sessions. for quiet places to work between sessions.
4.4.3. Resolution: Update to RFC 8718 4.4.3. Resolution: Update to RFC 8718
To address this, is updated as follows: [RFC8718] To address this issue, [RFC8718] is updated as follows:
1. Section 3.2.2 is updated so that the bullet on ad-hoc meeting 1. Section 3.2.2 of [RFC8718] is updated so that the entry on ad hoc
space now reads: meeting space (first bullet) now reads:
There are sufficient, easily accessible places within the | There are sufficient, easily accessible places within the
Facility for people to hold ad hoc conversations and group | Facility for people to hold ad hoc conversations and group
discussions. | discussions.
2. Section 3.2.4 is updated so that the bullet on the lounge now 2. Section 3.2.4 of [RFC8718] is updated so that the entry on the
reads: lounge (sixth bullet) now reads:
There are sufficient places within the Facility suitable for | There are sufficient places within the Facility suitable for
people to work online on their own devices. | people to work online on their own devices.
5. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
This document should not affect the security of the Internet. This document should not affect the security of the Internet.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC8718] Lear, E., Ed., "IETF Plenary Meeting Venue Selection [RFC8718] Lear, E., Ed., "IETF Plenary Meeting Venue Selection
Process", BCP 226, RFC 8718, DOI 10.17487/RFC8718, Process", BCP 226, RFC 8718, DOI 10.17487/RFC8718,
February 2020, <https://www.rfc-editor.org/info/rfc8718>. February 2020, <https://www.rfc-editor.org/info/rfc8718>.
[RFC8719] Krishnan, S., "High-Level Guidance for the Meeting Policy [RFC8719] Krishnan, S., "High-Level Guidance for the Meeting Policy
of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719, of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719,
February 2020, <https://www.rfc-editor.org/info/rfc8719>. February 2020, <https://www.rfc-editor.org/info/rfc8719>.
Contributors Contributors
Thanks to all of the contributors: Laura Nugent, Stephanie McCammon, Thanks to the following people for their contributions to this
Alexa Morris, Greg Wood, Lars Eggert and Jason Livingood. document: Laura Nugent, Stephanie McCammon, Alexa Morris, Greg Wood,
Lars Eggert, and Jason Livingood.
Authors' Addresses Authors' Addresses
Jay Daley (editor) Jay Daley (editor)
IETF Administration LLC IETF Administration LLC
1000 N. West Street, Suite 1200 1000 N. West Street, Suite 1200
Wilimington, DE 19801 Wilmington, DE 19801
United States of America United States of America
Email: jay@staff.ietf.org Email: jay@staff.ietf.org
Sean Turner Sean Turner
IETF Administration LLC IETF Administration LLC
1000 N. West Street, Suite 1200 1000 N. West Street, Suite 1200
Wilimington, DE 19801 Wilmington, DE 19801
United States of America United States of America
Email: sean@sn3rd.com Email: sean@sn3rd.com
 End of changes. 65 change blocks. 
195 lines changed or deleted 180 lines changed or added

This html diff was produced by rfcdiff 1.48.