rfc8718xml2.original.xml		rfc8718.xml
	<?xml version='1.0' encoding='ascii'?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" conse
	<!ENTITY RFC2119 SYSTEM		nsus="true" docName="draft-ietf-mtgvenue-iaoc-venue-selection-process-16" indexI
	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">		nclude="true" ipr="trust200902" number="8718" prepTime="2020-02-26T17:09:53" scr
	<!ENTITY RFC8174 SYSTEM		ipts="Common,Latin" seriesNo="226" sortRefs="true" submissionType="IETF" symRefs
	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">		="true" tocDepth="2" tocInclude="true" xml:lang="en">
	<!ENTITY RFC3935 SYSTEM		<link href="https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-se
	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3935.xml">		lection-process-16" rel="prev"/>
	<!ENTITY RFC6771 SYSTEM		<link href="https://dx.doi.org/10.17487/rfc8718" rel="alternate"/>
	"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6771.xml">		<link href="urn:issn:2070-1721" rel="alternate"/>
	<!ENTITY I-D.ietf-mtgvenue-meeting-policy SYSTEM
	"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mtgvenue-
	meeting-policy.xml">
	]>
	<?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"
	docName="draft-ietf-mtgvenue-iaoc-venue-selection-process-16"
	ipr="trust200902" submissionType="IETF" updates="" xml:lang="en">
	<front>		<front>
	<title abbrev="Venue Selection">IETF Plenary Meeting Venue Selection		<title abbrev="Venue Selection">IETF Plenary Meeting Venue Selection Process
	Process</title>		</title>
			<seriesInfo name="RFC" value="8718" stream="IETF"/>
			<seriesInfo name="BCP" value="226" stream="IETF"/>
	<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 showOnFrontPage="true">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 month="02" year="2020"/>
	<date />
	<area>General</area>		<area>General</area>
	<workgroup>mtgvenue</workgroup>		<workgroup>Meeting Venue Working Group</workgroup>
			<keyword>Meeting Venues</keyword>
	<abstract>		<keyword>Meeting selection process</keyword>
	<t>The IASA has responsibility for arranging IETF plenary meeting Venue		<keyword>IASA</keyword>
	selection and operation. This memo specifies IETF community		<abstract pn="section-abstract">
	requirements for meeting venues, including hotels and meeting		<t pn="section-abstract-1">
	room space. It directs the IASA to make available additional		The IETF Administration Support Activity (IASA) is responsible
	process documents that describe the current meeting		for arranging the selection and operation of the IETF plenary meeting
	selection process.</t>		venue. This memo specifies IETF community
			requirements for meeting venues, including hotels and meeting
			space. It also directs the IASA to make available additional
			process documents that describe the current meeting
			selection process.</t>
	</abstract>		</abstract>
			<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
			"exclude" pn="section-boilerplate.1">
			<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
			>
			<t pn="section-boilerplate.1-1">
			This memo documents an Internet Best Current Practice.
			</t>
			<t pn="section-boilerplate.1-2">
			This document is a product of the Internet Engineering Task Force
			(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by
			the Internet Engineering Steering Group (IESG). Further information
			on BCPs is available in Section 2 of RFC 7841.
			</t>
			<t pn="section-boilerplate.1-3">
			Information about the current status of this document, any
			errata, and how to provide feedback on it may be obtained at
			<eref target="https://www.rfc-editor.org/info/rfc8718" brackets="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" pn="section-boilerplate.2">
			<name slugifiedName="name-copyright-notice">Copyright Notice</name>
			<t pn="section-boilerplate.2-1">
			Copyright (c) 2020 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			</t>
			<t pn="section-boilerplate.2-2">
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(<eref target="https://trustee.ietf.org/license-info" brackets="none
			"/>) 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 Simplified BSD License text as described in
			Section 4.e of the Trust Legal Provisions and are provided without
			warranty as described in the Simplified BSD License.
			</t>
			</section>
			</boilerplate>
			<toc>
			<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.1-1">
			<li pn="section-toc.1-1.1">
			<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
			="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
			n</xref></t>
			</li>
			<li pn="section-toc.1-1.2">
			<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
			="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-venue-selection-objective
			s">Venue Selection Objectives</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.2.2">
			<li pn="section-toc.1-1.2.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derive
			dContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-core-values">
			Core Values</xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.2">
			<t keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derive
			dContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-venue-selecti
			on-non-objecti">Venue Selection Non-objectives</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.3">
			<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
			="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-meeting-criteria">Meeting
			Criteria</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.3.2">
			<li pn="section-toc.1-1.3.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derive
			dContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-mandatory-cri
			teria">Mandatory Criteria</xref></t>
			</li>
			<li pn="section-toc.1-1.3.2.2">
			<t keepWithNext="true" pn="section-toc.1-1.3.2.2.1"><xref derive
			dContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-important-cri
			teria">Important Criteria</xref></t>
			</li>
			<li pn="section-toc.1-1.3.2.3">
			<t keepWithNext="true" pn="section-toc.1-1.3.2.3.1"><xref derive
			dContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-other-conside
			rations">Other Considerations</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.4">
			<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
			="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-documentation-requirement
			s">Documentation Requirements</xref></t>
			</li>
			<li pn="section-toc.1-1.5">
			<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
			="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
			Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.6">
			<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
			="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-security-considerations">
			Security Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.7">
			<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
			="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-privacy-considerations">P
			rivacy Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.8">
			<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
			="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-normative-references">Nor
			mative References</xref></t>
			</li>
			<li pn="section-toc.1-1.9">
			<t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent
			="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-informative-references">I
			nformative References</xref></t>
			</li>
			<li pn="section-toc.1-1.10">
			<t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedConten
			t="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derived
			Content="" format="title" sectionFormat="of" target="name-acknowledgements">Ackn
			owledgements</xref></t>
			</li>
			<li pn="section-toc.1-1.11">
			<t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedConten
			t="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derived
			Content="" format="title" sectionFormat="of" target="name-contributors">Contribu
			tors</xref></t>
			</li>
			<li pn="section-toc.1-1.12">
			<t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedConten
			t="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derived
			Content="" format="title" sectionFormat="of" target="name-authors-address">Autho
			r's Address</xref></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
			<section anchor="Introduction" numbered="true" removeInRFC="false" toc="incl
	<section anchor="Introduction" title="Introduction">		ude" pn="section-1">
	<t>The Internet Administrative Support Activity (IASA) has		<name slugifiedName="name-introduction">Introduction</name>
	responsibility for arranging IETF plenary meeting venue		<t pn="section-1-1">The IETF Administrative Support Activity (IASA) <xref
	selection and operation. The purpose of this document is to		target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>
			is
			responsible for arranging the selection and operation of the IETF
			plenary meeting venue. The purpose of this document is to
	guide the IASA in their selection of regions, cities,		guide the IASA in their selection of regions, cities,
	facilities, and hotels. The IASA applies this guidance at		facilities, and hotels. The IASA 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 pn="section-1-2">It remains the responsibility of the IASA to apply the
	<t>It remains the responsibility of the IASA to apply their best		ir best judgment. The
	judgment. The IASA accepts input and feedback both during the		IASA accepts input and feedback during the consultation process and later (for
	consultation process and later (for instance when there are changes in th		instance, when there are changes in the situation at a chosen location).
	e		The community is encouraged to provide direct feedback about the IASA's
	situation at a chosen location). Any appeals remain subject to		performance to the IETF Administration LLC, the Nominations Committee (NOMCOM),
	the provisions of <xref target="RFC4071">BCP101</xref>. As		or the Internet Engineering Steering Group (IESG). Any reviews of IASA
	always, the community is encouraged to provide direct feedback to the		decisions remain subject to the provisions of <xref target="RFC8711" section="4.
	Nominations Committee (NOMCOM), Internet Engineering Steering		7" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/r
	Group (IESG), and IAB regarding the discharge of the IASA's		fc8711#section-4.7" derivedContent="RFC8711"/> (BCP 101).
	performance.		</t>
	</t>		<t pn="section-1-3">The following four terms describe the places for which
	<t>Four terms describe the places for which the IETF contracts		the IETF contracts
	services:<list style="hanging">		services:</t>
	<t hangText="Venue: "><vspace />This is an umbrella term for the		<dl newline="true" spacing="normal" pn="section-1-4">
	city, meeting resources and guest room resources.		<dt pn="section-1-4.1">Venue:</dt>
	</t>		<dd pn="section-1-4.2">An umbrella term for the
	<t hangText="Facility: "><vspace />The building that houses		city, meeting resources, and guest room resources.</dd>
	meeting rooms and associated resources. It may also		<dt pn="section-1-4.3">Facility:</dt>
	house an IETF Hotel.		<dd pn="section-1-4.4">The building that houses
	</t>		meeting rooms and associated resources. It may also
	<t hangText="IETF Hotels: "><vspace />One or more hotels, in close		house an IETF Hotel.</dd>
			<dt pn="section-1-4.5">IETF Hotels:</dt>
			<dd pn="section-1-4.6">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 IASA
	(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 pn="section-1-4.7">Overflow Hotels:</dt>
			<dd pn="section-1-4.8">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 IASA.</dd>
	</list></t>		</dl>
	<t>		<t pn="section-1-5">
			The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",		D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
	and "OPTIONAL" in this document are to be interpreted as described in		OT RECOMMENDED</bcp14>",
	BCP 14 <xref target="RFC2119"/><xref target="RFC8174"/> when, and		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	only when, they appear in all capitals, as shown here.		be interpreted as
	</t>		described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
			f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
			mat="of" derivedContent="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
	</section>		</section>
			<section anchor="objectives" numbered="true" removeInRFC="false" toc="includ
	<section anchor="objectives" title="Venue Selection Objectives">		e" pn="section-2">
	<section anchor="core" title="Core Values">		<name slugifiedName="name-venue-selection-objectives">Venue Selection Obje
	<t>Some IETF values pervade the selection process. These often are		ctives</name>
	applicable to multiple requirements listed in this document. They are		<section anchor="core" numbered="true" removeInRFC="false" toc="include" p
	not limited to the following, but at minimum include: <list		n="section-2.1">
	style="hanging">		<name slugifiedName="name-core-values">Core Values</name>
	<t hangText="Why we meet?"><vspace />We meet to pursue the IETF's		<t pn="section-2.1-1">Some IETF values pervade the selection process. Th
	mission <xref target="RFC3935" />, partly by advancing the		ese are often
	development of Internet-Drafts and RFCs. We also seek to		applicable to multiple requirements listed in this document. At a
			minimum, they include the following:</t>
			<dl newline="true" spacing="normal" pn="section-2.1-2">
			<dt pn="section-2.1-2.1">Why we meet:</dt>
			<dd pn="section-2.1-2.2">We meet to pursue the IETF's
			mission <xref target="RFC3935" format="default" sectionFormat="of"
			derivedContent="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>
			<dt pn="section-2.1-2.3">Inclusiveness:</dt>
	<t hangText="Inclusiveness:"><vspace />We would like to facilitate		<dd pn="section-2.1-2.4">
	the onsite or remote participation of anyone who wants to be		<t pn="section-2.1-2.4.1">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 pn="section-2.1-2.4.2">Every country has limits on who it will pe
	borders. However the IETF seeks to: <list style="numbers">		rmit within its
	<t>Minimize situations in which onerous entry regulations		borders. However, the IETF seeks to:</t>
			<ol spacing="normal" start="1" type="1" pn="section-2.1-2.4.3">
			<li pn="section-2.1-2.4.3.1" derivedCounter="1.">Minimize situatio
			ns 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 pn="section-2.1-2.4.3.2" derivedCounter="2.">Avoid meeting in
			countries with laws that effectively exclude
	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 pn="section-2.1-2.5">Where we meet:</dt>
	locations globally, in order to spread the difficulty and cost of		<dd pn="section-2.1-2.6">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" format="default" sectionFormat="of" derived
	</t>		Content="RFC8719"/>.</dd>
			<dt pn="section-2.1-2.7">Internet Access:</dt>
	<t hangText="Internet Access:"><vspace />As an organization, we		<dd pn="section-2.1-2.8">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>
			<dt pn="section-2.1-2.9">Focus:</dt>
	<t hangText="Focus:"><vspace />We meet to have focused		<dd pn="section-2.1-2.10">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" format="default" sectionFo
	<t hangText="Economics:"><vspace />Meeting attendees participate as		rmat="of" derivedContent="RFC6771"/>.</dd>
			<dt pn="section-2.1-2.11">Economics:</dt>
			<dd pn="section-2.1-2.12">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>
			<dt pn="section-2.1-2.13">Least Astonishment and Openness:</dt>
	<t hangText="Least Astonishment and Openness:"><vspace />		<dd pn="section-2.1-2.14">Regular participants
	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		IASA 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" numbered="true" removeInRFC="false" toc="i
	<section anchor="nonobjectives" title="Venue Selection Non-Objectives">		nclude" pn="section-2.2">
	<t>IETF meeting Venues are not selected or declined with the explicit		<name slugifiedName="name-venue-selection-non-objecti">Venue Selection N
	purposes of:<list style="hanging">		on-objectives</name>
			<t pn="section-2.2-1">IETF meeting Venues are not selected or declined w
	<t hangText="Politics: "><vspace />Endorsing or condemning		ith the explicit
			purposes of:</t>
			<dl newline="true" spacing="normal" pn="section-2.2-2">
			<dt pn="section-2.2-2.1">Politics:</dt>
			<dd pn="section-2.2-2.2">Endorsing or condemning
	particular countries, political paradigms, laws, regulations, or		particular countries, political paradigms, laws, regulations, or
	policies.</t>		policies.</dd>
			<dt pn="section-2.2-2.3">Maximal attendance:</dt>
	<t hangText="Maximal attendance: "><vspace />		<dd pn="section-2.2-2.4">While the IETF strives to be as inclusive as
	While the IETF strives to be as inclusive as possible		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>		<dt pn="section-2.2-2.5">Tourism:</dt>
	<t hangText="Tourism: "><vspace />Variety in site-seeing		<dd pn="section-2.2-2.6">Variety in site-seeing
	experiences.</t>		experiences.</dd>
	</list></t>		</dl>
	</section>		</section>
	</section>		</section>
	<section anchor="criteria" title="Meeting Criteria">		<section anchor="criteria" numbered="true" removeInRFC="false" toc="include"
	<t>This section contains the criteria for IETF meetings. It is		pn="section-3">
	broken down into three subsections: mandatory criteria,		<name slugifiedName="name-meeting-criteria">Meeting Criteria</name>
	important criteria, and other considerations, each as explained		<t pn="section-3-1">This section contains the criteria for IETF meetings.
			It is
			broken down into three subsections: <xref target="mandatories" format="def
			ault" sectionFormat="of" derivedContent="Section 3.1">mandatory criteria</xref>,
			<xref target="importants" format="default" sectionFormat="of" derivedConte
			nt="Section 3.2">important criteria </xref>, and <xref target="otherconsideratio
			ns" format="default" sectionFormat="of" derivedContent="Section 3.3">other consi
			derations</xref>, each as explained
	below.		below.
	</t>		</t>
	<section anchor="mandatories" title="Mandatory Criteria">		<section anchor="mandatories" numbered="true" removeInRFC="false" toc="inc
	<t>If criteria in this subsection cannot be met, a particular		lude" pn="section-3.1">
	location is unacceptable for selection, and the IASA MUST NOT		<name slugifiedName="name-mandatory-criteria">Mandatory Criteria</name>
	enter into a contract. Should the IASA learn that a location no		<t pn="section-3.1-1">If criteria in this subsection cannot be met, a pa
	longer can meet a mandatory requirement after having entered		rticular
			location is unacceptable for selection, and the IASA <bcp14>MUST NOT</bcp
			14>
			enter into a contract. Should the IASA 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">		<ul spacing="normal" bare="false" empty="false" pn="section-3.1-2">
	<t>The Facility MUST provide sufficient		<li pn="section-3.1-2.1">The Facility <bcp14>MUST</bcp14> provide suff
	space in an appropriate layout to accommodate the expected		icient
	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 pn="section-3.1-2.2">The Facility and IETF Hotels <bcp14>MUST</bcp
			14> provide wheelchair access
	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 pn="section-3.1-2.3">It <bcp14>MUST</bcp14> be possible to provisi
			on
	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 anchor="importants" numbered="true" removeInRFC="false" toc="incl
	</section>		ude" pn="section-3.2">
			<name slugifiedName="name-important-criteria">Important Criteria</name>
	<section anchor="importants" title="Important Criteria">		<t pn="section-3.2-1">The criteria in this subsection are not mandatory,
	<t>The criteria in this subsection are not mandatory,		but they are still highly significant. It may be necessary to
	but are still highly significant. It may be necessary to		trade-off one or more of these criteria against others.
	trade one or more of these criteria off 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 to another that meets fewer of
	whole preferable than 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 IASA <bcp14>MU
			ST</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 IASA 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 numbered="true" removeInRFC="false" toc="exclude" pn="section-3
	<t><list style="symbols">		.2.1">
	<t>Travel to the Venue is acceptable based on cost, time, and burden		<name slugifiedName="name-venue-city-criteria">Venue City Criteria</na
			me>
			<t pn="section-3.2.1-1">The following requirements relate to the Venue
			city.</t>
			<ul spacing="normal" bare="false" empty="false" pn="section-3.2.1-2">
			<li pn="section-3.2.1-2.1">Travel to the Venue is acceptable based o
			n 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 pn="section-3.2.1-2.2">The Venue is assessed as favorable for ob
	sponsors. That is, the Meeting is in a location that		taining a host and
	it is possible and probable to find a host and sponsors. </t>		sponsors. That is, the Meeting is in a location in which
	<t>Travel barriers to entry, including visa requirements, are		it is possible and probable to find a host and sponsors. </li>
			<li pn="section-3.2.1-2.3">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 IASA 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 pn="section-3.2.1-2.4">Economic, safety, and health risks associ
	acceptable. </t>		ated with this Venue are
	<t>The selection of the venue comports with		acceptable. </li>
	<xref target="I-D.ietf-mtgvenue-meeting-policy" />.		<li pn="section-3.2.1-2.5">The selection of the venue comports with
	</t>		the practices described in
	</list>		<xref target="RFC8719" format="default" sectionFormat="of" derived
	</t>		Content="RFC8719"/>.
	</section>		</li>
	<section title="Basic Venue Criteria">		</ul>
	<t>The following requirements relate to the Venue and Facilities.</t>		</section>
			<section numbered="true" removeInRFC="false" toc="exclude" pn="section-3
	<t>The IETF operates internationally and adjusts to		.2.2">
	local requirements. Facilities selected for IETF Meetings SHALL		<name slugifiedName="name-basic-venue-criteria">Basic Venue Criteria</
			name>
			<t pn="section-3.2.2-1">The following requirements relate to the Venue
			and Facilities.</t>
			<t pn="section-3.2.2-2">The IETF operates internationally and adjusts
			to
			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 pn="section-3.2.2-3">In addition:</t>
	<t>In addition:</t>		<ul spacing="normal" bare="false" empty="false" pn="section-3.2.2-4">
	<t>		<li pn="section-3.2.2-4.1">There are sufficient places (e.g., a mix
	<list style="symbols">		of hallways, bars, meeting
	<t>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 pn="section-3.2.2-4.2">The cost of guest rooms, meeting space, m
	is affordable, within the norms of business travel.		eeting food and beverage
	</t>		is affordable, within the norms of business travel.</li>
	<t>The Facility is accessible or reasonable accommodations		<li pn="section-3.2.2-4.3">The Facility is accessible, or
	can be made to allow access by people with disabilities.		reasonable accommodations can be made to allow access, by people with
	</t>		disabilities. </li>
	</list>		</ul>
	</t>		</section>
	</section>		<section numbered="true" removeInRFC="false" toc="exclude" pn="section-3
	<section title="Technical Meeting Needs">		.2.3">
	<t>The following criteria relate to technical meeting needs.</t>		<name slugifiedName="name-technical-meeting-needs">Technical Meeting N
	<t>		eeds</name>
	<list style="symbols">		<t pn="section-3.2.3-1">The following criteria relate to technical mee
	<t>The Facility's support technologies and services -- network,		ting needs.</t>
			<ul spacing="normal" bare="false" empty="false" pn="section-3.2.3-2">
			<li pn="section-3.2.3-2.1">The Facility's support technologies and s
			ervices -- 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>
			<li pn="section-3.2.3-2.2">The IETF Hotels directly provide, or else
	<t>The IETF Hotel(s) directly provide, or else permit and facilitate,		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 numbered="true" removeInRFC="false" toc="exclude" pn="section-3
	<section title="Hotel Needs">		.2.4">
	<t>The following criteria relate to IETF Hotels.</t>		<name slugifiedName="name-hotel-needs">Hotel Needs</name>
	<t>		<t pn="section-3.2.4-1">The following criteria relate to IETF Hotels.<
	<list style="symbols">		/t>
	<t>The IETF Hotel(s) are within close proximity to each other and the		<ul spacing="normal" bare="false" empty="false" pn="section-3.2.4-2">
	Facility.</t>		<li pn="section-3.2.4-2.1">The IETF Hotels are within close proximit
	<t>The guest rooms at the IETF Hotel(s) are sufficient in number to		y to each other and the
	house 1/3 or more of projected meeting attendees.</t>		Facility.</li>
	<t>Overflow Hotels can be placed under contract, within convenient		<li pn="section-3.2.4-2.2">The guest rooms at the IETF Hotels are su
			fficient in number to
			house one-third or more of projected meeting attendees.</li>
			<li pn="section-3.2.4-2.3">Overflow Hotels can be placed under contr
			act, 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 pn="section-3.2.4-2.4">The Facility environs include budget hote
	l		ls within convenient travel
	time, cost, and effort.</t>		time, cost, and effort.</li>
	<t>The IETF Hotel(s) are accessible by people with disabilities.		<li pn="section-3.2.4-2.5">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 pn="section-3.2.4-2.6">At least one IETF Hotel or the Facility h
	unge,		as a space for use as a
	conducive to planned and ad hoc meetings and chatting, as well		lounge, conducive to planned and ad hoc meetings and chatting, as well
	as working online. There are tables with seating, convenient for		as a space for working online. There are tables with seating, conven
			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 numbered="true" removeInRFC="false" toc="exclude" pn="section-3
	<section title="Food and Beverage">		.2.5">
	<t>The following criteria relate to food and		<name slugifiedName="name-food-and-beverage">Food and Beverage</name>
			<t pn="section-3.2.5-1">The following criteria relate to food and
	beverage.</t>		beverage.</t>
	<t>		<ul spacing="normal" bare="false" empty="false" pn="section-3.2.5-2">
	<list style="symbols">		<li pn="section-3.2.5-2.1">The Facility environs, which include both
	<t>The Facility environs, which includes both onsite, as well as areas		on-site 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 pn="section-3.2.5-2.2">A range of attendees' health-related and
	requirements can be satisfied with robust and flexible onsite		religion-related dietary
	service or through access to an adequate grocery.</t>		requirements can be satisfied with robust and flexible on-site
	<t>The Facility environs include grocery shopping that will accommodat		service or through access to an adequate grocery store.</li>
	e a		<li pn="section-3.2.5-2.3">The Facility environs include grocery sho
			pping that will accommodate 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" numbered="true" removeInRFC="false"
	<section anchor="otherconsiderations" title="Other Consideraitons">		toc="include" pn="section-3.3">
	<t>The following considerations are desirable, but not as		<name slugifiedName="name-other-considerations">Other Considerations</na
	important as the preceding requirements, and thus should not be		me>
	traded off for them.		<t pn="section-3.3-1">The following considerations are desirable, but th
	</t>		ey are not as
	<t>		important as the preceding requirements and thus should not be
	<list style="symbols">		traded-off for them.
	<t>We have something of a preference for an IETF meeting to		</t>
	be under "One Roof". That		<ul spacing="normal" bare="false" empty="false" pn="section-3.3-2">
	is, qualified meeting space and guest rooms are available in the		<li pn="section-3.3-2.1">We have something of a preference for an IETF
	same facility.</t>		meeting to
	<t>It is desirable for Overflow Hotels to provide reasonable,		be under "One Roof"; that is, qualified meeting space and guest room
			s are available in the
			same facility.</li>
			<li pn="section-3.3-2.2">It is desirable for Overflow Hotels to provid
			e 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 pn="section-3.3-2.3">It is desirable to enter into a multi-event c
			ontract 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 pn="section-3.3-2.4">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>		</section>
	</t>
	</section>
	</section>		</section>
	<section title="Documentation Requirements">		<section numbered="true" removeInRFC="false" toc="include" pn="section-4">
	<t>The IETF Community works best when it is well informed. This		<name slugifiedName="name-documentation-requirements">Documentation Requir
			ements</name>
			<t pn="section-4-1">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 IASA <bcp14>SHALL</bcp14> pub licly
	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 anchor="IANA" title="IANA Considerations">
	<t>This memo asks the IANA for no new parameters.</t>
	<t>[The RFC-Editor may remove this section prior to publicaiton.]</t>
	</section>		</section>
			<section anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn=
	<section anchor="Security" title="Security Considerations">		"section-5">
	<t>This note proposes no protocols, and therefore no new protocol		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
			<t pn="section-5-1">This document has no IANA actions.</t>
			</section>
			<section anchor="Security" numbered="true" removeInRFC="false" toc="include"
			pn="section-6">
			<name slugifiedName="name-security-considerations">Security Considerations
			</name>
			<t pn="section-6-1">This note proposes no protocols and therefore introduc
			es no new protocol
	insecurities.</t>		insecurities.</t>
	</section>		</section>
			<section anchor="Privacy" numbered="true" removeInRFC="false" toc="include"
	<section anchor="Privacy" title="Privacy Considerations">		pn="section-7">
	<t>Different places have different constraints on individual		<name slugifiedName="name-privacy-considerations">Privacy Considerations</
			name>
			<t pn="section-7-1">Different places have different constraints on individ
			ual
	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 IASA <bcp14>SHALL</bcp14> inform the IETF 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 pn="section-8">
	<references title="Normative References">		<name slugifiedName="name-normative-references">Normative References</name
	&RFC2119;		>
	&RFC8174;		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc211
	<reference anchor="RFC4071"		9" quoteTitle="true" derivedAnchor="RFC2119">
	target="http://www.rfc-editor.org/info/rfc4071">
	<front>		<front>
	<title>Structure of the IETF Administrative Support Activity		<title>Key words for use in RFCs to Indicate Requirement Levels</title
	(IASA)</title>		>
	<author fullname="R. Austein" initials="R." role="editor"		<author initials="S." surname="Bradner" fullname="S. Bradner">
	surname="Austein">		<organization showOnFrontPage="true"/>
	<organization />
	</author>		</author>
	<author fullname="B. Wijnen" initials="B." role="editor"		<date year="1997" month="March"/>
	surname="Wijnen">		<abstract>
	<organization />		<t>In many standards track documents several words are used to signi
			fy the requirements in the specification. These words are often capitalized. Th
			is document defines these words as they should be interpreted in IETF documents.
			This document specifies an Internet Best Current Practices for the Internet Co
			mmunity, and requests discussion and suggestions for improvements.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="2119"/>
			<seriesInfo name="DOI" value="10.17487/RFC2119"/>
			</reference>
			<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc817
			4" quoteTitle="true" derivedAnchor="RFC8174">
			<front>
			<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</titl
			e>
			<author initials="B." surname="Leiba" fullname="B. Leiba">
			<organization showOnFrontPage="true"/>
	</author>		</author>
	<date month="April" year="2005" />		<date year="2017" month="May"/>
	<abstract>		<abstract>
	<t>This document describes the structure of the IETF Administrative		<t>RFC 2119 specifies common key words that may be used in protocol
	Support Activity (IASA) as an activity housed within the Internet		specifications. This document aims to reduce the ambiguity by clarifying that
	Society (ISOC). It defines the roles and responsibilities of the		only UPPERCASE usage of the key words have the defined special meanings.</t>
	IETF Administrative Oversight Committee (IAOC), the IETF
	Administrative Director (IAD), and ISOC in the fiscal and
	administrative support of the IETF standards process. It also
	defines the membership and selection rules for the IAOC. This
	document specifies an Internet Best Current Practices for the
	Internet Community, and requests discussion and suggestions for
	improvements.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="BCP" value="101" />		<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="4071" />		<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC4071" />		<seriesInfo name="DOI" value="10.17487/RFC8174"/>
			</reference>
			<reference anchor="RFC8719" target="https://www.rfc-editor.org/info/rfc871
			9" quoteTitle="true" derivedAnchor="RFC8719">
			<front>
			<title>High-Level Guidance for the Meeting Policy of the IETF</title>
			<author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="February" year="2020"/>
			</front>
			<seriesInfo name="BCP" value="226"/>
			<seriesInfo name="RFC" value="8719"/>
			<seriesInfo name="DOI" value="10.17487/RFC8719"/>
	</reference>		</reference>
	&I-D.ietf-mtgvenue-meeting-policy;
	</references>		</references>
	<references title="Informative References">		<references pn="section-9">
	&RFC3935;		<name slugifiedName="name-informative-references">Informative References</
	&RFC6771;		name>
			<reference anchor="RFC3935" target="https://www.rfc-editor.org/info/rfc393
			5" quoteTitle="true" derivedAnchor="RFC3935">
			<front>
			<title>A Mission Statement for the IETF</title>
			<author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2004" month="October"/>
			<abstract>
			<t>This memo gives a mission statement for the IETF, tries to define
			the terms used in the statement sufficiently to make the mission statement unde
			rstandable and useful, argues why the IETF needs a mission statement, and tries
			to capture some of the debate that led to this point. This document specifies a
			n Internet Best Current Practices for the Internet Community, and requests discu
			ssion and suggestions for improvements.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="95"/>
			<seriesInfo name="RFC" value="3935"/>
			<seriesInfo name="DOI" value="10.17487/RFC3935"/>
			</reference>
			<reference anchor="RFC6771" target="https://www.rfc-editor.org/info/rfc677
			1" quoteTitle="true" derivedAnchor="RFC6771">
			<front>
			<title>Considerations for Having a Successful "Bar BOF" Side Meeting</
			title>
			<author initials="L." surname="Eggert" fullname="L. Eggert">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Camarillo" fullname="G. Camarillo">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2012" month="October"/>
			<abstract>
			<t>New work is typically brought to the IETF by a group of intereste
			d individuals. IETF meetings are a convenient place for such groups to hold inf
			ormal get-togethers to discuss and develop their ideas. Such side meetings, whi
			ch are not reflected in the IETF meeting agenda and have no official status, are
			often half-jokingly referred to as "bar BOF" sessions to acknow
			ledge that some of them may eventually lead to a proposal for an official IETF B
			OF ("birds of a feather" session) on a given topic.</t>
			<t>During recent IETF meetings, many such "bar BOF" get-togethers ha
			ve been organized and moderated in ways that made them increasingly indistinguis
			hable from official IETF BOFs or sometimes even IETF working group meetings.</t>
			<t>This document argues that this recent trend is not helpful in rea
			ching the ultimate goal of many of these get-togethers, i.e., to efficiently dis
			cuss and develop ideas for new IETF work. It encourages the organizers to consi
			der the benefits of holding them in much less formal settings and to also consid
			er alternative means to develop their ideas. This document also recommends that
			the community abandon the term "bar BOF" and instead use other terms such as "s
			ide meeting", in order to stress the unofficial nature of these get-togethers.
			This document is not an Internet Standards Track specification; it is published
			for informational purposes.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6771"/>
			<seriesInfo name="DOI" value="10.17487/RFC6771"/>
			</reference>
			<reference anchor="RFC8711" target="https://www.rfc-editor.org/info/rfc871
			1" quoteTitle="true" derivedAnchor="RFC8711">
			<front>
			<title>Structure of the IETF Administrative Support Activity, Version
			2.0</title>
			<author initials="B." surname="Haberman">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Hall">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Livingood">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="February" 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">		<section anchor="Acknowledgements" numbered="false" removeInRFC="false" toc=
	<t>[RFC Editor: Please remove this section prior to publication.]</t>		"include" pn="section-appendix.a">
	<t>		<name slugifiedName="name-acknowledgements">Acknowledgements</name>
	<list style="hanging">		<t pn="section-appendix.a-1">Contributions came from <contact fullname="Ja
	<t hangText="2016-01-12:">Initial version</t>		ri Arkko"/>, <contact fullname="Scott Bradner"/>,
	<t hangText="2016-01-21:">Update to reflect		<contact fullname="Alissa Cooper"/>, <contact fullname="Dave Crocker"/>
	https://iaoc.ietf.org/documents/VenueSelectionCriteriaJan2016.pdf		, <contact fullname="Jordi Palet Martinez"/>, <contact fullname="Andrew
	and		Sullivan"/>, and other participants in the MTGVENUE Working
	https://iaoc.ietf.org/documents/VenueSelectionProcess11Jan16.pdf,		Group. Those listed in this section or as contributors may or
	accessed from		may not agree with the content of this memo.</t>
	https://iaoc.ietf.org/private/privatemeetings.html.</t>		</section>
	<t hangText="2016-02-23:">Reorganize and capture IAOC Meetings		<section anchor="Contributors" numbered="false" removeInRFC="false" toc="inc
	Committee discussions.</t>		lude" pn="section-appendix.b">
	<t hangText="2016-03-03:">Final from Design Team.</t>		<name slugifiedName="name-contributors">Contributors</name>
	<t hangText="2016-03-17:">First update incorporating mtgvenue@ietf.org		<t pn="section-appendix.b-1">The following people provided substantial tex
	comments</t>		t contributions
	<t hangText="2016-05-20">Updated in accordance with editing by Laura		to this memo. Specifically, Fred Baker originated this work.
	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 showOnFrontPage="true">Association Management Solutions</o
			rganization>
			<address>
			<email>lnugent@amsl.com</email>
			</address>
			</contact>
			<contact fullname="Lou Berger">
			<organization showOnFrontPage="true">LabN Consulting, L.L.C.</organizati
			on>
			<address>
			<email>lberger@labn.net</email>
			</address>
			</contact>
			<contact fullname="Ole Jacobsen">
			<organization showOnFrontPage="true">The Internet Protocol Journal</orga
			nization>
			<address>
			<email>olejacobsen@me.com</email>
			</address>
			</contact>
			<contact fullname="Jim Martin">
			<organization showOnFrontPage="true">INOC</organization>
			<address>
			<email>jim@inoc.com</email>
			</address>
			</contact>
			</section>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.c">
			<name slugifiedName="name-authors-address">Author's Address</name>
			<author initials="E." surname="Lear" fullname="Eliot Lear" role="editor">
			<organization showOnFrontPage="true">Cisco Systems</organization>
			<address>
			<postal>
			<street>Richtistrasse 7</street>
			<city>Wallisellen</city>
			<code>CH-8304</code>
			<country>Switzerland</country>
			</postal>
			<phone>+41 44 878 9200</phone>
			<email>lear@cisco.com</email>
			</address>
			</author>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 76 change blocks.
	510 lines changed or deleted		764 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/