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

Internet Engineering Task Force                            J. Daley, Ed.
Internet-Draft                                                 S. Turner
Obsoletes: 8719 (if approved)                    IETF Administration LLC
Updates: 8718 (if approved)                              12 October 2023
Intended status: Best Current Practice                                  
Expires: 14 April 2024

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

Abstract

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

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

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 14 April 2024.

Daley & Turner            Expires 14 April 2024                 [Page 1]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Summary of changes to RFC8718 and RFC8719:  . . . . . . . . .   3
   3.  The Meeting (Rotation) Policy . . . . . . . . . . . . . . . .   3
     3.1.  Current Policy  . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Discussion  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Resolution: Replacement of the IETF Meeting Policy  . . .   4
   4.  Hotels and Facility . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  The “One Roof” Preference . . . . . . . . . . . . . . . .   5
       4.1.1.  Current Policy  . . . . . . . . . . . . . . . . . . .   5
       4.1.2.  Discussion  . . . . . . . . . . . . . . . . . . . . .   5
       4.1.3.  Resolution: Clarification of Interpretation . . . . .   7
     4.2.  Number of rooms reserved  . . . . . . . . . . . . . . . .   7
       4.2.1.  Current Policy  . . . . . . . . . . . . . . . . . . .   7
       4.2.2.  Discussion  . . . . . . . . . . . . . . . . . . . . .   8
       4.2.3.  Resolution: Update to RFC 8718  . . . . . . . . . . .   8
     4.3.  Overflow Hotels . . . . . . . . . . . . . . . . . . . . .   8
       4.3.1.  Current Policy  . . . . . . . . . . . . . . . . . . .   8
       4.3.2.  Discussion  . . . . . . . . . . . . . . . . . . . . .   9
       4.3.3.  Resolution: Clarification of Interpretation . . . . .   9
     4.4.  Ad-hoc Space Including the Lounge and Terminal Room . . .   9
       4.4.1.  Current Policy  . . . . . . . . . . . . . . . . . . .   9
       4.4.2.  Discussion  . . . . . . . . . . . . . . . . . . . . .  10
       4.4.3.  Resolution: Update to RFC 8718  . . . . . . . . . . .  10
   5.  Unfiltered Internet Access  . . . . . . . . . . . . . . . . .  10
     5.1.  Current Policy  . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Discussion  . . . . . . . . . . . . . . . . . . . . . . .  11
     5.3.  Resolution: Update to RFC 8178  . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  12

Daley & Turner            Expires 14 April 2024                 [Page 2]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   IETF meeting venues are researched, negotiated, booked and managed in
   accordance with [RFC8718] “IETF Plenary Meeting Venue Selection
   Process” and [RFC8719] "High-Level Guidance for the Meeting Policy of
   the IETF".  While these RFCs were published in 2020, the substantive
   work was completed in 2018 and since then there have been a number of
   developments that have affected the efficacy of our current model for
   IETF meetings.

   The IASA has reviewed the venue selection in light of these
   developments, primarily informed by the staff who work on venue
   selection, and has identified a number of issues to be addressed by a
   combination of updates to those RFCs and clarifications of
   interpretation.

2.  Summary of changes to [RFC8718] and [RFC8719]:

   1.  Replaces [RFC8719] with a new Meeting (Rotation) Policy as set
       out in this document.

   2.  Clarifies the interpretation of "close proximity" as used in
       [RFC8718].

   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”.

   4.  Clarifies that the IASA should interpret any reference to
       Overflow Hotels in [RFC8718] as an entirely optional feature that
       the IASA can choose to provide at its own discretion.

   5.  Updates various parts of [RFC8718] that specify ad-hoc space to
       better match the community requirements as expressed in post-
       meeting surveys.

   6.  Clarifies the interpretation of 'unfiltered' regarding Internet
       access to cover the current environment.

3.  The Meeting (Rotation) Policy

3.1.  Current Policy

   The current meeting rotation policy is set as the "1-1-1-*" policy in
   [RFC8719]:

