rfc9712.original.xml   rfc9712.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!-- pre-edited by ST 10/01/24 -->
<!-- formatted by ST 11/08/24 -->
<!-- reference review by TH 11/18/24 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="bcp" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="bcp" docName="draft-da
docName="draft-daley-gendispatch-venue-requirements-03" ipr="trust200902" ley-gendispatch-venue-requirements-03" ipr="trust200902" number="9712" updates="
updates="8718 8719" submissionType="IETF" xml:lang="en" version="3" consensus= 8718, 8719" obsoletes="" tocInclude="true" submissionType="IETF" xml:lang="en" v
"true"> ersion="3" consensus="true" sortRefs="true" symRefs="true">
<front> <front>
<title>IETF Meeting Venue Requirements Review</title>
<seriesInfo name="Internet-Draft" value="draft-daley-gendispatch-venue-requi
rements-03"/>
<title abbrev="IETF Meeting Venue Requirements Review">IETF Meeting Venue Re
quirements Review</title>
<seriesInfo name="RFC" value="9712"/>
<seriesInfo name="BCP" value="226"/>
<author fullname="Jay Daley" initials="J." surname="Daley" role="editor"> <author fullname="Jay Daley" initials="J." surname="Daley" role="editor">
<organization abbrev="IETF Administration LLC">IETF Administration LLC</or ganization> <organization abbrev="IETF Administration LLC">IETF Administration LLC</or ganization>
<address> <address>
<postal> <postal>
<street>1000 N. West Street, Suite 1200</street> <street>1000 N. West Street, Suite 1200</street>
<city>Wilimington</city> <city>Wilmington</city>
<region>DE</region> <region>DE</region>
<code>19801</code> <code>19801</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>jay@staff.ietf.org</email> <email>jay@staff.ietf.org</email>
</address> </address>
</author> </author>
<author fullname="Sean Turner" initials="S." surname="Turner"> <author fullname="Sean Turner" initials="S." surname="Turner">
<organization abbrev="IETF Administration LLC">IETF Administration LLC</or ganization> <organization abbrev="IETF Administration LLC">IETF Administration LLC</or ganization>
<address> <address>
<postal> <postal>
<street>1000 N. West Street, Suite 1200</street> <street>1000 N. West Street, Suite 1200</street>
<city>Wilimington</city> <city>Wilmington</city>
<region>DE</region> <region>DE</region>
<code>19801</code> <code>19801</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>sean@sn3rd.com</email> <email>sean@sn3rd.com</email>
</address> </address>
</author> </author>
<date year="2024"/> <date year="2025" month="January"/>
<area>General</area> <abstract>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract> <t>Following a review of the IETF meeting venue requirements, this documen
<t>Following a review of the IETF meeting venue requirements, this documen t updates RFC 8718 ("IETF Plenary Meeting Venue Selection Process"), clarifies h
t proposes updates ow the IETF
to RFC 8718 “IETF Plenary Meeting Venue Selection Process”, clarifies ho Administration Support Activity (IASA) should interpret some elements of RFC 871
w the IETF 8, and specifies a replacement exploratory meeting process, thereby updating RFC
Administration Support Activity (IASA) should interpret some elements of 8719 ("High-Level Guidance for the Meeting Policy of the IETF").</t>
RFC 8718, and
proposes a replacement exploratory meeting process, thereby updating RFC
8719 "High-Level
Guidance for the Meeting Policy of the IETF".</t>
</abstract> </abstract>
<note title="Editorial Note">
<t>Discussion of this draft takes place on the mtgvenue mailing list, whic
h has its home page
at <eref target="https://www.ietf.org/mailman/listinfo/mtgvenue" bracket
s="angle"/>. </t>
<t>The source code and an issues list for this draft can be found at <eref
target="https://github.com/JayDaley/draft-daley-gendispatch-venue-requ
irements"
brackets="angle"/>. </t>
</note>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <name>Introduction</name>
<t>IETF meeting venues are researched, negotiated, booked and managed in a <t>IETF meeting venues are researched, negotiated, booked, and managed in
ccordance with <xref accordance with
target="RFC8718"/> “IETF Plenary Meeting Venue Selection Process” and "IETF Plenary Meeting Venue Selection Process" <xref target="RFC8718"/> an
<xref d "High-Level Guidance for the Meeting Policy of the IETF" <xref target="RFC8719
target="RFC8719"/> "High-Level Guidance for the Meeting Policy of the "/>. While these RFCs were published in 2020, the substantive work was completed
IETF". While these in 2018, and since then, there have been a number of developments that have aff
RFCs were published in 2020, the substantive work was completed in 2018 ected the efficacy of the current model for IETF meetings.</t>
and since then there
have been a number of developments that have affected the efficacy of ou
r current model for
IETF meetings.</t>
<t>The IASA has reviewed the venue selection in light of these development s, primarily <t>The IASA has reviewed the venue selection in light of these development s, primarily
informed by the staff who work on venue selection, and has identified a number of issues to 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 clarification s of be addressed by a combination of updates to those RFCs and clarification s of
interpretation.</t> interpretation.</t>
</section> </section>
<section> <section>
<name>Summary of changes to <xref target="RFC8718"/> and <xref target="RFC <name>Summary of Changes to RFCs 8718 and 8719</name>
8719"/>:</name>
<t> This document makes the following changes to <xref target="RFC8718"/> a
nd <xref target="RFC8719"/>:</t>
<ol> <ol>
<li>Updates the Meeting (Rotation) Policy of <xref target="RFC8719"/> wi th a new process for <li>Updates the meeting (rotation) policy specified in <xref target="RF C8719"/> with a new process for
the selection of exploratory meetings.</li> the selection of exploratory meetings.</li>
<li>Clarifies the interpretation of "close proximity" as used in <xref t arget="RFC8718" <li>Clarifies the interpretation of "close proximity" as used in <xref t arget="RFC8718"
/>.</li> />.</li>
<li>Updates the room block requirement of <xref target="RFC8718"/> from
“one-third of the <li>Updates the room block requirement specified in <xref target="RFC8718"/>
projected attendees” to a more flexible “sufficient rooms to meet the from "one-third or more of
expected projected meeting attendees" to a more flexible "sufficient rooms to m
demand”.</li> eet the expected
<li>Clarifies that the IASA should interpret any reference to Overflow H demand".</li>
otels in <xref <li>Clarifies that the IASA should interpret any reference to "Overflow
Hotels" in <xref
target="RFC8718"/> as an entirely optional feature that the IASA can choose to provide target="RFC8718"/> as an entirely optional feature that the IASA can choose to provide
at its own discretion.</li> at its own discretion.</li>
<li>Updates various parts of <xref target="RFC8718"/> that specify ad-ho
c space to better <li>Updates the ad hoc space specified in various parts of <xref target=
match the community requirements as expressed in post-meeting surveys. "RFC8718"/>
</li> to better match the community requirements, as expressed in post-meeting
surveys.</li>
</ol> </ol>
</section> </section>
<section> <section>
<name>The Meeting (Rotation) Policy and Exploratory Meetings</name> <name>The Meeting (Rotation) Policy and Exploratory Meetings</name>
<section> <section>
<name>Current Policy</name> <name>Current Policy</name>
<t>The current meeting rotation policy is set as the "1-1-1-*" policy in <xref <t>The current meeting (rotation) policy is set as the "1-1-1-*" policy in <xref
target="RFC8719"/>:</t> target="RFC8719"/>:</t>
<blockquote><t>[...] the meeting policy (let's call this the "1-1-1" pol icy) is that <blockquote><t>[...] the meeting policy (let's call this the "1-1-1" pol icy) is that
meetings should rotate between North America, Europe, and Asia. the meetings should rotate between North America, Europe, and Asia.</t><
1-1-1-* meeting /blockquote>
policy is a slightly modified version of the aforementioned 1-1-1 me
eting policy that
allows for additional flexibility in the form of an exploratory meet
ing (denoted with an
"*").</t></blockquote>
<t>and</t> <t>and</t>
<blockquote><t>[...] the 1-1-1-* meeting policy is a slightly modified v ersion of the <blockquote><t>[...] the 1-1-1-* meeting policy is a slightly modified v ersion of the
aforementioned 1-1-1 meeting policy that allows for additional flexi bility in the form aforementioned 1-1-1 meeting policy that allows for additional flexi bility in the form
of an exploratory meeting (denoted with an "*").</t></blockquote> of an exploratory meeting (denoted with an "*").</t></blockquote>
<t><xref target="RFC8719" section="4"/> further sets out the process for agreeing on an <t>Furthermore, <xref target="RFC8719" section="4"/> describes the proce ss for agreeing on an
exploratory meeting, which includes the requirement for a participant to nominate the 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 t here is consensus city, the community to discuss it, and the IETF chair to determine if there is consensus
for the city to be considered suitable.</t> for the city to be considered suitable.</t>
</section> </section>
<section> <section>
<name>Discussion</name> <name>Discussion</name>
<t>Community consensus is a very high bar, much higher than is required for a meeting in <t>Community consensus is a very high bar, much higher than is required for a meeting in
Asia, Europe or North America. For those ordinary meetings, the IASA c onsiders community Asia, Europe, or North America. For those ordinary meetings, the IASA considers community
feedback but is ultimately the decision maker and can choose to go ahe ad with a meeting in feedback but is ultimately the decision maker and can choose to go ahe ad with a meeting in
a particular city even if there is no community consensus on the suita bility of that city a particular city even if there is no community consensus on the suita bility of that city
for an IETF meeting. Furthermore, it has been demonstrated by the low attendance at some for an IETF meeting. Furthermore, it has been demonstrated by the low attendance at some
exploratory meetings that community consensus is orthogonal to the via bility of meeting in exploratory meetings that community consensus is orthogonal to the via bility of meeting in
a particular city.</t> a particular city.</t>
</section> </section>
<section> <section>
<name>Resolution: Replacement of the process for an exploratory meeting< /name> <name>Resolution: Replacement of the Process for an Exploratory Meeting< /name>
<t>This document replaces <xref target="RFC8719" section="4"/> and sets the new process as <t>This document replaces <xref target="RFC8719" section="4"/> and sets the new process as
follows:</t> follows:</t>
<t>Exploratory meetings may be scheduled by the IASA following its norma l processes, <t>Exploratory meetings may be scheduled by the IASA following its norma l processes,
including those for assessing the suitability of a particular city, co nsulting with the including those for assessing the suitability of a particular city, co nsulting with the
IETF community and deferring to the IESG if there is any concern that the core objective from <xref target="RFC8718"/> of 'why we meet’ might not be m et.</t> IETF community, and deferring to the IESG if there is any concern that the core objective from <xref target="RFC8718"/> of 'why we meet' might not be met.</t>
<t>The IASA should ensure that the frequency of exploratory meetings is such that it does not <t>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 redefine the concept of 'exploratory' and that the distribution of
exploratory meetings does not disproportionately impact meetings in th e 1-1-1 regions.</t> exploratory meetings does not disproportionately impact meetings in th e 1-1-1 regions.</t>
</section> </section>
</section> </section>
<section> <section>
<name>Hotels and Facility</name> <name>Hotels and the Facility</name>
<section> <section>
<name>The “One Roof” Preference</name> <name>The "One-Roof" Preference</name>
<section> <section>
<name>Current Policy</name> <name>Current Policy</name>
<t><xref target="RFC8718"/> defines “IETF Hotels” as:</t> <t><xref target="RFC8718"/> defines "IETF Hotels" as:</t>
<blockquote>One or more hotels, in close proximity to the Facility, wh ere the IETF guest <blockquote>One or more hotels, in close proximity to the Facility, wh ere the IETF guest
room block allocations are negotiated and where network services man aged by the IASA room block allocations are negotiated and where network services man aged by the IASA
(e.g., the "IETF" SSID) are in use.</blockquote> (e.g., the "IETF" SSID) are in use.</blockquote>
<t>It also provides the following important criteria (only listing tho se directly <t>It also provides the following important criteria (only listing tho se directly
relevant):</t> relevant):</t>
<blockquote><ul> <blockquote><ul>
<li>The IETF Hotels are within close proximity to each other and t he Facility.</li> <li>The IETF Hotels are within close proximity to each other and t he Facility.</li>
</ul></blockquote> </ul></blockquote>
<t>Additionally, <xref target="RFC8718"/> contains this preference:</t > <t>Additionally, <xref target="RFC8718"/> contains this preference:</t >
<blockquote><ul> <blockquote><ul>
<li>We have something of a preference for an IETF meeting to be un der "One Roof"; that <li>We have something of a preference for an IETF meeting to be un der "One Roof"; that
is, qualified meeting space and guest rooms are available in the same facility.</li> is, qualified meeting space and guest rooms are available in the same facility.</li>
</ul></blockquote> </ul></blockquote>
</section> </section>
<section> <section>
<name>Discussion</name> <name>Discussion</name>
<t>What happens in practice is that the IASA books a venue that confor ms to one of two <t>What happens in practice is that the IASA books a venue that confor ms to one of two
separate configurations:</t> separate configurations:</t>
<ol> <ol type="1" spacing="normal">
<li><t>A "one roof" venue of a hotel with the meeting space in the h <li><t>A "One-Roof" venue of a hotel with the meeting space in the h
otel or directly otel or directly
attached.</t> attached.</t>
<t>The advantages of this configuration are:</t> <t>The advantages of this configuration are:</t>
<ul> <ul spacing="normal">
<li>With a large enough room block, the meeting space is general ly free.</li> <li>With a large enough room block, the meeting space is general ly free.</li>
<li>For those IETF participants (and staff) that normally stay i n the IETF hotel, there is a strong sense of community.</li> <li>For those IETF participants (and staff) that normally stay i n the IETF hotel, there is a strong sense of community.</li>
<li>It is usually easier and more flexible to work with a single point of contact <li>It is usually easier and more flexible to work with a single point of contact
instead of several (convention centers with separate contacts instead of several (e.g., convention centers have separate con
for Audio/Visual services, Food/Beverages, and tacts for Audio/Visual services, Food/Beverage services, and meeting space).</li
space).</li> >
<li>It can be much cheaper for the IASA than working with a sepa rate convention <li>It can be much cheaper for the IASA than working with a sepa rate convention
center.</li> center.</li>
<li>Group discussions can more naturally move from the facility to the hotel.</li> <li>Group discussions can move more naturally from the Facility to the hotel.</li>
<li>It is easier to negotiate network changes to the hotel as pa rt of an overall <li>It is easier to negotiate network changes to the hotel as pa rt of an overall
network package.</li> network package.</li>
<li>Someone can walk from their room to the meeting space in a f ew minutes, staying <li>Someone can walk from their room to the meeting space in a f ew minutes, staying
indoors the whole time. </li> indoors the whole time. </li>
</ul> </ul>
<t>The disadvantages are:</t> <t>The disadvantages are:</t>
<ul> <ul>
<!--[rfced] There are two instances of "to accommodate us". Is it okay
to refer to "us", or would it be clearer (or more formal) to say
"to accommodate the IETF meeting requirements" as shown below?
Original:
* There are a limited number of hotels (and therefore cities)
with large enough meeting space and sufficient rooms to
accommodate us.
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.
Perhaps:
* There are a limited number of hotels (and therefore cities)
with large enough meeting space and sufficient rooms to
accommodate the IETF meeting requirements.
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 the IETF meeting requirements.
-->
<li>There are a limited number of hotels (and therefore cities) with large enough <li>There are a limited number of hotels (and therefore cities) with large enough
meeting space and sufficient rooms to accommodate us.</li> meeting space and sufficient rooms.</li>
<li>The room rates at conference hotels are often on the high si <li>The room rates at conference hotels are often on the high si
de and it can be de, which can be
more expensive for IETF participants.</li> more expensive for IETF participants.</li>
</ul> </ul>
</li> </li>
<li><t>A meeting space not co-located with a hotel, normally a conve ntion center, but <li><t>A meeting space not co-located with a hotel (normally a conve ntion center) but
where there are hotels within a short walk.</t> where there are hotels within a short walk.</t>
<t>The advantages of this configuration are:</t> <t>The advantages of this configuration are:</t>
<ul> <ul spacing="normal">
<li>It makes many more cities available as potential venues.</li > <li>It makes many more cities available as potential venues.</li >
<li>It provides more options for local hotels.</li> <li>It provides more options for local hotels.</li>
<li>Convention centers generally have a range of nearby hotels e <li>It enables the IASA to negotiate a lower room rate than othe
nabling the IASA to rwise
negotiate a lower room rate than otherwise.</li> as convention centers generally have a range of hotels nearby.</l
i>
</ul> </ul>
<t>The disadvantages are:</t> <t>The disadvantages are:</t>
<ul> <ul spacing="normal">
<li>Convention centers are much more difficult to negotiate with <li>Convention centers are much more difficult to negotiate with
and less and are less
flexible.</li> flexible.</li>
<li>The IASA has to pay for the meeting space.</li> <li>The IASA has to pay for the meeting space.</li>
<li>For those IETF participants (and staff) that normally stay i n the IETF hotel, the sense of community is diminished.</li> <li>For those IETF participants (and staff) that normally stay i n the IETF hotel, the sense of community is diminished.</li>
<li>Choice of a main hotel and negotiation of the network for th at hotel are more <li>The choice of a main hotel and negotiation for the network a t that hotel are more
complicated.</li> complicated.</li>
</ul> </ul>
</li> </li>
</ol> </ol>
<t>While a "one-roof" venue is preferred, there are a limited number o <t>To meet in cities that do not have suitable "One-Roof" venues, the
f hotels (and IASA needs to
therefore cities) with large enough meeting space and sufficient roo work with convention centers. If this approach is not taken, then ma
ms to accommodate ny cities and
us. To meet in cities that do not have suitable "one-roof" venues, t potentially some countries will be practically excluded as meeting v
he IASA needs to enues.</t>
work with convention centers. If it did not take this approach then <t>It should also be noted that a "One-Roof" venue shifts the costs of
many cities and the meeting
potentially some countries would be practically excluded as meeting onto participants whereas a convention center shifts the costs onto
venues.</t> the
<t>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 shif
ted more towards the
IASA.</t> IASA.</t>
<t>Despite "one-roof" being expressed as a preference in <xref target= "RFC8718"/> there <t>Despite "One Roof" being expressed as a preference in <xref target= "RFC8718"/>, there
are some in the community who consider it as the only way to meet th e requirement for are some in the community who consider it as the only way to meet th e requirement for
"close proximity".</t> "close proximity".</t>
</section> </section>
<section> <section>
<name>Resolution: Clarification of Interpretation</name> <name>Resolution: Clarification of Interpretation</name>
<t>To address this concern, the IASA should interpret the "close proxi
mity" requirement of <t>To address this concern, the IASA should interpret the "close
<xref target="RFC8718"/> as follows: </t> proximity" requirement of <xref target="RFC8718"/> as follows: </t>
<t indent="1">Where the meeting space is a convention center or other <t indent="5">Where the meeting space is a convention center or
facility without a another facility without a directly attached hotel, the "close
directly attached hotel, the “close proximity” requirement for the I proximity" requirement for the IETF Hotels should mean
ETF Hotels should be that the time it takes to walk from the IETF Hotels to the meeting
taken to mean that the time it takes to walk from the IETF Hotels to space should be no longer than ten minutes, and it should be a safe wa
the meeting space lk including
should be no longer than ten minutes, and a safe walk, including ear early in the morning and late at night.</t>
ly in the morning <t>It should be noted that <xref target="RFC8718" sectionFormat="of"
and late at night.</t> section="3.2.2"/> already uses a walkability test of 5-10 minutes
<t>It should be noted that <xref target="RFC8718" sectionFormat="of" s for a similar purpose.</t>
ection="3.2.2"/>
already uses a walkability test of 5-10 minutes for a similar purpos
e.</t>
</section> </section>
</section> </section>
<section> <section>
<name>Number of rooms reserved</name> <name>Number of Rooms Reserved</name>
<section> <section>
<name>Current Policy</name> <name>Current Policy</name>
<t><xref target="RFC8718"/> includes the following requirement as an i mportant <t><xref target="RFC8718"/> includes the following requirement as an i mportant
criterion:</t> criterion:</t>
<blockquote><ul> <blockquote><ul>
<li>The guest rooms at the IETF Hotels are sufficient in number to house one-third or <li>The guest rooms at the IETF Hotels are sufficient in number to house one-third or
more of the projected meeting attendees.</li> more of the projected meeting attendees.</li>
</ul></blockquote> </ul></blockquote>
</section> </section>
<section> <section>
<name>Discussion</name> <name>Discussion</name>
<t>COVID-driven cancellations and lockdowns have badly affected the ho spitality industry <t>COVID-driven cancellations and lockdowns have badly affected the ho spitality industry
overall. Hotels and convention centers are now much more cautious ab out the terms of overall. Hotels and convention centers are now much more cautious ab out the terms of
their bookings and much less willing to invest to secure a booking, as they aim to their bookings and much less willing to invest in securing a booking , as they aim to
protect themselves from any similar sudden loss of income. For examp le, many hotels are protect themselves from any similar sudden loss of income. For examp le, many hotels are
now requiring payment in full in advance for guest room blocks from now requiring conference organizers to provide full payment in advan
conference ce for guest room blocks.</t>
organizers.</t>
<t>Where the IASA can get a large room block, it is finding that hotel s are less willing <t>Where the IASA can get a large room block, it is finding that hotel s are less willing
to provide good discounts and so room pricing is not always on a par to provide good discounts, so room pricing is not always on a par wi
with other nearby th other nearby
hotels, with a smaller number of available rooms.</t> hotels that have a smaller number of available rooms.</t>
<t>Then there is the impact of the now ubiquitous offering of short-te rm apartment rental <t>Then there is the impact of the now ubiquitous offering of short-te rm apartment rental
sites. These sites are significant competitors to hotels for travele r accommodation both sites. These sites are significant competitors to hotels for travele r accommodation both
in price and availability.</t> in price and availability.</t>
<t>The net result is that the IASA is reserving more hotel rooms than are being used, <t>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 financi ally guarantee which exposes it to unnecessary risk as they are required to financi ally guarantee
certain levels of occupancy, and leads to wasted effort.</t> certain levels of occupancy, and this leads to wasted effort.</t>
</section> </section>
<section> <section>
<name>Resolution: Update to RFC 8718</name> <name>Resolution: Update to RFC 8718</name>
<t>To address this, this document updates <xref target="RFC8718" secti
on="3.2.4"/> to <t>To address this issue, this document updates <xref target="RFC8718"
replace the requirement for the total room block in the IETF Hotels section="3.2.4"/> by
from “one-third of replacing the total room block requirement for IETF Hotels from
the projected attendees” to a more flexible “sufficient rooms to mee "one-third or more of projected meeting attendees" to a more flexible
t the expected "sufficient rooms to meet the expected demand".</t>
demand”.</t>
</section> </section>
</section> </section>
<section> <section>
<name>Overflow Hotels</name> <name>Overflow Hotels</name>
<section> <section>
<name>Current Policy</name> <name>Current Policy</name>
<t><xref target="RFC8718" section="1"/> defines "Overflow Hotels" as f ollows:</t> <t><xref target="RFC8718" section="1"/> defines "Overflow Hotels" as f ollows:</t>
<blockquote><t>One or more hotels, usually in close proximity to the F acility, where the <blockquote><t>One or more hotels, usually in close proximity to the F acility, where the
IASA has negotiated a group room rate for the purposes of the meet ing. IETF has negotiated a group room rate for the purposes of the meet ing.
</t></blockquote> </t></blockquote>
<t>The concept is further expanded in <xref target="RFC8718" section=" 3.2.4" <t>The concept is further expanded in <xref target="RFC8718" section=" 3.2.4"
sectionFormat="comma"/>:</t> sectionFormat="of"/>:</t>
<blockquote><t>Overflow Hotels can be placed under contract, within co nvenient travel time <blockquote><t>Overflow Hotels can be placed under contract, within co nvenient travel time
to and from the Facility and at a variety of guest room rates</t>< /blockquote> to and from the Facility and at a variety of guest room rates</t>< /blockquote>
</section> </section>
<section> <section>
<name>Discussion</name> <name>Discussion</name>
<t>The IASA has historically contracted with overflow hotels including those at other <t>The IASA has historically contracted with Overflow Hotels including those at other
price points from the IETF Hotels. They were very underutilized by a ttendees, reflecting price points from the IETF Hotels. They were very underutilized by a ttendees, reflecting
the general under-utilization of IETF contracted room blocks, exposi the general underutilization of IETF contracted room blocks and expo
ng the IASA to sing the IASA to
financial risk and with little benefit to participants. As a result, financial risk with little benefit to participants. As a result, the
the use of overflow use of Overflow
hotels has reduced and they are rarely contracted. However, due to t Hotels has reduced, and they are rarely contracted. However, due to
he way they are the way they are
incorporated into <xref target="RFC8718"/> there are still many who incorporated into <xref target="RFC8718"/>, there are still many who
believe these are, believe these are,
or should be, a normal feature of IETF meetings.</t> or should be, a normal feature of IETF meetings.</t>
</section> </section>
<section> <section>
<name>Resolution: Clarification of Interpretation</name> <name>Resolution: Clarification of Interpretation</name>
<t>To address this, the IASA should interpret any reference to Overflo w Hotels as an <t>To address this issue, the IASA should interpret any reference to O verflow Hotels as an
entirely optional feature that the IASA can choose to provide at its own discretion.</t> entirely optional feature that the IASA can choose to provide at its own discretion.</t>
</section> </section>
</section> </section>
<section> <section>
<name>Ad-hoc Space Including the Lounge and Terminal Room</name> <name>Ad Hoc Space including the Lounge and Terminal Room</name>
<section> <section>
<name>Current Policy</name> <name>Current Policy</name>
<t><xref target="RFC8718" section="3.2.2"/> and <xref target="RFC8718"
sectionFormat="bare" section="3.2.4"/> include the following requi <t>Sections <xref target="RFC8718" section="3.2.2" sectionFormat="bare
rements as important "/> and <xref target="RFC8718"
sectionFormat="bare" section="3.2.4"/> of <xref target="RFC8718"/>
include the following requirements as important
criteria:</t> criteria:</t>
<blockquote><ul> <blockquote><ul>
<li>There are sufficient places (e.g., a mix of hallways, bars, me eting rooms, and <li>There are sufficient places (e.g., a mix of hallways, bars, me eting rooms, and
restaurants) for people to hold ad hoc conversations and group d iscussions in the restaurants) for people to hold ad hoc conversations and group d iscussions in the
combination of spaces offered by the facilities, hotels, and bar s/restaurants in the combination of spaces offered by the facilities, hotels, and bar s/restaurants in the
surrounding area, within walking distance (5-10 minutes). </li> surrounding area, within walking distance (5-10 minutes). </li>
<li>At least one IETF Hotel or the Facility has a space for use as a lounge, conducive <li>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. 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 wit h laptops. These can There are tables with seating, convenient for small meetings wit h laptops. These can
be at an open bar or casual restaurant. Preferably the lounge ar ea is centrally be at an open bar or casual restaurant. Preferably the lounge ar ea is centrally
located, permitting easy access to participants. </li> located, permitting easy access to participants. </li>
</ul></blockquote> </ul></blockquote>
<t>While not a formal requirement, a Terminal Room, described as a ded <t>While not a formal requirement, a terminal room (described as a ded
icated room with icated room with
extended opening hours beyond the normal hours of IETF meetings, Eth extended opening hours beyond the normal hours of IETF meetings), Et
ernet connectivity, hernet connectivity,
a printer and a staffed helpdesk, has been a long-standing feature o a printer, and a staffed help desk have been long-standing features
f IETF meetings.</t> of IETF meetings.</t>
</section> </section>
<section> <section>
<name>Discussion</name> <name>Discussion</name>
<t>Both the Lounge and the Terminal Room are regularly but lightly use <t>Both the lounge and the terminal room are used regularly but lightl
d, far below y, i.e., far below
capacity. The reason for this is explained in the feedback to post-m capacity. The reason for this is explained in the feedback to post-m
eeting surveys: most eeting surveys: Most
participants want an immediately accessible ad-hoc meeting space, wh participants want an immediately accessible ad hoc meeting space, wh
ich is best provided ich is best provided
by plenty of hallway seating. The IASA has responded to this feedbac k by adopting a new by plenty of hallway seating. The IASA has responded to this feedbac k by adopting a new
practice of hiring in hallway seating whenever that provided by the venue is practice of bringing in additional in-hallway seating whenever that provided by the venue is
insufficient.</t> insufficient.</t>
<t>Dedicated rooms, such as the Lounge or Terminal Room, or external f acilities "within <t>Dedicated rooms, such as the lounge or terminal room, or external f acilities "within
walking distance (5-10 minutes)" are unsuitable for the majority of participant needs, walking distance (5-10 minutes)" are unsuitable for the majority of participant needs,
though there remains a need for quiet places to work between session s.</t> though there remains a need for quiet places to work between session s.</t>
</section> </section>
<section> <section>
<name>Resolution: Update to RFC 8718</name> <name>Resolution: Update to RFC 8718</name>
<t>To address this, <xref target="RFC8718"> is updated as follows:</xr <t>To address this issue, <xref target="RFC8718"/> is updated as follo
ef></t> ws:</t>
<ol> <ol type="1" spacing="normal">
<li><t>Section <xref target="RFC8718" section="3.2.2" sectionFormat= <li><t><xref target="RFC8718" section="3.2.2"
"bare"/> is updated sectionFormat="of"/> is updated so that the entry on ad hoc
so that the bullet on ad-hoc meeting space now reads:</t> meeting space (first bullet) now reads:</t>
<t indent="1">There are sufficient, easily accessible places withi <blockquote>There are sufficient, easily accessible places within
n the Facility for the Facility for
people to hold ad hoc conversations and group discussions.</t></ people to hold ad hoc conversations and group discussions.</bloc
li> kquote></li>
<li><t>Section <xref target="RFC8718" section="3.2.4" sectionFormat= <li><t><xref target="RFC8718" section="3.2.4"
"bare"/> is updated sectionFormat="of"/> is updated so that the entry on the lounge (six
so that the bullet on the lounge now reads:</t> th bullet) now reads:</t>
<t indent="1">There are sufficient places within the Facility suit <blockquote>There are sufficient places within the Facility suitab
able for people to le for people to
work online on their own devices.</t></li> work online on their own devices.</blockquote></li>
</ol> </ol>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA"> <section anchor="IANA">
<!-- All drafts are required to have an IANA considerations section. See R FC 8126 for a guide.-->
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This memo includes no request to IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="Security"> <section anchor="Security">
<!-- All drafts are required to have a security considerations section. Se e RFC 3552 for a guide. -->
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document should not affect the security of the Internet.</t> <t>This document should not affect the security of the Internet.</t>
</section> </section>
<!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 718.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 718.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 719.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 719.xml"/>
</references> </references>
</references> </references>
<section anchor="Contributors" numbered="false"> <section anchor="Acknowledgements" numbered="false">
<name>Contributors</name> <name>Contributors</name>
<t>Thanks to all of the contributors: Laura Nugent, Stephanie McCammon, Al <t>Thanks to the following people for their contributions to this document
exa Morris, Greg : <contact fullname="Laura
Wood, Lars Eggert and Jason Livingood.</t> Nugent"/>, <contact fullname="Stephanie McCammon"/>, <contact
fullname="Alexa Morris"/>, <contact fullname="Greg Wood"/>, <contact
fullname="Lars Eggert"/>, and <contact fullname="Jason Livingood"/>.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 66 change blocks. 
199 lines changed or deleted 204 lines changed or added

This html diff was produced by rfcdiff 1.48.