rfc8718xml2.original.xml   rfc8718.xml 
<?xml version='1.0' encoding='ascii'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC3935 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3935.xml">
<!ENTITY RFC6771 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6771.xml">
<!ENTITY I-D.ietf-mtgvenue-meeting-policy SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mtgvenue-
meeting-policy.xml">
]> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc comments="no" ?>
<?rfc inline="no" ?>
<?rfc editing="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="bcp" <rfc number="8718" category="bcp" ipr="trust200902" submissionType="IETF"
docName="draft-ietf-mtgvenue-iaoc-venue-selection-process-16" seriesNo="226" consensus="true" xml:lang="en" tocInclude="true"
ipr="trust200902" submissionType="IETF" updates="" xml:lang="en"> tocDepth="2" symRefs="true" sortRefs="true"
docName="draft-ietf-mtgvenue-iaoc-venue-selection-process-16"
xmlns:xi="http://www.w3.org/2001/XInclude" version="3">
<front> <front>
<title abbrev="Venue Selection">IETF Plenary Meeting Venue Selection <title abbrev="Venue Selection">IETF Plenary Meeting Venue Selection
Process</title> Process</title>
<seriesInfo name="RFC" value="8718" />
<seriesInfo name="BCP" value="226"/>
<author initials="E." surname="Lear" fullname="Eliot Lear" role="editor"> <author initials="E." surname="Lear" fullname="Eliot Lear" role="editor">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>Richtistrasse 7</street> <street>Richtistrasse 7</street>
<city>Wallisellen</city> <city>Wallisellen</city>
<code>CH-8304</code> <code>CH-8304</code>
<country>Switzerland</country> <country>Switzerland</country>
</postal> </postal>
<phone>+41 44 878 9200</phone> <phone>+41 44 878 9200</phone>
<email>lear@cisco.com</email> <email>lear@cisco.com</email>
</address> </address>
</author> </author>
<date /> <date month="January" year="2020" />
<area>General</area> <area>General</area>
<workgroup>mtgvenue</workgroup> <workgroup>Meeting Venue Working Group</workgroup>
<keyword>Meeting Venues</keyword>
<keyword>Meeting selection process</keyword>
<keyword>IASA</keyword>
<abstract> <abstract>
<t>The IASA has responsibility for arranging IETF plenary meeting Venue <t>
selection and operation. This memo specifies IETF community The IETF Administration LLC (IETF LLC) is responsible
requirements for meeting venues, including hotels and meeting for arranging the selection and operation of the IETF plenary meeting
room space. It directs the IASA to make available additional venue. This memo specifies IETF community
process documents that describe the current meeting requirements for meeting venues, including hotels and meeting
selection process.</t> space. It also directs the IETF LLC to make available additional
process documents that describe the current meeting
selection process.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" title="Introduction">
<t>The Internet Administrative Support Activity (IASA) has <!-- [rfced] Note that we changed instannces of "the LLC" to "the IETF LLC"
responsibility for arranging IETF plenary meeting venue for consistency with other documents in this cluster. Please let us know any
selection and operation. The purpose of this document is to objections.
guide the IASA in their selection of regions, cities, -->
facilities, and hotels. The IASA applies this guidance at <t>The IETF Administration LLC (IETF LLC) <xref target="RFC8711"/> is
responsible for arranging the selection and operation of the IETF
plenary meeting venue. The purpose of this document is to
guide the IETF LLC in their selection of regions, cities,
facilities, and hotels. The IETF LLC should apply this guidance at
different points in the process in an attempt to faithfully different points in the process in an attempt to faithfully
meet the requirements of the IETF community. We specify a set meet the requirements of the IETF community. We specify a set
of general criteria for venue selection and several requirements for of general criteria for venue selection and several requirements for
transparency and community consultation.</t> transparency and community consultation.</t>
<t>It remains the responsibility of the IASA to apply their best <t> It remains the responsibility of the IETF LLC to apply their best
judgment. The IASA accepts input and feedback both during the judgment. The IETF LLC accepts input and feedback during the
consultation process and later (for instance when there are changes in th consultation process and later (for instance, when there are
e changes in the situation at a chosen location). As
situation at a chosen location). Any appeals remain subject to always, the community is encouraged to provide direct feedback
the provisions of <xref target="RFC4071">BCP101</xref>. As to the IETF LLC Board about their performance as well as to the
always, the community is encouraged to provide direct feedback to the Nominations Committee (NOMCOM), the Internet Engineering Steering
Nominations Committee (NOMCOM), Internet Engineering Steering Group (IESG), and the ISOC Board of Trustees, from which the
Group (IESG), and IAB regarding the discharge of the IASA's IETF LLC Board is constructed.
performance. </t>
</t> <t>The following four terms describe the places for which the IETF contrac
<t>Four terms describe the places for which the IETF contracts ts
services:<list style="hanging"> services:</t>
<t hangText="Venue: "><vspace />This is an umbrella term for the <dl newline="true">
city, meeting resources and guest room resources. <dt>Venue:</dt><dd>An umbrella term for the
</t> city, meeting resources, and guest room resources.</dd>
<t hangText="Facility: "><vspace />The building that houses <dt>Facility:</dt><dd>The building that houses
meeting rooms and associated resources. It may also meeting rooms and associated resources. It may also
house an IETF Hotel. house an IETF Hotel.</dd>
</t> <dt>IETF Hotels</dt><dd>One or more hotels, in close
<t hangText="IETF Hotels: "><vspace />One or more hotels, in close
proximity to the Facility, where the IETF guest room block proximity to the Facility, where the IETF guest room block
allocations are allocations are
negotiated and where network services managed by the IASA negotiated and where network services managed by the IETF LLC
(e.g., the "IETF" SSID) are in use.</t> (e.g., the "IETF" SSID) are in use.</dd>
<t hangText="Overflow Hotels: "><vspace />One or more <dt>Overflow Hotels:</dt><dd>One or more
hotels, usually in close proximity to the Facility, hotels, usually in close proximity to the Facility,
where the IETF has negotiated a group rate for the purposes of where the IETF has negotiated a group room rate for the purposes of
the meeting. Of particular note is that Overflow Hotels the meeting. Of particular note is that Overflow Hotels
usually are not connected to the IETF network and do not are not usually connected to the IETF network and do not
use network services managed by the IASA.</t> use network services managed by the IETF LLC.</dd>
</list></t> </dl>
<t>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/><xref target="RFC8174"/> when, and
only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="objectives" title="Venue Selection Objectives"> <section anchor="objectives" title="Venue Selection Objectives">
<section anchor="core" title="Core Values"> <section anchor="core" title="Core Values">
<t>Some IETF values pervade the selection process. These often are <t>Some IETF values pervade the selection process. These are often
applicable to multiple requirements listed in this document. They are applicable to multiple requirements listed in this document. At a
not limited to the following, but at minimum include: <list minimum, they include the following:</t>
style="hanging"> <dl newline="true">
<t hangText="Why we meet?"><vspace />We meet to pursue the IETF's <dt>Why we meet:</dt>
mission <xref target="RFC3935" />, partly by advancing the <dd>We meet to pursue the IETF's
development of Internet-Drafts and RFCs. We also seek to mission <xref target="RFC3935" />. This is partly done by
advancing the development of Internet-Drafts and RFCs. We also seek
to
facilitate attendee participation in multiple topics and to enable facilitate attendee participation in multiple topics and to enable
cross-pollination of ideas and technologies.</t> cross-pollination of ideas and technologies.</dd>
<t hangText="Inclusiveness:"><vspace />We would like to facilitate <dt>Inclusiveness:</dt>
the onsite or remote participation of anyone who wants to be <dd><t>We would like to facilitate
the on-site or remote participation of anyone who wants to be
involved. Widespread participation contributes to the involved. Widespread participation contributes to the
diversity of perspectives represented in the diversity of perspectives represented in the
working sessions</t> working sessions.</t>
<t>Every country has limits on who it will permit within its <t>Every country has limits on who it will permit within its
borders. However the IETF seeks to: <list style="numbers"> borders. However, the IETF seeks to:</t>
<t>Minimize situations in which onerous entry regulations
<ol>
<li>Minimize situations in which onerous entry regulations
inhibit, discourage, or prevent participants from inhibit, discourage, or prevent participants from
attending meetings, or failing that attending meetings; failing that, meeting locations are to
to distribute meeting locations such that onerous entry be distributed such that onerous entry
regulations are not always experienced by the same regulations are not always experienced by the same
attendees; and</t> attendees; and</li>
<t>Avoid meeting in countries with laws that effectively exclude <li>Avoid meeting in countries with laws that effectively exclud
e
people on the basis of race, ethnicity, religion, gender, sexu al people on the basis of race, ethnicity, religion, gender, sexu al
orientation, national origin, citizenship, or gender orientation, national origin, citizenship, or gender
identity.</t> identity.</li>
</list></t> </ol>
</dd>
<t hangText="Where we meet:"><vspace />We meet in different <dt>Where we meet:</dt>
locations globally, in order to spread the difficulty and cost of <dd>We meet in different
global locations, in order to spread the difficulty and cost of
travel among active participants, balancing travel time and travel among active participants, balancing travel time and
expense across the regions in which participants are expense across participants based in various regions. Our
based. Our regional location policy is articulated in regional location policy is articulated in
<xref target="I-D.ietf-mtgvenue-meeting-policy" />. <xref target="RFC8719" />.</dd>
</t>
<t hangText="Internet Access:"><vspace />As an organization, we <dt>Internet Access:</dt>
<dd>As an organization, we
write specifications for the Internet, and we use it heavily. write specifications for the Internet, and we use it heavily.
Meeting attendees need unfiltered access to the general Internet Meeting attendees need unfiltered access to the general Internet
and their corporate networks. "Unfiltered access" in this and their corporate networks. "Unfiltered access", in this
case means that all forms of communication are allowed. case, means that all forms of communication are allowed.
This includes, but is not limited to, access to corporate networks This includes, but is not limited to, access to corporate networks
via encrypted VPNs from the meeting Facility and Hotels, including via encrypted VPNs from the meeting Facility and Hotels, including
Overflow Hotels. We also need open network access available at Overflow Hotels. We also need open network access available at
high enough data rates, at the meeting Facility, to support our high enough data rates, at the meeting Facility, to support our
work, including the support of remote work, which includes support of remote
participation. Beyond this, we are the first users of participation. Beyond this, we are the first users of
our own technology. Any filtering may cause a problem our own technology. Any filtering may cause a problem
with that technology development. In some cases, with that technology development. In some cases,
local laws may require some filtering. We seek to local laws may require some filtering. We seek to
avoid such locales without reducing the avoid such locales without reducing the
pool of cities to an unacceptable level by stating a pool of cities to an unacceptable level by stating a
number of criteria below, one mandatory and others number of criteria below, one mandatory and others
important, to allow for the case where local laws may important, to allow for the case where local laws may
require filtering in some circumstances.</t> require filtering in some circumstances.</dd>
<t hangText="Focus:"><vspace />We meet to have focused <dt>Focus:</dt>
<dd>We meet to have focused
technical discussions. These are not limited to technical discussions. These are not limited to
scheduled breakout sessions, although of course those scheduled breakout sessions, although of course those
are important. They also happen over meals or drinks, are important. They also happen over meals or drinks,
a specific type of non-session that we call a through a specific type of non-session that we call a
"Bar BOF", or in side meetings. Environments that are "Bar BOF", or in side meetings. Environments that are
noisy or distracting prevent that or reduce its noisy or distracting prevent or reduce the
effectiveness, and are therefore less desirable as a effectiveness of these sessions and are therefore less desirable a
meeting Facility.<xref target="RFC6771" /></t> s a
meeting Facility <xref target="RFC6771" />.</dd>
<t hangText="Economics:"><vspace />Meeting attendees participate as <dt>Economics:</dt>
<dd>Meeting attendees participate as
individuals. While many are underwritten by employers or sponsors, individuals. While many are underwritten by employers or sponsors,
many are self-funded. In order to reduce participation costs and many are self-funded. In order to reduce participation costs and
travel effort, we therefore seek locations that provide convenient travel effort, we therefore seek locations that provide convenient
budget alternatives for food and lodging, and which minimize budget alternatives for food and lodging, and that minimize
travel segments from major airports to the Venue. Within reason, travel segments from major airports to the Venue. Within reason,
budget should not be a barrier to accommodation.</t> one's budget should not be a barrier to accommodation.</dd>
<t hangText="Least Astonishment and Openness:"><vspace /> <dt>Least Astonishment and Openness:</dt>
Regular participants <dd>Regular participants
should not be surprised by meeting Venue selections, particularly should not be surprised by meeting Venue selections, particularly
when it comes to locales. To avoid surprise, the venue when it comes to locales. To avoid surprise, the venue
selection process, as with all other IETF processes, selection process, as with all other IETF processes,
should be as open as practicable. It should be possible should be as open as practicable. It should be possible
for the community to engage early to express its views for the community to engage in discussion early to express its vie ws
on prospective selections, so that the community and the on prospective selections, so that the community and the
IASA can exchange views as to appropriateness long IETF LLC can exchange views as to appropriateness long
before a venue contract is considered.</t> before a venue contract is considered.</dd>
</list></t> </dl>
</section> </section>
<section anchor="nonobjectives" title="Venue Selection Non-Objectives"> <section anchor="nonobjectives" title="Venue Selection Non-objectives">
<t>IETF meeting Venues are not selected or declined with the explicit <t>IETF meeting Venues are not selected or declined with the explicit
purposes of:<list style="hanging"> purposes of:</t>
<t hangText="Politics: "><vspace />Endorsing or condemning <dl newline="true">
<dt>Politics:</dt><dd>Endorsing or condemning
particular countries, political paradigms, laws, regulations, or particular countries, political paradigms, laws, regulations, or
policies.</t> policies.</dd>
<t hangText="Maximal attendance: "><vspace /> <dt>Maximal attendance:</dt><dd>While the IETF strives to be as incl
While the IETF strives to be as inclusive as possible usive as possible,
both online and in person, maximal both online and in person, maximal
meeting attendance in and of itself is not a goal. It meeting attendance in and of itself is not a goal. It
would defeat a key goal of meeting if would defeat a key goal of meeting if
active contributors with differing active contributors with differing
points of view did not have the opportunity to resolve their points of view did not have the opportunity to resolve their
disagreements, no matter how full the rooms. disagreements, no matter how full the rooms.</dd>
</t>
<t hangText="Tourism: "><vspace />Variety in site-seeing <dt>Tourism:</dt><dd>Variety in site-seeing
experiences.</t> experiences.</dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section anchor="criteria" title="Meeting Criteria"> <section anchor="criteria" title="Meeting Criteria">
<t>This section contains the criteria for IETF meetings. It is <t>This section contains the criteria for IETF meetings. It is
broken down into three subsections: mandatory criteria, broken down into three subsections: <xref target="mandatories">mandatory c
important criteria, and other considerations, each as explained riteria</xref>,
<xref target="importants">important criteria </xref>, and <xref target="ot
herconsiderations">other considerations</xref>, each as explained
below. below.
</t> </t>
<section anchor="mandatories" title="Mandatory Criteria"> <section anchor="mandatories" title="Mandatory Criteria">
<t>If criteria in this subsection cannot be met, a particular <t>If criteria in this subsection cannot be met, a particular
location is unacceptable for selection, and the IASA MUST NOT location is unacceptable for selection, and the IETF LLC <bcp14>MUST NOT<
enter into a contract. Should the IASA learn that a location no /bcp14>
longer can meet a mandatory requirement after having entered enter into a contract. Should the IETF LLC learn that a location
can no longer meet a mandatory requirement after having entered
into a contract, it will inform the community and address the into a contract, it will inform the community and address the
matter on a case by case basis.</t> matter on a case-by-case basis.</t>
<t><list style="symbols">
<t>The Facility MUST provide sufficient <ul spacing="normal">
space in an appropriate layout to accommodate the expected <li>The Facility <bcp14>MUST</bcp14> provide sufficient
number of participants, leadership, and support staff to space in an appropriate layout to accommodate the
attend that meeting.</t> number of participants, leadership, and support staff expected to
<t>The Facility and IETF Hotels MUST provide wheelchair access attend that meeting.</li>
<li>The Facility and IETF Hotels <bcp14>MUST</bcp14> provide wheelchair a
ccess
to accommodate the number of people who are anticipated to to accommodate the number of people who are anticipated to
require it.</t> require it.</li>
<t>It MUST be possible to provision <li>It <bcp14>MUST</bcp14> be possible to provision
Internet Access to the Facility and IETF Hotels that allows Internet Access to the Facility and IETF Hotels that allows
those attending in person to utilize the Internet for all their IETF, those attending in person to utilize the Internet for all their IETF,
business, and day to day needs; as well as sufficient business, and day-to-day needs; in addition, there must be sufficient
bandwidth and access for remote attendees. This includes, but is not bandwidth and access for remote attendees.
Provisions include, but are not
limited to, native and unmodified IPv4 and IPv6 connectivity, limited to, native and unmodified IPv4 and IPv6 connectivity,
global reachability, and no additional limitation that would and global reachability; there may be no additional limitation that woul
materially impact their Internet use. d
To ensure availability, materially impact their Internet use. To ensure availability,
it MUST be possible to provision redundant paths to the it <bcp14>MUST</bcp14> be possible to provision redundant paths to the
Internet.</t> Internet.</li>
</list> </ul>
</t>
</section> </section>
<section anchor="importants" title="Important Criteria"> <section anchor="importants" title="Important Criteria">
<t>The criteria in this subsection are not mandatory, <t>The criteria in this subsection are not mandatory,
but are still highly significant. It may be necessary to but they are still highly significant. It may be necessary to
trade one or more of these criteria off against others. trade-off one or more of these criteria against others.
A Venue that meets more of these criteria is on the A Venue that meets more of these criteria is, on the
whole preferable than another that meets fewer of whole, preferable to another that meets fewer of
these criteria. Requirements classed as Important can these criteria. Requirements classed as Important can
also be balanced across Venue selections for multiple also be balanced across Venue selections for multiple
meetings. When a particular requirement in this section meetings. When a particular requirement in this section
cannot be met, the IASA MUST notify the community at the cannot be met but the Venue is selected anyway, the IETF LLC <bcp1
4>MUST</bcp14> notify the community at the
time of the venue announcement. Furthermore, it may be time of the venue announcement. Furthermore, it may be
appropriate for the IASA to assist those who, as a appropriate for the IETF LLC to assist those who, as a
result, have been inconvenienced in some way. result, have been inconvenienced in some way.
</t> </t>
<section title="Venue City Criteria"> <section title="Venue City Criteria">
<t><list style="symbols"> <t>The following requirements relate to the Venue city.</t>
<t>Travel to the Venue is acceptable based on cost, time, and burden <ul spacing="normal">
<li>Travel to the Venue is acceptable based on cost, time, and burden
for participants traveling from multiple regions. It is anticipated for participants traveling from multiple regions. It is anticipated
that the burden borne will be generally shared over the course of that the burden borne will generally be shared over the course of
multiple years.</t> multiple years.</li>
<t>The Venue is assessed as favorable for obtaining a host and <li>The Venue is assessed as favorable for obtaining a host and
sponsors. That is, the Meeting is in a location that sponsors. That is, the Meeting is in a location in which
it is possible and probable to find a host and sponsors. </t> it is possible and probable to find a host and sponsors. </li>
<t>Travel barriers to entry, including visa requirements, are <li>Travel barriers to entry, including visa requirements, are
likely to be such that an overwhelming majority of likely to be such that an overwhelming majority of
participants who wish to do so can attend. The term "travel participants who wish to do so can attend. The term "travel
barriers" is to be read barriers" is to be read
broadly by the IASA in the context of whether a broadly by the IETF LLC in the context of whether a
successful meeting can be had.</t> successful meeting can be had.</li>
<t>Economic, safety, and health risks associated with this Venue are <li>Economic, safety, and health risks associated with this Venue are
acceptable. </t> acceptable. </li>
<t>The selection of the venue comports with <li>The selection of the venue comports with the practices described in
<xref target="I-D.ietf-mtgvenue-meeting-policy" />. <xref target="RFC8719" />.
</t> </li>
</list> </ul>
</t>
</section> </section>
<section title="Basic Venue Criteria"> <section title="Basic Venue Criteria">
<t>The following requirements relate to the Venue and Facilities.</t> <t>The following requirements relate to the Venue and Facilities.</t>
<t>The IETF operates internationally and adjusts to <t>The IETF operates internationally and adjusts to
local requirements. Facilities selected for IETF Meetings SHALL local requirements. Facilities selected for IETF meetings <bcp14>SHALL </bcp14>
have provided written assurance that they are in compliance with have provided written assurance that they are in compliance with
local health, safety and accessibility laws and regulations, local health, safety, and accessibility laws and regulations,
and will remain in compliance throughout our stay. and that they will remain in compliance throughout our stay.
</t> </t>
<t>In addition:</t> <t>In addition:</t>
<t>
<list style="symbols"> <ul spacing="normal">
<t>There are sufficient places (e.g., a mix of hallways, bars, meeting <li>There are sufficient places (e.g., a mix of hallways, bars, meeting
rooms, and restaurants) for people to hold ad hoc rooms, and restaurants) for people to hold ad hoc
conversations and group discussions in the combination of conversations and group discussions in the combination of
spaces offered by the facilities, hotels and spaces offered by the facilities, hotels, and
bars/restaurants in the surrounding area, within walking bars/restaurants in the surrounding area, within walking
distance (5-10 minutes).</t> distance (5-10 minutes).</li>
<t>The cost of guest rooms, meeting space, meeting food and beverage <li>The cost of guest rooms, meeting space, meeting food and beverage
is affordable, within the norms of business travel. is affordable, within the norms of business travel.</li>
</t> <li>The Facility is accessible, or
<t>The Facility is accessible or reasonable accommodations reasonable accommodations can be made to allow access, by people with
can be made to allow access by people with disabilities. disabilities. </li>
</t> </ul>
</list>
</t>
</section> </section>
<section title="Technical Meeting Needs"> <section title="Technical Meeting Needs">
<t>The following criteria relate to technical meeting needs.</t> <t>The following criteria relate to technical meeting needs.</t>
<t>
<list style="symbols"> <ul spacing="normal">
<t>The Facility's support technologies and services -- network, <li>The Facility's support technologies and services -- network,
audio-video, etc. -- are sufficient for the anticipated activities audio-video, etc. -- are sufficient for the anticipated activities
at the meeting, or the Facility is willing to add such at the meeting, or the Facility is willing to add such
infrastructure or these support technologies and services might be infrastructure, or these support technologies and services might be
provided by a third party, all at no -- or at an acceptable -- cost provided by a third party, all at no -- or at an acceptable -- cost
to the IETF.</t> to the IETF.</li>
<t>The IETF Hotel(s) directly provide, or else permit and facilitate, <li>The IETF Hotels directly provide, or else permit and facilitate,
the delivery of a high performance, robust, unfiltered and the delivery of a high performance, robust, unfiltered, and
unmodified Internet service for the public areas and guest unmodified Internet service for the public areas and guest
rooms, and that this service be included in the cost of rooms; this service is to be included in the cost of
the room.</t> the room.</li>
</list> </ul>
</t>
</section> </section>
<section title="Hotel Needs"> <section title="Hotel Needs">
<t>The following criteria relate to IETF Hotels.</t> <t>The following criteria relate to IETF Hotels.</t>
<t>
<list style="symbols"> <ul spacing="normal">
<t>The IETF Hotel(s) are within close proximity to each other and the <li>The IETF Hotels are within close proximity to each other and the
Facility.</t> Facility.</li>
<t>The guest rooms at the IETF Hotel(s) are sufficient in number to <li>The guest rooms at the IETF Hotels are sufficient in number to
house 1/3 or more of projected meeting attendees.</t> house one-third or more of projected meeting attendees.</li>
<t>Overflow Hotels can be placed under contract, within convenient <li>Overflow Hotels can be placed under contract, within convenient
travel time to and from the Facility and at a variety of guest room travel time to and from the Facility and at a variety of guest room
rates.</t> rates.</li>
<t>The Facility environs include budget hotels within convenient trave <li>The Facility environs include budget hotels within convenient trav
l el
time, cost, and effort.</t> time, cost, and effort.</li>
<t>The IETF Hotel(s) are accessible by people with disabilities. <li>The IETF Hotels are accessible by people with disabilities.
While we mandate wheelchair accessibility, other forms are While we mandate wheelchair accessibility, other forms are
important, and should be provided to the extent possible, important and should be provided for to the extent possible
based on anticipated needs of the community.</t> based on anticipated needs of the community.</li>
<t>At least one IETF Hotel or the Facility has a space for use as a lo <li>At least one IETF Hotel or the Facility has a space for use as a
unge, lounge, conducive to planned and ad hoc meetings and chatting, as well
conducive to planned and ad hoc meetings and chatting, as well as a space for working online. There are tables with seating, conven
as working online. There are tables with seating, convenient for ient for
small meetings with laptops. These can be at an open bar or casual small meetings with laptops. These can be at an open bar or casual
restaurant. Preferably the lounge area is centrally restaurant. Preferably the lounge area is centrally
located, permitting easy access to participants.</t> located, permitting easy access to participants.</li>
</list> </ul>
</t>
</section> </section>
<section title="Food and Beverage"> <section title="Food and Beverage">
<t>The following criteria relate to food and <t>The following criteria relate to food and
beverage.</t> beverage.</t>
<t> <ul spacing="normal">
<list style="symbols"> <li>The Facility environs, which include both on-site as well as areas
<t>The Facility environs, which includes both onsite, as well as areas
within a reasonable walking distance or conveniently within a reasonable walking distance or conveniently
accessible by a short taxi ride or by local accessible by a short taxi ride or by local
public transportation, have convenient and inexpensive public transportation, have convenient and inexpensive
choices for meals that can accommodate a wide range of dietary choices for meals that can accommodate a wide range of dietary
requirements.</t> requirements.</li>
<t>A range of attendee's health-related and religion-related dietary <li>A range of attendees' health-related and religion-related dietary
requirements can be satisfied with robust and flexible onsite requirements can be satisfied with robust and flexible on-site
service or through access to an adequate grocery.</t> service or through access to an adequate grocery store.</li>
<t>The Facility environs include grocery shopping that will accommodat <li>The Facility environs include grocery shopping that will accommoda
e a te a
wide range of dietary requirements, within a reasonable walking wide range of dietary requirements, within a reasonable walking
distance, or conveniently accessible by a short taxi, bus, or subway distance or conveniently accessible by a short taxi, bus, or subway
ride, from the Facility and IETF Hotels.</t> ride from the Facility and IETF Hotels.</li>
</list> </ul>
</t>
</section> </section>
</section> </section>
<section anchor="otherconsiderations" title="Other Consideraitons">
<t>The following considerations are desirable, but not as <section anchor="otherconsiderations" title="Other Considerations">
important as the preceding requirements, and thus should not be <t>The following considerations are desirable, but they are not as
traded off for them. important as the preceding requirements and thus should not be
traded-off for them.
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>We have something of a preference for an IETF meeting to
<t>We have something of a preference for an IETF meeting to be under "One Roof"; that is, qualified meeting space and guest room
be under "One Roof". That s are available in the
is, qualified meeting space and guest rooms are available in the same facility.</li>
same facility.</t> <li>It is desirable for Overflow Hotels to provide reasonable,
<t>It is desirable for Overflow Hotels to provide reasonable,
reliable, unfiltered Internet service for the public areas reliable, unfiltered Internet service for the public areas
and guest rooms, and that this service be included in the and guest rooms, and for this service be included in the
cost of the room.</t> cost of the room.</li>
<t>It is desirable to enter into a multi-event contract with the <li>It is desirable to enter into a multi-event contract with the
Facility and IETF Hotels or associated hotel chains in Facility and IETF Hotels or associated hotel chains in
case such a contract will either reduce case such a contract will reduce
administrative costs, reduce direct attendee costs, or both.</t> administrative costs, reduce direct attendee costs, or both.</li>
<t>Particularly when we are considering a city for the first <li>When we are considering a city for the first
time, it is desirable to have someone participate in the site time, it is particularly desirable to have someone familiar with
visit who is familiar with both the locale and the IETF. both the locale and the IETF participate in the site
Such a person can provide guidance visit. Such a person can provide guidance
regarding safety, location of local services, and regarding safety, location of local services,
understanding best ways to get to and from the Venue, and the best ways to get to and from the Venue, and
local customs, as well as identify how our requirements are local customs, as well as how our requirements are
met. met.</li>
</t> </ul>
</list>
</t>
</section> </section>
</section> </section>
<section title="Documentation Requirements"> <section title="Documentation Requirements">
<t>The IETF Community works best when it is well informed. This <t>The IETF Community works best when it is well informed. This
memo does not specify processes nor who has responsibility for memo does not specify processes nor who has responsibility for
fulfilling our requirements for meetings. Nevertheless, both of fulfilling our requirements for meetings. Nevertheless, both of
these aspects are important. Therefore, the IASA SHALL publicly these aspects are important. Therefore, the IETF LLC <bcp14>SHALL</bcp14> publicly
document and keep current both a list of roles and document and keep current both a list of roles and
responsibilities relating to IETF meetings, as well as the responsibilities relating to IETF meetings, as well as the
selection processes they use in order to fulfill the selection processes they use in order to fulfill the
requirements of the community. requirements of the community.
</t> </t>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t> <t>This document has no IANA actions.</t>
<t>[The RFC-Editor may remove this section prior to publicaiton.]</t>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" title="Security Considerations">
<t>This note proposes no protocols, and therefore no new protocol <t>This note proposes no protocols and therefore introduces no new protoco l
insecurities.</t> insecurities.</t>
</section> </section>
<section anchor="Privacy" title="Privacy Considerations"> <section anchor="Privacy" title="Privacy Considerations">
<t>Different places have different constraints on individual <t>Different places have different constraints on individual
privacy. The requirements in this memo are intended to privacy. The requirements in this memo are intended to
provide for some limited protections. provide for some limited protections.
As meetings are announced, IASA SHALL inform the IETF of As meetings are announced, the IETF LLC <bcp14>SHALL</bcp14> inform the I ETF of
any limitations to privacy they have become aware of in their any limitations to privacy they have become aware of in their
investigations. For example, participants would be informed investigations. For example, participants would be informed
of any regulatory authentication or logging requirements.</t> of any regulatory authentication or logging requirements.</t>
</section> </section>
<section anchor="Contributors" title="Contributors">
<t>The following people provided substantial text contributions
to this memo:
</t>
<t>Fred Baker
<vspace />
Email: fred.ietf@gmail.com
</t>
<t>Fred originated this work.</t>
<t>
Ray Pelletier<vspace />
Email: Rpelletier13@gmail.com
</t>
<t>
Laura Nugent<vspace />
Association Management Solutions<vspace />
Email: lnugent@amsl.com
</t><t>
Lou Berger<vspace />
LabN Consulting, L.L.C.<vspace />
Email: lberger@labn.net
</t><t>
Ole Jacobsen<vspace />
The Internet Protocol Journal<vspace />
EMail: olejacobsen@me.com
</t><t>
Jim Martin<vspace />
INOC<vspace />
Email: jim@inoc.com</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Additional contributions came from Jari Arkko, Scott Bradner,
Alissa Cooper, Dave Crocker, Jordi Palet Martinez, Andrew
Sullivan, and other participants in the mtgvenue working
group. Those listed in this section or as contributors may or
may not agree with the content of this memo.</t>
</section>
</middle> </middle>
<back> <back>
<!--references split to informative and normative --> <!--references split to informative and normative -->
<references title="Normative References"> <references title="Normative References">
&RFC2119; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
&RFC8174; xml"/>
<reference anchor="RFC4071" <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
target="http://www.rfc-editor.org/info/rfc4071"> xml"/>
<front>
<title>Structure of the IETF Administrative Support Activity <!-- ietf-mtgvenue-meeting-policy -->
(IASA)</title> <reference anchor="RFC8719" target="https://www.rfc-editor.org/info/rfc8719">
<author fullname="R. Austein" initials="R." role="editor" <front>
surname="Austein"> <title>High-Level Guidance for the Meeting Policy of the IETF</title>
<organization /> <author initials='S.' surname='Krishnan' fullname='Suresh Krishnan'>
</author> <organization/>
<author fullname="B. Wijnen" initials="B." role="editor" </author>
surname="Wijnen"> <date month='January' year='2020'/>
<organization /> </front>
</author> <seriesInfo name="BCP" value="226"/>
<date month="April" year="2005" /> <seriesInfo name="RFC" value="8719"/>
<abstract> <seriesInfo name="DOI" value="10.17487/RFC8719"/>
<t>This document describes the structure of the IETF Administrative </reference>
Support Activity (IASA) as an activity housed within the Internet
Society (ISOC). It defines the roles and responsibilities of the <!-- [rfced] When this document was initially in AUTH48, we received notice
IETF Administrative Oversight Committee (IAOC), the IETF that a reference to draft-ietf-iasa2-rfc4071bis should be added. We have
Administrative Director (IAD), and ISOC in the fiscal and added an informative reference to RFC-to-be 8711. In addition, we added a
administrative support of the IETF standards process. It also citation where the LLC is first mentioned in the Introduction. Please review
defines the membership and selection rules for the IAOC. This and let us know if any updates are needed.
document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for Notes about including a reference to draft-ietf-iasa2-rfc4071bis:
improvements.</t>
</abstract> - Date: Wed, 12 Dec 2018
</front> Following up on our earlier thread, it has become apparent that
<seriesInfo name="BCP" value="101" /> draft-ietf-iasa2-rfc4071bis is now needed as a reference from
<seriesInfo name="RFC" value="4071" /> draft-ietf-mtgvenue-iaoc-venue-selection-process rather than an earlier draft
<seriesInfo name="DOI" value="10.17487/RFC4071" /> that was mentioned. Barring objections from Alissa, please update your
</reference> records for draft-ietf-mtgvenue-iaoc-venue-selection-process to indicate a
&I-D.ietf-mtgvenue-meeting-policy; MISSREF to draft-ietf-iasa2-rfc4071bis.
Date: Thu, 14 Mar 2019
Returning to this draft that there was some confusion about, I think
draft-ietf-mtgvenue-iaoc-venue-selection-process will need to reference
draft-ietf-iasa2-rfc4071bis and not draft-ietf-iasa2-struct. Originally we
were planning to reference 4071, and it was not clear that there would be a
4071bis. The only reason we’re referencing either of these drafts is that we
are tied to the term “IASA”.
-->
</references> </references>
<references title="Informative References"> <references title="Informative References">
&RFC3935; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3935.
&RFC6771; xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6771.
xml"/>
<reference anchor="RFC8711" target="https://rfc-editor.org/info/rfc8711">
<front>
<title>Structure of the IETF Administrative Support Activity,
Version 2.0</title>
<author initials="B." surname="Haberman">
<organization/>
</author>
<author initials="J." surname="Hall">
<organization/>
</author>
<author initials="J." surname="Livingood">
<organization/>
</author>
<date month="January" year="2020"/>
</front>
<seriesInfo name="BCP" value="101"/>
<seriesInfo name="RFC" value="8711"/>
<seriesInfo name="DOI" value="10.17487/RFC8711"/>
</reference>
</references> </references>
<section anchor="log" title="Change Log">
<t>[RFC Editor: Please remove this section prior to publication.]</t> <section anchor="Acknowledgements" title="Acknowledgements" numbered="false"
<t> >
<list style="hanging"> <t>Contributions came from <contact fullname="Jari Arkko"/>, <contact
<t hangText="2016-01-12:">Initial version</t> fullname="Scott Bradner"/>,
<t hangText="2016-01-21:">Update to reflect <contact fullname="Alissa Cooper"/>, <contact fullname="Dave
https://iaoc.ietf.org/documents/VenueSelectionCriteriaJan2016.pdf Crocker"/>, <contact fullname="Jordi Palet Martinez"/>, <contact fullname
and ="Andrew
https://iaoc.ietf.org/documents/VenueSelectionProcess11Jan16.pdf, Sullivan"/>, and other participants in the MTGVENUE Working
accessed from Group. Those listed in this section or as contributors may or
https://iaoc.ietf.org/private/privatemeetings.html.</t> may not agree with the content of this memo.</t>
<t hangText="2016-02-23:">Reorganize and capture IAOC Meetings </section>
Committee discussions.</t>
<t hangText="2016-03-03:">Final from Design Team.</t> <section anchor="Contributors" title="Contributors" numbered="false">
<t hangText="2016-03-17:">First update incorporating mtgvenue@ietf.org <t>The following people provided substantial text contributions
comments</t> to this memo. Specifically, Fred Baker originated this work.
<t hangText="2016-05-20">Updated in accordance with editing by Laura
Nugent, Dave Crocker, Lou Berger, Fred Baker, and others.</t>
<t hangText="posting as working group draft">August 2, 2016</t>
<t hangText="Reorganized per Alissa Cooper outline">Work in progress.
In addition, contributors were re-organized to be authors.</t>
<t hangText="2016-10-28">Editor changeover. Further alignment with
guidance by Alissa Cooper, Andrew Sullivan and the mtgvenue working
group. Many various changes.</t>
<t hangText="2016-11-16">Extensive editorial, format and polishing
pass. A few substance changes, including food section.</t>
<t hangText="2016-11-30">Additions based on working group meeting and
off-list discussions; more editorial and format hacking.</t>
<t hangText="2016-12-24">Various clarifying bits to provide some glue
between the high-level 'objectives' and the detailed criteria and
roles, per suggestions fronm Lear. Editorial changes, per 12/27
response to Cooper. Refined uses of 'Facility' and 'Venue', per 12/4
response to Carpenter; also added Carpenter 'lounge' text. Moved
community consultation to a separate criterion; removed 'acceptable
to the IETF Community from the 2 entries that had it. Removed
Post-Seroul Revisions and Text Carried Forward.</t>
<t hangText="2016-12-24">
Address comments made on list by Stephen Farrell
&lt;stephen.farrell@cs.tcd.ie&gt;. Minor text change in Section
5. Replaced links in sections 5.3 and 5.5.</t>
<t hangText="2017-03-12">
Add openness comment as requested by Stephen Farrell. Add
statement about 4071 as proposed by Brian and modified by
Jari. Elaborated on what "unfiltered" means, based on
discussion between Eliot and Stephen. Preface to Section
5 as discussed between Lou and Stephen. Slight editorial
tweak to that by Eliot. IETF operates
internationally, as proposed by Brian.
</t>
<t hangText="2017-04-18">
Add new introductory text. Sharpen mandatory
definition. Split first criteria into two, and reword them to
be more actionable. Remove net cash
positive requirement. Change many critera from Mandatory
to Important. Remove consensus text. Modify chapeau.
Add some normative MUSTs in Section 5, and restructure
Section 5.5. A bunch of other stuff as well. Use diff.
</t>
<t hangText="2017-05-14">
Happy Mother's Day. This version removes the tabular
format of requirements, moves mandatory requirements up
front, adds a desiderata section, adds a mandatory
filtering requirement, consolidates introductory text,
moves procedural requirements into Section 5, removes
the definition of Headquarters Hotel, removes the MUST in
late changes, and adds a desire for a local participant in
site selection.
</t>
<t hangText="2017-09-12">
These are last call edits. Big change is around Internet
requirements. Also, address Andrew Sullivan comments, as
well as SM comments. Brian Carpenter big scrub on IAOC to
IASA.
</t>
<t hangText="2017-10-20">
Final edits from WGLC based on Laura Nugent's review. Most are
editorial for clarity. Also, remove large table and link
to the live copy.
</t>
<t hangText="2018-01-10">
Changes based on AD review.
</t>
<t hangText="2018-02-02">
Changes based on genart review and IETF last call.
</t>
<t hangText="2018-05-07">
Several versions of changes. Based on reorg of meetings
committee, Section 4 and 5 moved out. Also, final LC
comments addressed. In particular: no smoking added.
Reference to RFC8174 added. Reference to meeting policy
doc added.
</t>
<t hangText="2018-05-11">
Remove no smoking.
</t>
</list>
</t> </t>
<contact fullname="Fred Baker">
<address>
<email>fred.ietf@gmail.com</email>
</address>
</contact>
<contact fullname="Ray Pelletier">
<address>
<email>Rpelletier13@gmail.com</email>
</address>
</contact>
<contact fullname="Laura Nugent">
<organization>Association Management Solutions</organization>
<address>
<email>lnugent@amsl.com</email>
</address>
</contact>
<contact fullname="Lou Berger">
<organization>LabN Consulting, L.L.C.</organization>
<address>
<email>lberger@labn.net</email>
</address>
</contact>
<contact fullname="Ole Jacobsen">
<organization>The Internet Protocol Journal</organization>
<address>
<email>olejacobsen@me.com</email>
</address>
</contact>
<contact fullname="Jim Martin">
<organization>INOC</organization>
<address>
<email>jim@inoc.com</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 91 change blocks. 
446 lines changed or deleted 405 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/