Daley & Turner            Expires 14 April 2024                 [Page 3]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

   |  [...] the meeting policy (let's call this the "1-1-1" policy) is
   |  that meetings should rotate between North America, Europe, and
   |  Asia. the 1-1-1-* meeting policy is a slightly modified version of
   |  the aforementioned 1-1-1 meeting policy that allows for additional
   |  flexibility in the form of an exploratory meeting (denoted with an
   |  "*").

   and

   |  [...] the 1-1-1-* meeting policy is a slightly modified version of
   |  the aforementioned 1-1-1 meeting policy that allows for additional
   |  flexibility in the form of an exploratory meeting (denoted with an
   |  "*").

   [RFC8719] further sets out the process for agreeing on an exploratory
   meeting, which includes the requirement for a participant to nominate
   the city, the community to discuss it and the IETF Chair to determine
   if there is consensus for the city to be considered suitable.

3.2.  Discussion

   The view of the community appears to have shifted since RFC 8719 was
   written, towards a less rigid policy for IETF meeting rotation, with
   the key goal of avoiding excessive geographic concentration, and with
   greater discretion being given to the IASA.  This is partly because,
   since 2020, the IASA has established two practices to ensure
   community input into the choice of meeting venues:

   1.  The IASA consults with the IESG when there is any concern that
       the likely number or makeup of onsite participants is not
       sufficient for a viable IETF meeting at a particular venue.

   2.  The IASA publishes a formal assessment of proposed venues
       (cities) as part of its process of seeking community feedback.

3.3.  Resolution: Replacement of the IETF Meeting Policy

   This document obsoletes [RFC8719] and sets the IETF Meeting Policy as
   follows:

   The IETF meets onsite three times a year.  The core regions for IETF
   meetings are North America, Europe and Asia, and the non-core regions
   are Africa, the Caribbean, Central America, the Middle East, Oceania
   and South America.  For the avoidance of doubt, North America
   includes the US, Canada and Mexico, and meetings cannot be held in
   Antarctica.  These meetings rotate geographically at the discretion
   of the IASA with the following restrictions:

Daley & Turner            Expires 14 April 2024                 [Page 4]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

   *  No two adjacent meetings in the same region.

   *  No more than one meeting per region in a calendar year.

   *  No more than one meeting in a non-core region in a calendar year.

   *  No more than one meeting per country in any two adjacent calendar
      years.

4.  Hotels and Facility

4.1.  The “One Roof” Preference

4.1.1.  Current Policy

   [RFC8718] defines “IETF Hotels” as:

   |  One or more hotels, in close proximity to the Facility, where the
   |  IETF guest room block allocations are negotiated and where network
   |  services managed by the IASA (e.g., the "IETF" SSID) are in use.

   It also provides the following important criteria (only listing those
   directly relevant):

   |  *  The IETF Hotels are within close proximity to each other and
   |     the Facility.

   Additionally, [RFC8718] contains this preference:

   |  *  We have something of a preference for an IETF meeting to be
   |     under "One Roof"; that is, qualified meeting space and guest
   |     rooms are available in the same facility.

4.1.2.  Discussion

   What happens in practice is that the IASA books a venue that conforms
   to one of two separate configurations:

   1.  A "one roof" venue of a hotel with the meeting space in the hotel
       or directly attached.

       The advantages of this configuration are:

       *  With a large enough room block, the meeting space is generally
          free.

Daley & Turner            Expires 14 April 2024                 [Page 5]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

       *  For a core group of IETF participants (and staff) that
          normally stay in the IETF hotel, there is a strong sense of
          community.

       *  It is usually easier and more flexible to work with a single
          point of contact instead of several (convention centers with
          separate contacts for AV, F&B, and space).

       *  It can be much cheaper for the IASA than working with a
          separate convention center.

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

       *  It is easier to negotiate network changes to the hotel as part
          of an overall network package.

       *  Someone can walk from their room to the meeting space in a few
          minutes, staying indoors the whole time.

       The disadvantages are:

       *  There are a limited number of hotels (and therefore cities)
          with large enough meeting space and sufficient rooms to
          accommodate us.

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

   2.  A meeting space not co-located with a hotel, normally a
       convention center, but where there are hotels within a short
       walk.

       The advantages of this configuration are:

       *  It makes many more cities available as potential venues.

       *  It provides more options for local hotels.

       *  Convention centers generally have a range of nearby hotels
          enabling the IASA to negotiate a lower room rate than
          otherwise.

       The disadvantages are:

       *  Convention centers are much more difficult to negotiate with
          and less flexible.

Daley & Turner            Expires 14 April 2024                 [Page 6]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

       *  The IASA has to pay for the meeting space.

       *  The sense of community for a core group of IETF participants
          is diminished.

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

   While a "one-roof" venue is preferred, there are a limited number of
   hotels (and therefore cities) with large enough meeting space and
   sufficient rooms to accommodate us.  To meet in cities that do not
   have suitable "one-roof" venues, the IASA needs to work with
   convention centers.  If it did not take this approach then many
   cities and potentially some countries would be practically excluded
   as meeting venues.

   It should also be noted that a "one-roof" venue shifts the costs of
   the meeting more onto participants than a convention center, where
   the costs are shifted more towards the IASA.

   Despite "one-roof" being expressed as a preference in [RFC8718] there
   are some in the community who consider it as the only way to meet the
   requirement for "close proximity".

4.1.3.  Resolution: Clarification of Interpretation

   To address this concern, the IASA should interpret the "close
   proximity" requirement of [RFC8718] as follows:

    Where the meeting space is a convention center or other facility
    without a directly attached hotel, the “close proximity” requirement
    for the IETF Hotels should be taken to mean that the time it takes
    to walk from the IETF Hotels to the meeting space should be no
    longer than ten minutes, and a safe walk, including early in the
    morning and late at night.

   It should be noted that Section 3.2.2 of [RFC8718] already uses a
   walkability test of 5-10 minutes for a similar purpose.

4.2.  Number of rooms reserved

4.2.1.  Current Policy

   [RFC8718] includes the following requirement as an important
   criterion:

   |  *  The guest rooms at the IETF Hotels are sufficient in number to
   |     house one-third or more of the projected meeting attendees.

Daley & Turner            Expires 14 April 2024                 [Page 7]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

4.2.2.  Discussion

   COVID-driven cancellations and lockdowns have badly affected the
   hospitality industry overall.  Hotels and convention centers are now
   much more cautious about the terms of their bookings and much less
   willing to invest to secure a booking, as they aim to protect
   themselves from any similar sudden loss of income.  For example, many
   hotels are now requiring payment in full in advance for guest room
   blocks from conference organizers.

   Where the IASA can get a large room block, it is finding that hotels
   are less willing to provide good discounts and so room pricing is not
   always on a par with other nearby hotels, with a smaller number of
   available rooms.

   Then there is the impact of the now ubiquitous offering of short-term
   apartment rental sites.  These sites are significant competitors to
   hotels for traveler accommodation both in price and availability.

   The net result is that the IASA is reserving more hotel rooms than
   are being used, which exposes it to unnecessary risk as they are
   required to financially guarantee certain levels of occupancy, and
   leads to wasted effort.

4.2.3.  Resolution: Update to RFC 8718

   To address this, this document updates Section 3.2.4 of [RFC8718] to
   replace the requirement for the total room block in the IETF Hotels
   from “one-third of the projected attendees” to a more flexible
   “sufficient rooms to meet the expected demand”.

4.3.  Overflow Hotels

4.3.1.  Current Policy

   Section 1 of [RFC8718] defines "Overflow Hotels" as follows:

   |  One or more hotels, usually in close proximity to the Facility,
   |  where the IASA has negotiated a group room rate for the purposes
   |  of the meeting.

   The concept is further expanded in [RFC8718], Section 3.2.4:

   |  Overflow Hotels can be placed under contract, within convenient
   |  travel time to and from the Facility and at a variety of guest
   |  room rates

Daley & Turner            Expires 14 April 2024                 [Page 8]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

4.3.2.  Discussion

   The IASA has historically contracted with overflow hotels including
   those at other price points from the IETF Hotels.  They were very
   underutilized by attendees, reflecting the general under-utilization
   of IETF contracted room blocks, exposing the IASA to financial risk
   and with little benefit to participants.  As a result, the use of
   overflow hotels has reduced and they are rarely contracted.  However,
   due to the way they are incorporated into [RFC8718] there are still
   many who believe these are, or should be, a normal feature of IETF
   meetings.

4.3.3.  Resolution: Clarification of Interpretation

   To address this, the IASA should interpret any reference to Overflow
   Hotels as an entirely optional feature that the IASA can choose to
   provide at its own discretion.

4.4.  Ad-hoc Space Including the Lounge and Terminal Room

4.4.1.  Current Policy

   Section 3.2.2 of [RFC8718] and 3.2.4 include the following
   requirements as important criteria:

   |  *  There are sufficient places (e.g., a mix of hallways, bars,
   |     meeting rooms, and restaurants) for people to hold ad hoc
   |     conversations and group discussions in the combination of
   |     spaces offered by the facilities, hotels, and bars/restaurants
   |     in the surrounding area, within walking distance (5-10
   |     minutes).
   |  
   |  *  At least one IETF Hotel or the Facility has a space for use as
   |     a lounge, conducive to planned and ad hoc meetings and
   |     chatting, as well as a space for working online.  There are
   |     tables with seating, convenient for small meetings with
   |     laptops.  These can be at an open bar or casual restaurant.
   |     Preferably the lounge area is centrally located, permitting
   |     easy access to participants.

   While not a formal requirement, a Terminal Room has been a long-
   standing feature of IETF meetings.  It is described in the The Tao of
   the IETF (https://www.ietf.org/about/participate/tao/) as a dedicated
   room with extended opening hours beyond the normal hours of IETF
   meetings, Ethernet connectivity, a printer and a staffed helpdesk.

Daley & Turner            Expires 14 April 2024                 [Page 9]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

4.4.2.  Discussion

   Both the Lounge and the Terminal Room are regularly but lightly used,
   far below capacity.  The reason for this is explained in the feedback
   to post-meeting surveys: most participants want an immediately
   accessible ad-hoc meeting space, which is best provided by plenty of
   hallway seating.  The IASA has responded to this feedback by adopting
   a new practice of hiring in hallway seating whenever that provided by
   the venue is insufficient.

   Dedicated rooms, such as the Lounge or Terminal Room, or external
   facilities "within walking distance (5-10 minutes)" are unsuitable
   for the majority of participant needs, though there remains a need
   for quiet places to work between sessions.

4.4.3.  Resolution: Update to RFC 8718

   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.

5.  Unfiltered Internet Access

5.1.  Current Policy

   [RFC8718] provides the following mandatory criteria:

   |  *  It MUST be possible to provision Internet Access to the
   |     Facility and IETF Hotels

   This is further defined as "unfiltered" as follows:

   |  As an organization, we write specifications for the Internet, and
   |  we use it heavily.  Meeting attendees need unfiltered access to
   |  the general Internet and their corporate networks.  "Unfiltered
   |  access", in this case, means that all forms of communication are
   |  allowed.  This includes, but is not limited to, access to

Daley & Turner            Expires 14 April 2024                [Page 10]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

   |  corporate networks via encrypted VPNs from the meeting Facility
   |  and Hotels, including Overflow Hotels.  We also need open network
   |  access available at high enough data rates, at the meeting
   |  Facility, to support our work, which includes support of remote
   |  participation.  Beyond this, we are the first users of our own
   |  technology.  Any filtering may cause a problem with that
   |  technology development.  In some cases, local laws may require
   |  some filtering.  We seek to avoid such locales without reducing
   |  the pool of cities to an unacceptable level by stating a number of
   |  criteria below, one mandatory and others important, to allow for
   |  the case where local laws may require filtering in some
   |  circumstances.

5.2.  Discussion

   There is a wide spectrum of activities that may be considered
   "filtering", and not all of those are likely to be unacceptable to
   IETF participants.  For example, some countries operate filters that
   are minimally invasive by redirecting and filtering traffic to a
   small number of high-risk sites and only for one specific illegal
   activity https://en.wikipedia.org/wiki/
   Internet_censorship_in_New_Zealand.  Discussions with the community
   indicate that a meeting in such a country would not be considered a
   breach of the meeting criterion above.

5.3.  Resolution: Update to RFC 8178

   To address this, Section 2.1 of [RFC8718] is updated to include the
   following as part of the core value relating to Internet Access:

    Neither the Facility network, the IETF Hotels network, nor any
    upstream providers may impose technical constraints that affect the
    ability of meeting attendees (whether remote or onsite) to
    participate in the meeting or development of Internet protocols.
    That means that some filtering (e.g. for DoS protection, or locally
    mandated blocking of access to known CSAM sites) may be acceptable,
    but that broad, non-transparent filtering (e.g. port blocking or
    extensive government censorship of VPNs, web sites or email
    providers) are not acceptable.  Where any filtering is unavoidable,
    or recommended by the IETF meeting NOC, the mechanisms used should
    be openly described as soon as is practical (e.g. before the meeting
    if local mandates are imposed, or during a meeting if in response to
    some attack/events).

6.  IANA Considerations

   This memo includes no request to IANA.

Daley & Turner            Expires 14 April 2024                [Page 11]
Internet-Draft   IETF Meeting Venue Requirements Review     October 2023

7.  Security Considerations

   This document should not affect the security of the Internet.

8.  References

8.1.  Normative References

   [RFC8718]  Lear, E., Ed., "IETF Plenary Meeting Venue Selection
              Process", BCP 226, RFC 8718, DOI 10.17487/RFC8718,
              February 2020, <https://www.rfc-editor.org/info/rfc8718>.

   [RFC8719]  Krishnan, S., "High-Level Guidance for the Meeting Policy
              of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719,
              February 2020, <https://www.rfc-editor.org/info/rfc8719>.

Contributors

   Thanks to all of the contributors: Laura Nugent, Stephanie McCammon,
   Alexa Morris, Greg Wood, Lars Eggert and Jason Livingood.  Special
   thanks to Stephen Farrell for the text updating relating to Internet
   filtering.

Authors' Addresses

   Jay Daley (editor)
   IETF Administration LLC
   1000 N. West Street, Suite 1200
   Wilimington, DE 19801
   United States of America
   Email: jay@staff.ietf.org

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

Daley & Turner            Expires 14 April 2024                [Page 12]