<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?> encoding="UTF-8"?>

<!-- pre-edited by ST 10/01/24 -->
<!-- formatted by ST 11/08/24 -->
<!-- reference review by TH 11/18/24 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<!--[rfced] This document will be assigned a new BCP number. Please
let us know if this is not correct (i.e., it should be part of
an existing BCP).

See the complete list of BCPs here:
https://www.rfc-editor.org/bcps
-->

<!-- [rfced] FYI: The "sortRefs" and "symRefs" elements
were absent in the submitted XML file, so we have
added them accordingly.
-->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="bcp" docName="draft-daley-gendispatch-venue-requirements-03" ipr="trust200902"
  updates="8718 number="9712" updates="8718, 8719" obsoletes="" tocInclude="true" submissionType="IETF" xml:lang="en" version="3" consensus="true"> consensus="true"  sortRefs="true" symRefs="true">

  <front>
    <title>IETF

<!--[rfced] The short title that spans the top of the PDF file was
absent. We were able to fit the full title, so we included it. If
any further updates are desired, please let us know.

Current (in PDF file):
   IETF Meeting Venue Requirements Review
-->

    <title abbrev="IETF Meeting Venue Requirements Review">IETF Meeting Venue Requirements Review</title>
    <seriesInfo name="Internet-Draft" value="draft-daley-gendispatch-venue-requirements-03"/> name="RFC" value="9712"/>
    <author fullname="Jay Daley" initials="J." surname="Daley" role="editor">
      <organization abbrev="IETF Administration LLC">IETF Administration LLC</organization>
      <address>
        <postal>
          <street>1000 N. West Street, Suite 1200</street>
          <city>Wilimington</city>
          <region>DE</region>
          <code>19801</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>jay@staff.ietf.org</email>
      </address>
    </author>

    <author fullname="Sean Turner" initials="S." surname="Turner">
      <organization abbrev="IETF Administration LLC">IETF Administration LLC</organization>
      <address>
        <postal>
          <street>1000 N. West Street, Suite 1200</street>
          <city>Wilimington</city>
          <region>DE</region>
          <code>19801</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>sean@sn3rd.com</email>
      </address>
    </author>

    <date year="2024"/>

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup> year="2024" month="December"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<abstract>
      <t>Following

<!--[rfced] Is this document "proposing" or "providing" updates to
RFCs 8718 and 8719? May we update the Abstract's lead-in sentence
from "this document proposes updates" to "this document was
developed to update" as shown below for clarity?

Original:
   Following a review of the IETF meeting venue requirements, this
   document proposes updates to RFC 8718 “IETF "IETF Plenary Meeting Venue
   Selection Process”, Process", 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".</t> IETF".

Perhaps:
   Following a review of the IETF meeting venue requirements, this
   document was developed to update "IETF Plenary Meeting Venue
   Selection Process" (RFC 8718), clarify how the IETF Administration
   Support Activity (IASA) should interpret some elements of RFC 8718,
   and specify a replacement exploratory meeting process, thereby
   updating "High-Level Guidance for the Meeting Policy of the IETF"
   (RFC 8719).
-->

      <t>Following a review of the IETF meeting venue requirements, this document proposes updates
        to "IETF Plenary Meeting Venue Selection 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 "High-Level
        Guidance for the Meeting Policy of the IETF" (RFC 8719).</t>
    </abstract>
 <!--   <note title="Editorial Note">
      <t>Discussion of this draft takes place on the mtgvenue mailing list, which has its home page
        at <eref target="https://www.ietf.org/mailman/listinfo/mtgvenue" brackets="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-requirements"
          brackets="angle"/>. </t>
    </note>
    </note>-->
  </front>

  <middle>

    <section>
      <name>Introduction</name>
      <t>IETF meeting venues are researched, negotiated, booked booked, and managed in accordance with <xref
          target="RFC8718"/> “IETF
      "IETF Plenary Meeting Venue Selection Process” and Process" <xref
          target="RFC8719"/> target="RFC8718"/> and "High-Level
      Guidance for the Meeting Policy of the IETF". IETF" <xref target="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.</t>

