Internet DRAFT - draft-daley-gendispatch-venue-requirements
draft-daley-gendispatch-venue-requirements
Internet Engineering Task Force J. Daley, Ed.
Internet-Draft S. Turner
Updates: 8718 (if approved) IETF Administration LLC
Intended status: Informational 10 March 2023
Expires: 11 September 2023
IETF Meeting Venue Requirements Review
draft-daley-gendispatch-venue-requirements-00
Abstract
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.
Editorial Note
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>.
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 11 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Daley & Turner Expires 11 September 2023 [Page 1]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Recommendations and Proposals . . . . . . . . . . 3
3. Issues, Analysis, Recommendations and Proposals . . . . . . . 3
3.1. The "IETF Hotels" / "One Roof" Model . . . . . . . . . . 3
3.1.1. Current Policy . . . . . . . . . . . . . . . . . . . 3
3.1.2. Current Practice . . . . . . . . . . . . . . . . . . 4
3.1.3. Developments . . . . . . . . . . . . . . . . . . . . 5
3.1.4. Practical Concerns . . . . . . . . . . . . . . . . . 7
3.1.5. Recommendations and Proposals . . . . . . . . . . . . 7
3.2. The Lounge, Terminal Room and Ad-hoc Space . . . . . . . 8
3.2.1. Current Policy . . . . . . . . . . . . . . . . . . . 8
3.2.2. Current Practice . . . . . . . . . . . . . . . . . . 9
3.2.3. Developments . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Practical Concerns . . . . . . . . . . . . . . . . . 9
3.2.5. Proposals . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Internet Filtering . . . . . . . . . . . . . . . . . . . 11
3.3.1. Current Policy . . . . . . . . . . . . . . . . . . . 11
3.3.2. Developments . . . . . . . . . . . . . . . . . . . . 12
3.3.3. Practical Concerns . . . . . . . . . . . . . . . . . 12
3.3.4. Recommendations . . . . . . . . . . . . . . . . . . . 12
3.4. New Venues vs Known Good Venues . . . . . . . . . . . . . 13
4. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
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.
Daley & Turner Expires 11 September 2023 [Page 2]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
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.
2. Summary of Recommendations and Proposals
1. We recommend replacing the "close proximity" requirement with a
"time to walk" requirement somewhere between 5-15 minutes.
2. We recommend replacing the "one-third" requirement for rooms in
the IETF Hotels with a "sufficient to meet projected demand"
requirement.
3. We propose to no longer provide a Terminal Room and direct people
to the Lounge instead.
4. We recommend that the community reopen the discussion on Internet
filtering at venues and provide us with better guidance by
considering four key questions.
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.
3. Issues, Analysis, Recommendations and Proposals
3.1. The "IETF Hotels" / "One Roof" Model
3.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.
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:
Daley & Turner Expires 11 September 2023 [Page 3]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
| * 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.
3.1.2. Current Practice
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:
1. It simplifies the negotiation and installation of the hotel
network. Very few hotels have any experience of a third party
installing a network and so the negotiation is often as much work
as the installation.
Daley & Turner Expires 11 September 2023 [Page 4]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
2. One large room block is more likely to result in a lower room
price and hotel commissions paid to the IETF.
3. For the core group of IETF participants (and staff) that normally
stay in the IETF hotel or close by, there is a strong sense of
community.
When this hotel is under the same roof as the facility then there are
further advantages:
4. 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).
5. It can be much cheaper than working with a separate convention
center.
6. Group discussions can more naturally move from the facility to
the hotel.
3.1.3. Developments
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.
Daley & Turner Expires 11 September 2023 [Page 5]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
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.
3.1.3.1. Hotel Internet Access
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:
* Access points installed inside elevators to provide a better
experience in the elevators
* Access points configured to rotate their channel at a frequency of
less than a minute.
* Captive portals that only allow for a small number of IPv6
connections because anything more must be a mistake.
* Networks with plenty of external bandwidth but such a low-powered
captive portal setup that effective bandwidth per user is below
usable.
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.
Daley & Turner Expires 11 September 2023 [Page 6]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
3.1.4. Practical Concerns
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.
3.1.5. Recommendations and Proposals
We make the following recommendations:
Daley & Turner Expires 11 September 2023 [Page 7]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
1. To replace the "close proximity" requirement for the IETF Hotels
with a "time to walk" requirement, that aims to limit the time it
takes to walk from the hotel(s) to the meeting space and to each
other. We make no proposal as to the length of time other than
to note it should not be any less than five minutes nor more than
fifteen minutes (see https://en.wikipedia.org/wiki/15-minute_city
for context and https://app.traveltime.com to generate a walking
time polygon for your city of choice) and that Section 3.2.2 of
[RFC8718] already uses a walkability test of 5-10 minutes for a
similar purpose.
2. 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". Short-
term apartment rental companies only operate in some countries,
so the number of rooms booked will need to vary depending on our
assessment of the availability of alternative forms of
accommodation. Note, this excludes the number of rooms reserved
in the overflow hotels, which are not guaranteed and which do not
benefit from the IETF network.
We propose:
3. For the NOC to monitor the usage of the IETF network in the IETF
Hotels in order to understand it better. This would provide the
data for a review of the hotel network and what, if any, changes
are needed. We leave the details of what monitoring takes place
to the NOC and community to decide.
3.2. The Lounge, Terminal Room and Ad-hoc Space
3.2.1. Current Policy
[RFC8718] includes 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.
Daley & Turner Expires 11 September 2023 [Page 8]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
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.
3.2.2. Current Practice
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.
3.2.3. Developments
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.
3.2.4. Practical Concerns
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:
Daley & Turner Expires 11 September 2023 [Page 9]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
* "the rather limited number of chairs and lounge tables in front of
the meeting rooms"
* "less space for social interaction and the terminal room/code
lounge was far away from the meetings"
* "Terminal room: this should have been more readily accessible and
not located on floor -3 in a room with no window"
* "Hard to find breakout rooms and have the side conversations that
are so critical to IETF sessions"
Increasing ad-hoc meeting space presents us with some challenges:
1. Most venues include "pre-function" space but we tend to use that
for our registration desk and related desks (e.g. IANA, RPC).
2. There are many venues that could not support such space and if it
became a strong requirement that would significantly reduce our
choice.
3. Of those venues that do have such space, our experience is that
they often do not have the furniture and so we would need to rent
it. This is not an insurmountable problem but does mean
increasing our costs at a time we want to be reducing them.
4. Fire restrictions often prevent us from using space that might
appear to the observer to be otherwise free for us to use in this
way.
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.
3.2.5. Proposals
As the Terminal Room is not a requirement from [RFC8718] , it is
within scope for the LLC to propose the following changes:
1. To no longer have a Terminal Room. Anyone that wishes to use the
Terminal Room will be directed to the Code Lounge instead.
2. Drop the in-person helpdesk. Technical support will still be
available via the support email and we will introduce a new Zulip
channel for live support. On those rare occasions when in-person
support is required, then an engineer will appear.
Daley & Turner Expires 11 September 2023 [Page 10]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
3. Drop the requirement for an IETF provided printer. If people
need to print then they will need to identify suitable facilities
themselves. The registration desk may be able to provide
pointers, but we are no longer guaranteeing that print services
will be available.
Relatedly, the meeting planning team will be taking the following
actions:
1. Where the opportunity arises for us to provide greater ad-hoc
space through rental of furniture, then we will consider this.
2. We will experiment with the location of the Lounge and see what
feedback we get from that.
3. We will improve the messaging and signage around the lounge,
encouraging people to use it as ad-hoc meeting space.
3.3. Internet Filtering
3.3.1. Current Policy
[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
Daley & Turner Expires 11 September 2023 [Page 11]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
| 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.
3.3.2. Developments
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.
3.3.3. Practical Concerns
In practice the requirements have proven difficult to interpret
because they leave too many questions unanswered:
1. Is any filtering acceptable? 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 and it is not clear if we
could meet in a country with such restrictions.
2. If we can be reasonably sure that people can legally, technically
and practically circumvent filtering through the use of VPNs (or
VPNs + encrypted DNS, or MASQUE, or other) then does it matter
what else is going on, on the local network?
3. We have historically met in venues where unfiltered access was
provided to the meeting space and IETF Hotels but not to overflow
hotels. Is that acceptable going forward?
4. There is much text in [RFC8718] about the importance of people
being able to work in bars, cafes etc yet this is not considered
when filtering is discussed. Should it be?
3.3.4. Recommendations
We recommend the community reopen the discussion on filtering and
provide us better guidance on the key questions listed above.
Daley & Turner Expires 11 September 2023 [Page 12]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
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.
3.4. New Venues vs Known Good Venues
The factors that make a venue a good venue are numerous:
* Those in common to all participants:
- Size and layout of the meeting space
- Facilities in the area around the meeting space
- The weather
* Those with a more geographically varied impact on participants:
- Overall cost of travel and accommodation
- Visa availability and requirements
* Those primarily impacting staff and volunteers:
- Service provision from the meeting space
- Technical facilities and service provision
- Local sponsors / hosts
- Desirability for meeting hosts
Revisiting known good venues has a number of advantages and
disadvantages:
* Advantages:
- We know the space and the services work for us
- Participants gain familiarity with the space and can use it
more efficiently
- The staff costs associated with researching, booking and
managing the meeting are lower than negotiating from scratch
* Disadvantages:
Daley & Turner Expires 11 September 2023 [Page 13]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
- The venue becomes much less competitive on price (as has
happened with Prague)
- It restricts the number of local communities that we interact
with
- Is it less appealing to Global Hosts to sponsor a meeting in
the same venue.
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.
4. Next Steps
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.
5. IANA Considerations
This memo includes no request to IANA.
Daley & Turner Expires 11 September 2023 [Page 14]
Internet-Draft IETF Meeting Venue Requirements Review March 2023
6. Security Considerations
This document should not affect the security of the Internet.
7. References
7.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
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 11 September 2023 [Page 15]
