-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-daley-gendispatch-venue-requirements.xml
391 lines (373 loc) · 21.6 KB
/
draft-daley-gendispatch-venue-requirements.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="bcp"
docName="draft-daley-gendispatch-venue-requirements-02" ipr="trust200902"
updates="8718 8719" submissionType="IETF" xml:lang="en" version="3" consensus="true">
<front>
<title>IETF Meeting Venue Requirements Review</title>
<seriesInfo name="Internet-Draft" value="draft-daley-gendispatch-venue-requirements-02"/>
<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>
</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>
</postal>
<email>sean@sn3rd.com</email>
</address>
</author>
<date year="2024"/>
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>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 exploratory meeting process, thereby updating RFC 8719 "High-Level
Guidance for the Meeting Policy of the IETF".</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>
</front>
<middle>
<section>
<name>Introduction</name>
<t>IETF meeting venues are researched, negotiated, booked and managed in accordance with <xref
target="RFC8718"/> “IETF Plenary Meeting Venue Selection Process” and <xref
target="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.</t>
<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 <xref target="RFC8718"/> and <xref target="RFC8719"/>:</name>
<ol>
<li>Updates the Meeting (Rotation) Policy of <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 the room block requirement of <xref target="RFC8718"/> from “one-third of the
projected attendees” to a more flexible “sufficient rooms to meet the expected
demand”.</li>
<li>Clarifies that the IASA should interpret any reference to Overflow Hotels in <xref
target="RFC8718"/> as an entirely optional feature that the IASA can choose to provide
at its own discretion.</li>
<li>Updates various parts of <xref target="RFC8718"/> that specify ad-hoc space to better
match the community 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>[...] 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>
<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 target="RFC8719" section="4"/> 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.</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 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 for an 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 and deferring to the IESG if there is any concern that the likely number or
makeup of onsite participants is insufficient for a viable IETF meeting.</t>
<t>The IASA MUST ensure that the frequency of exploratory meetings is such that it does not
redefine the concept of 'exploratory' and it MUST ensure that the distribution of
exploratory meetings does not disproportionately impact meetings in the 1-1-1 regions.</t>
</section>
</section>
<section>
<name>Hotels and Facility</name>
<section>
<name>The “One Roof” Preference</name>
<section>
<name>Current Policy</name>
<t><xref target="RFC8718"/> defines “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>
<li><t>A "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>
<li>With a large enough room block, the meeting space is generally free.</li>
<li>For a core group of 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 centers with separate contacts for AV, F&B, and
space).</li>
<li>It can be much cheaper for the IASA than working with a separate convention
center.</li>
<li>Group discussions can 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>
<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 can be
more expensive for IETF participants.</li>
</ul>
</li>
<li><t>A meeting space not co-located with a hotel, normally a convention center, but
where there are hotels within a short walk.</t>
<t>The advantages of this configuration are:</t>
<ul>
<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 the IASA to
negotiate a lower room rate than otherwise.</li>
</ul>
<t>The disadvantages are:</t>
<ul>
<li>Convention centers are much more difficult to negotiate with and less
flexible.</li>
<li>The IASA has to pay for the meeting space.</li>
<li>The sense of community for a core group of IETF participants is diminished.</li>
<li>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 then many cities and
potentially some countries would 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 a convention center, where the costs are shifted more towards the
IASA.</t>
<t>Despite "one-roof" being expressed as a preference in <xref target="RFC8718"/> there
are some in the community who consider it as the only way to meet 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 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.</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>
<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 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.</t>
<t>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.</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 leads to wasted effort.</t>
</section>
<section>
<name>Resolution: Update to RFC 8718</name>
<t>To address this, this document updates <xref target="RFC8718" section="3.2.4"/> 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”.</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 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>
<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 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 <xref 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, 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 Space Including the Lounge and Terminal Room</name>
<section>
<name>Current Policy</name>
<t><xref target="RFC8718" section="3.2.2"/> and <xref target="RFC8718"
sectionFormat="bare" section="3.2.4"/> include the following 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 as a dedicated room with
extended opening hours beyond the normal hours of IETF meetings, Ethernet connectivity,
a printer and a staffed helpdesk, has been a long-standing feature of IETF meetings.</t>
</section>
<section>
<name>Discussion</name>
<t>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.</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>
<name>Resolution: Update to RFC 8718</name>
<t>To address this, <xref target="RFC8718"> is updated as follows:</xref></t>
<ol>
<li><t>Section <xref target="RFC8718" section="3.2.2" sectionFormat="bare"/> is updated
so that the bullet on ad-hoc meeting space now reads:</t>
<t indent="1">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 target="RFC8718" section="3.2.4" sectionFormat="bare"/> is updated
so that the bullet on the lounge now reads:</t>
<t indent="1">There are sufficient places within the Facility suitable for people to
work online on their own devices.</t></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 no request to IANA.</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 to all of the contributors: Laura Nugent, Stephanie McCammon, Alexa Morris, Greg
Wood, Lars Eggert and Jason Livingood.</t>
</section>
</back>
</rfc>