<!--[rfced] Is "informed" the intended word here or would
"communicated" be clearer?

Original:
   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.

Perhaps:
   The IASA has reviewed the venue selection in light of these
   developments, which were primarily communicated 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.
-->

      <t>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.</t>
    </section>

    <section>
      <name>Summary of Changes to RFCs 8718 and 8719</name>

<!--[rfced] The text in Section 2 works off of the section title. To
avoid this and the use of a colon in the section title, may
we insert a lead-in sentence as shown below?

Original:
   2. Summary of changes to <xref target="RFC8718"/> [RFC8718] and <xref target="RFC8719"/>:</name> [RFC8719]:

     1.  Updates the Meeting (Rotation) Policy of [RFC8719] with
         a new process for the selection of exploratory meetings...

Perhaps:
   2. Summary of Changes to RFCs 8718 and 8719

     This document makes the following changes to [RFC8718] and [RFC8719]:

     1.  Updates the Meeting (Rotation) Policy specified in [RFC8719] with
         a new process for the selection of exploratory meetings...
-->

      <ol>
        <li>Updates the Meeting (Rotation) Policy of specified in  <xref target="RFC8719"/> with a new process for
          the selection of exploratory meetings.</li>
        <li>Clarifies the interpretation of "close proximity" as used in <xref target="RFC8718"
          />.</li>
        <li>Updates
<!-- [rfced] FYI: We updated the quoted text from RFC 8718 to exactly
match (i.e., we updated "one-third of the projected attendees" to
"one-third or more of projected meeting attendees") as shown
below.

Original:
   3.  Updates the room block requirement of [RFC8718] from "one-third of the
       projected attendees" to a more flexible "sufficient rooms to meet the
       expected demand".

Current:
   3.  Updates the room block requirement specified in [RFC8718] from
       "one-third or more of projected meeting attendees" to a more
       flexible "sufficient rooms to meet the expected demand".
-->
<li>Updates the room block requirement specified in <xref target="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”.</li>
          demand".</li>
        <li>Clarifies that the IASA should interpret any reference to Overflow Hotels "Overflow Hotels" in <xref
            target="RFC8718"/> as an entirely optional feature that the IASA can choose to provide
        at its own discretion.</li>

        <li>Updates the ad hoc space specified in various parts of <xref target="RFC8718"/> that specify ad-hoc space
	to better match the community requirements requirements, as expressed in post-meeting surveys.</li>
      </ol>
    </section>

    <section>
      <name>The Meeting (Rotation) Policy and Exploratory Meetings</name>
      <section>
        <name>Current Policy</name>
        <t>The current meeting rotation policy is set as the "1-1-1-*" policy in <xref
            target="RFC8719"/>:</t>
        <blockquote><t>[...]
<!-- [rfced] FYI: We removed repeated text that appeared to be a typo (the
text was the same as what appears in the next <blockquote> after "and"):

Original:
   [...] 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
            "*").</t></blockquote> "*").

