Internet-Draft | IETF Meeting Venue Requirements Review | March 2023 |
Daley & Turner | Expires 11 September 2023 | [Page] |
This document sets out a series of recommendations and proposals to the IETF Community from the IETF Administration LLC following a review of the IETF meeting venue requirements.¶
Discussion of this draft takes place on the gendispatch mailing list, which has its home page at <https://www.ietf.org/mailman/listinfo/gendispatch>.¶
The source code and an issues list for this draft can be found at <https://github.com/JayDaley/draft-daley-gendispatch-venue-requirements>.¶
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 11 September 2023.¶
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.¶
IETF meeting venues are researched, negotiated, booked and managed in accordance with RFC 8718 “IETF Plenary Meeting Venue Selection Process” [RFC8718]. While this RFC was 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 IETF Administration LLC has reviewed the venue selection in light of these developments, primarily informed by its close engagement with the Secretariat staff who work on venue selection, and has identified a number of problems and possible solutions, some of which it recommends to the community and some of which it proposes.¶
Taken together, the changes strip back much of the detail around venue requirements and allow for a greater variety of venue models and thereby support a greater range of possible venues.¶
We finish with a discussion on the merits of returning to the same venues that are known to work well vs maximizing the number of different venues, and therefore countries, that we visit.¶
[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.¶
These are distinct from the “overflow hotels”, which are arranged but not reserved, can be some distance from the meeting space, and do not receive the IETF network.¶
[RFC8718] provides the following mandatory criteria:¶
- It MUST be possible to provision Internet Access to the Facility and IETF Hotels¶
It also provides the following important criteria (only listing those directly relevant):¶
- The IETF Hotels directly provide, or else permit and facilitate, the delivery of a high performance, robust, unfiltered, and unmodified Internet service for the public areas and guest rooms; this service is to be included in the cost of the room.¶
- The IETF Hotels are within close proximity to each other and the Facility.¶
- The guest rooms at the IETF Hotels are sufficient in number to house one-third or more of projected meeting attendees.¶
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.¶
What happens in practice is that we book a single IETF Hotel (aka a main hotel), with enough rooms reserved for one third of projected attendees. Most of the time this is under the same roof as the meeting space because hotels often tie their meeting space to the size of the guest bedroom block. In other words, in order to be able to book sufficient meeting space in a “one roof” venue, we need to reserve a large room block.¶
The IETF network is made available in the IETF Hotel, covering the guest bedrooms and the main common areas. Even when we are not under one roof, we nearly always aim for a single hotel to fulfill the requirements of the IETF Hotels. The IETF has only installed the IETF network into more than one hotel on a very small number of occasions.¶
There are a number of advantages to having a single IETF Hotel:¶
When this hotel is under the same roof as the facility then there are further advantages:¶
As noted earlier, there have been a number of developments that have affected the efficacy of our current model.¶
The most recent of these developments was the COVID driven cancellations and lockdowns that 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 in order 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.¶
The current high global inflation and uncertain economic outlook adds to the risk averse stance of hotel and convention centers.¶
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 on price and availability.¶
Taking a more long-term perspective, the nature of Internet access for travelers has changed significantly over the years and the trajectory is much the same. In most of the countries that we visit, local SIM cards with a sufficient data limit are readily available at a reasonable price. The VPN industry has exploded with many commercial offerings and many corporations providing a VPN for staff. In addition, IETF-developed protocols like DoH and MASQUE have made protecting DNS and web traffic quite easy.¶
When the NOC adds the IETF network to a hotel, the general approach is to bring in new external connectivity via one of a number of mechanisms and then work with the existing hotel infrastructure to configure a new SSID on the hotel APs that avoids as much of the hotel captive portal equipment as possible.¶
Hotel WiFi has improved significantly, both in bandwidth and quality, and there appear to be fewer hotels doing silly things such as trying to intercept SSL connections. However, the experience of the NOC in working with hotel networks, a broader experience than just working with the IETF hotels, is that there remain a large number of problems with hotel WiFi. For example, the following issues have been encountered by the NOC:¶
In conclusion, while hotel WiFi has improved significantly, it remains entirely unpredictable as to how it will hold up when used by a large number of engineers with unusual traffic profiles.¶
This model limits our choice of venue as it tends to exclude “one roof” venues that have sufficient meeting space but insufficient rooms, and to exclude those venues where there is a convention center that is suitable for us, with a choice of nearby hotels that in total have sufficient rooms to accommodate us, but none of the hotels individually is big enough to meet our requirements for a single IETF Hotel. In both cases, it is not the policy that excludes them but the practicalities of implementing the policy.¶
The large room block strategy is losing its appeal due a number of factors.¶
As noted above, hotels are increasingly wary of reserving large blocks of rooms as they used to do, for a number of reasons.¶
Where we can get a large room block, we are finding that hotels are less willing to provide us good discounts, which means the room pricing is not always on a par with other nearby hotels, with a smaller number of available rooms.¶
We are reserving more hotel rooms than are being used and the anecdotal evidence is that this is down to more people making individual arrangements using short-term rental sites. This is exposing us to unnecessary risk as we are required to financially guarantee certain levels of occupancy, and is leading to wasted effort. It also means that we are not receiving the anticipated commission income from hotels, which would anyway be lower than pre-COVID due to the financial caution of hotels.¶
Finally, despite the effort that goes into providing the network in the IETF Hotel, it should be noted that we understand very little about how it is used.¶
We make the following recommendations:¶
We propose:¶
[RFC8718] includes the following requirements as important criteria:¶
The only requirements for a Terminal Room are given in the The Tao of the IETF (https://www.ietf.org/about/participate/tao/), which describes it as a dedicated room with extended opening hours beyond the normal hours of IETF meetings, Ethernet connectivity, a printer and a staffed helpdesk.¶
The Lounge is a feature of every IETF meeting. It is regularly but lightly used, far below capacity.¶
The Terminal Room is a feature of every IETF meeting. It is regularly but lightly used, far below capacity. It meets most of the requirements from the Tao (https://www.ietf.org/about/participate/tao/), but the decision was taken some years ago to move the helpdesk to the reception area.¶
Almost everybody at an IETF meeting now has a laptop, tablet, or smartphone (if not all of these) and WiFi in those devices is ubiquitous. In the other places where people regularly work outside of the office (airport lounges, cafes, hotels, etc) cabled ethernet connections are a rarity.¶
The need to print such things as travel documents, event tickets, and the like, has dropped to virtually zero as all of these things have been replaced with apps on mobile devices.¶
Those people that use the Terminal Room rarely use any of the facilities provided; they are largely after a quiet place to work between working group meetings they plan to attend.¶
The demand for in-person technical support is low and almost all of the visits are for things that could be supported remotely via a support ticket. The IETF NOC team already responds to support tickets throughout the meeting and we specifically monitor the perceptions of our support response in our post-meeting surveys.¶
In practice, negotiating the requirements of the Terminal Room with the venues takes disproportionately long and its usage is too low to justify this work.¶
In our last two post-meeting surveys, comments have been made about the lack of ad-hoc space in and around the facility, and the positioning of the Terminal Room and Code Lounge:¶
Increasing ad-hoc meeting space presents us with some challenges:¶
Given the under-utilization of the Lounge it might make sense to reconfigure the meeting space to make the Lounge easier to access so that it can more easily be used as ad-hoc meeting space, but where we have tried that it has meant having the meeting rooms further apart and participants have complained about that.¶
As the Terminal Room is not a requirement from [RFC8718] , it is within scope for the LLC to propose the following changes:¶
Relatedly, the meeting planning team will be taking the following actions:¶
[RFC8718] has a lot to say about filtering:¶
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 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.¶
And¶
It MUST be possible to provision Internet Access to the Facility and IETF Hotels [...] Provisions include, but are not limited to, native and unmodified IPv4 and IPv6 connectivity, and global reachability; there may be no additional limitation that would materially impact their Internet use.¶
The legal frameworks around filtering have grown more sophisticated and filtering technology has similarly developed.¶
Additionally, as noted above, VPN technology and other privacy-enhancing technologies have also developed rapidly.¶
Historically, the IETF has met in countries with significant Internet filtering and there is an expectation from the local communities in those countries that we revisit them.¶
In practice the requirements have proven difficult to interpret because they leave too many questions unanswered:¶
We recommend the community reopen the discussion on filtering and provide us better guidance on the key questions listed above.¶
It may be that these questions need to be answered on a case-by-case basis when we ask for community input on specific venues, but with better guidance we could provide better data for the community to consider and minimize wasted effort on venue research.¶
The factors that make a venue a good venue are numerous:¶
Revisiting known good venues has a number of advantages and disadvantages:¶
Visiting new venues also has a number of advantages and disadvantages, related to those above. However, these are not all equally important. In particular, there are two key issues - the availability and requirements for visas, which has a direct effect on the breadth of global participation, and the appeal to meeting hosts, which has a fundamental impact on the financial viability of IETF meetings.¶
[RFC8719] is silent on the question of these advantages and disadvantages and so the IETF LLC aims to find a balance between the two approaches. The community may wish us to take a different approach, or provide further guidance on how to balance these various factors.¶
Assuming that some changes are worth moving forward with, there are some options for how to progress those.¶
The first option is a replacement for [RFC8718] with the same level of detail as the existing document. That provides for clarity and certainty around the requirements and while it will inevitably need replacing as those requirements change, it is unlikely that this will be an obstacle to change.¶
The second option is a stripped back replacement for [RFC8718] that sets the key principles for the venue and leaves the details to the IETF LLC to interpret. This has the benefit of avoiding the importance of some meeting features being lost in the detail, as arguably has happened with the importance of ad-hoc meeting areas. However, this might not ensure sufficient community engagement and oversight of the interpretations of the principles.¶
This memo includes no request to IANA.¶
This document should not affect the security of the Internet.¶
Thanks to all of the contributors: Laura Nugent, Stephanie McCammon, Alexa Morris, Greg Wood, Lars Eggert and Jason Livingood¶