Current:
   [...] the meeting policy (let's call this the "1-1-1" policy) is that meetings
   should rotate between North America, Europe, and Asia.
-->
        <blockquote><t>[...] the meeting policy (let's call this the "1-1-1" policy) is that
            meetings should rotate between North America, Europe, and Asia.</t></blockquote>
        <t>and</t>
        <blockquote><t>[...] 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 "*").</t></blockquote>
        <t><xref
        <t>Furthermore, <xref target="RFC8719" section="4"/> 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.</t>
      </section>
      <section>
        <name>Discussion</name>
        <t>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.</t>
      </section>
      <section>
        <name>Resolution: Replacement of the process Process for an exploratory meeting</name> Exploratory Meeting</name>
        <t>This document replaces <xref target="RFC8719" section="4"/> and sets the new process as
          follows:</t>
        <t>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 <xref target="RFC8718"/> of 'why we meet’ meet' might not be met.</t>
        <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
          exploratory meetings does not disproportionately impact meetings in the 1-1-1 regions.</t>
      </section>
    </section>

    <section>
      <name>Hotels and the Facility</name>
      <section>
        <name>The “One Roof” "One-Roof" Preference</name>
        <section>
          <name>Current Policy</name>
          <t><xref target="RFC8718"/> defines “IETF Hotels” "IETF Hotels" as:</t>
          <blockquote>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.</blockquote>
          <t>It also provides the following important criteria (only listing those directly
            relevant):</t>
          <blockquote><ul>
              <li>The IETF Hotels are within close proximity to each other and the Facility.</li>
            </ul></blockquote>
          <t>Additionally, <xref target="RFC8718"/> contains this preference:</t>
          <blockquote><ul>
              <li>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.</li>
            </ul></blockquote>
        </section>
        <section>
          <name>Discussion</name>
          <t>What happens in practice is that the IASA books a venue that conforms to one of two
            separate configurations:</t>
          <ol>
          <ol type="1" spacing="normal">
            <li><t>A "one roof" "one-roof" venue of a hotel with the meeting space in the hotel or directly
                attached.</t>
              <t>The advantages of this configuration are:</t>
              <ul>
              <ul spacing="normal">
                <li>With a large enough room block, the meeting space is generally free.</li>
                <li>For those IETF participants (and staff) that normally stay in 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
                  instead of several (convention (e.g., convention centers with have separate contacts for Audio/Visual services, Food/Beverages, Food/Beverage services, and meeting space).</li>
                <li>It can be much cheaper for the IASA than working with a separate convention
                  center.</li>
                <li>Group discussions can move more naturally move from the facility to the hotel.</li>
                <li>It is easier to negotiate network changes to the hotel as part of an overall
                  network package.</li>
                <li>Someone can walk from their room to the meeting space in a few minutes, staying
                  indoors the whole time. </li>
              </ul>
              <t>The disadvantages are:</t>
              <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
                  meeting space and sufficient rooms to accommodate us.</li>
                <li>The room rates at conference hotels are often on the high side and it side, which can be
                  more expensive for IETF participants.</li>
              </ul>
            </li>
            <li><t>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.</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 provides more options for local hotels.</li>
                <li>Convention centers generally have a range of nearby hotels enabling
                <li>It enables the IASA to negotiate a lower room rate than otherwise.</li> otherwise
		as convention centers generally have a range of hotels nearby.</li>
              </ul>
              <t>The disadvantages are:</t>
              <ul>
              <ul spacing="normal">
                <li>Convention centers are much more difficult to negotiate with and are less
                  flexible.</li>
                <li>The IASA has to pay for the meeting space.</li>
                <li>For those IETF participants (and staff) that normally stay in the IETF hotel, the sense of community is diminished.</li>
                <li>Choice
                <li>The choice of a main hotel and negotiation of the network for that hotel are more
                  complicated.</li>
              </ul>
            </li>
          </ol>
          <t>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.</t>
          <t>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.</t>
          <t>Despite "one-roof" "one roof" being expressed as a preference in <xref target="RFC8718"/> target="RFC8718"/>, there
            are some in the community who consider it as the only way to meet the requirement for
            "close proximity".</t>
        </section>
        <section>
          <name>Resolution: Clarification of Interpretation</name>

          <t>To address this concern, the IASA should interpret the "close
          proximity" requirement of <xref target="RFC8718"/> as follows: </t>
          <t indent="1">Where indent="5">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.</t>
          <t>It should be noted that <xref target="RFC8718" sectionFormat="of"
          section="3.2.2"/> already uses a walkability test of 5-10 minutes
          for a similar purpose.</t>
        </section>
      </section>
      <section>
        <name>Number of rooms reserved</name> Rooms Reserved</name>
        <section>
          <name>Current Policy</name>
          <t><xref target="RFC8718"/> includes the following requirement as an important
            criterion:</t>
          <blockquote><ul>
              <li>The guest rooms at the IETF Hotels are sufficient in number to house one-third or
                more of the projected meeting attendees.</li>
            </ul></blockquote>
        </section>
        <section>
          <name>Discussion</name>
          <t>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.</t> blocks.</t>
          <t>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.</t>
          <t>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.</t>
          <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 financially guarantee
            certain levels of occupancy, and this leads to wasted effort.</t>
        </section>
        <section>
          <name>Resolution: Update to RFC 8718</name>
          <t>To

<!-- [rfced] FYI: RFC 8718 states "one-third or more of projected
meeting attendees" rather than "one-third of the projected
attendees", so we have updated the text accordingly.

Original:
   To address this, this document updates <xref target="RFC8718" section="3.2.4"/> Section 3.2.4 of [RFC8718] to
   replace the requirement for the total room block in the IETF Hotels
   from “one-third "one-third of the projected attendees” attendees" to a more flexible “sufficient
   "sufficient rooms to meet the expected
            demand”.</t> demand".

Current:
   To address this issue, this document updates Section 3.2.4 of [RFC8718]
   by replacing the total room block requirement for the IETF Hotels from
   "one-third or more of projected attendees" to a more flexible
   "sufficient rooms to meet the expected demand".
 -->

          <t>To address this issue, this document updates <xref target="RFC8718" section="3.2.4"/> by
          replacing the total room block requirement for IETF Hotels from
	  "one-third or more of projected meeting attendees" to a more flexible
	  "sufficient rooms to meet the expected demand".</t>
        </section>
      </section>
      <section>
        <name>Overflow Hotels</name>
        <section>
          <name>Current Policy</name>
          <t><xref target="RFC8718" section="1"/> defines "Overflow Hotels" as follows:</t>

          <blockquote><t>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.
            </t></blockquote>
          <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 convenient travel time
              to and from the Facility and at a variety of guest room rates</t></blockquote>
        </section>
        <section>
          <name>Discussion</name>
          <t>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 <xref target="RFC8718"/> target="RFC8718"/>, there are still many who believe these are,
            or should be, a normal feature of IETF meetings.</t>
        </section>
        <section>
          <name>Resolution: Clarification of Interpretation</name>
          <t>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.</t>
        </section>
      </section>
      <section>
        <name>Ad-hoc
        <name>Ad Hoc Space Including including the Lounge and Terminal Room</name>
        <section>
          <name>Current Policy</name>
          <t><xref

          <t>Sections <xref target="RFC8718" section="3.2.2"/> section="3.2.2" sectionFormat="bare"/> and <xref target="RFC8718"
              sectionFormat="bare" section="3.2.4"/> of <xref target="RFC8718"/> include the following requirements as important
            criteria:</t>
          <blockquote><ul>
              <li>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). </li>
              <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.
                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. </li>
            </ul></blockquote>
          <t>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.</t>
        </section>
        <section>
          <name>Discussion</name>
          <t>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.

<!--[rfced] Can "hiring" be replaced with "renting" or "providing" for
clarity as shown below?

Original:
   The IASA has responded to this feedback by adopting
   a new practice of hiring in hallway seating whenever
   that provided by the venue is insufficient.

Perhaps:
   The IASA has responded to this feedback by adopting
   a new practice of renting in-hallway seating whenever
   that provided by the venue is insufficient.
-->

	    The IASA has responded to this feedback by adopting a new
            practice of hiring in-hallway seating whenever that provided by the venue is
            insufficient.</t>
          <t>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.</t>
        </section>
        <section>
<!-- [rfced] FYI: We updated the following text to make the sections
and RFC being referenced clearer:

Original:
   To address this, is updated as follows: [RFC8718]

   1.  Section 3.2.2 is updated so that the bullet on ad-hoc meeting
       space now reads:

        There are sufficient, easily accessible places within the
        Facility for people to hold ad hoc conversations and group
        discussions.

   2.  Section 3.2.4 is updated so that the bullet on the lounge now
       reads:

        There are sufficient places within the Facility suitable for
        people to work online on their own devices.

Current:
   To address this, [RFC8718] is updated as follows:

   1.  Section 3.2.2 of [RFC8718] is updated so that the entry on
       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 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.
-->

          <name>Resolution: Update to RFC 8718</name>
          <t>To address this, this issue, <xref target="RFC8718"> target="RFC8718"/> is updated as follows:</xref></t>
          <ol>
            <li><t>Section <xref follows:</t>
          <ol type="1" spacing="normal">
            <li><t><xref target="RFC8718" section="3.2.2" sectionFormat="bare"/>
            sectionFormat="of"/> is updated so that the bullet entry on ad-hoc ad hoc
            meeting space (first bullet) now reads:</t>
              <t indent="1">There
              <blockquote>There are sufficient, easily accessible places within the Facility for
                people to hold ad hoc conversations and group discussions.</t></li>
            <li><t>Section <xref discussions.</blockquote></li>
            <li><t><xref target="RFC8718" section="3.2.4" sectionFormat="bare"/>
            sectionFormat="of"/> is updated so that the bullet entry on the lounge (sixth bullet) now reads:</t>
              <t indent="1">There
              <blockquote>There are sufficient places within the Facility suitable for people to
                work online on their own devices.</t></li> devices.</blockquote></li>
          </ol>
        </section>
      </section>
    </section>

    <section anchor="IANA">
      <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>IANA Considerations</name>
      <t>This memo includes document has no request to IANA.</t> IANA actions.</t>
    </section>

    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
      <t>This document should not affect the security of the Internet.</t>
    </section>

    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->

  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8718.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8719.xml"/>
      </references>
    </references>

    <section anchor="Contributors" numbered="false">
      <name>Contributors</name>
      <t>Thanks

<!--[rfced] Are these contributors considered coauthors for their
contributions, or should the Contributors section perhaps be
retitled "Acknowledgements" and the text be updated as shown
below? Please let us know your preference.

Original:
   Contributors

      Thanks to all of the contributors: Laura Nugent, Stephanie McCammon,
      Alexa Morris, Greg Wood, Lars Eggert Eggert and Jason Livingood.</t> Livingood.

Perhaps:
   Acknowledgements

       Thanks to the following people for their contributions to
       this document: Laura Nugent, Stephanie McCammon, Alexa Morris,
       Greg Wood, Lars Eggert Eggert, and Jason Livingood.
-->

    <section anchor="Contributors" numbered="false">
      <name>Contributors</name>
      <t>Thanks to all of the contributors: <contact fullname="Laura
      Nugent"/>, <contact fullname="Stephanie McCammon"/>, <contact
      fullname="Alexa Morris"/>, <contact fullname="Greg Wood"/>, <contact
      fullname="Lars Eggert"/>, and <contact fullname="Jason Livingood"/>.</t>
    </section>

<!-- [rfced] Terminology

a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.

 Lounge vs. lounge
   (Note: lowercase in RFC 8718)

 Meeting (Rotation) Policy vs. meeting rotation policy
   (Note: appears as "meeting policy" in RFC 8719. Perhaps use
   "meeting (rotation) policy" or "meeting rotation policy"
   for consistency in Sections 2 and 3.1.)

 One Roof vs. one roof
   (Note: uppercase in RFC 8718.)

 Overflow Hotels vs. overflow hotels
   (Note: uppercase in RFC 8718.)

 Terminal Room
   (Note: lowercase in RFC 8718 and other RFCs.)

b) Should one instance of "facility" perhaps be "Facility" in Section 4.1.2?

Original:
   *  Group discussions can more naturally move from the facility to
      the hotel.

Perhaps:
   *  Group discussions can move more naturally from the facility to
      the hotel.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

  </back>
</rfc>