<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<rfc number="8718" category="bcp" ipr="trust200902" submissionType="IETF"
     seriesNo="226" consensus="true" xml:lang="en" tocInclude="true"
     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>
    <title abbrev="Venue Selection">IETF Plenary Meeting Venue Selection
      Process</title>
<seriesInfo name="RFC" value="8718" />
<seriesInfo name="BCP" value="226"/>
    <author initials="E." surname="Lear" fullname="Eliot Lear" role="editor">
      <organization>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>

    <date month="February" year="2020" />
    <area>General</area>
    <workgroup>Meeting Venue Working Group</workgroup>
    <keyword>Meeting Venues</keyword>
    <keyword>Meeting selection process</keyword>
    <keyword>IASA</keyword>
    <abstract>
      <t>
      The IETF Administration Support Activity (IASA) is responsible
      for arranging the selection and operation of the IETF plenary meeting
      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>
  </front>

  <middle>

    <section anchor="Introduction" title="Introduction">
      <t>The IETF Administrative Support Activity (IASA) <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 IASA in their selection of regions, cities, 
        facilities, and hotels.  The IASA should apply this guidance at
        different points in the process in an attempt to faithfully
        meet the requirements of the IETF community.  We specify a set
        of general criteria for venue selection and several requirements for
	transparency and community consultation.</t>

<t>It remains the responsibility of the IASA to apply their best judgment. The
IASA accepts input and feedback during the consultation process and later (for
instance, when there are changes in the situation at a chosen location).
The community is encouraged to provide direct feedback about the IASA's
performance to the IETF Administration LLC, the Nominations Committee (NOMCOM),
or the Internet Engineering Steering Group (IESG). Any reviews of IASA
decisions remain subject to the provisions of <xref target="RFC8711"
section="4.7" sectionFormat="of"/> (BCP 101).
</t>
      <t>The following four terms describe the places for which the IETF contracts
          services:</t>
	  <dl newline="true">
          <dt>Venue:</dt><dd>An umbrella term for the
            city, meeting resources, and guest room resources.</dd>
	  <dt>Facility:</dt><dd>The building that houses
            meeting rooms and associated resources. It may also
            house an IETF Hotel.</dd>
          <dt>IETF Hotels:</dt><dd>One or more hotels, in close
            proximity to the Facility, where the IETF guest room block
            allocations are
            negotiated and where network services managed by the IASA
            (e.g., the "IETF" SSID) are in use.</dd>
	  <dt>Overflow Hotels:</dt><dd>One or more
            hotels, usually in close proximity to the Facility,
            where the IETF has negotiated a group room rate for the purposes of
            the meeting.  Of particular note is that Overflow Hotels
            are not usually connected to the IETF network and do not
            use network services managed by the IASA.</dd>
	  </dl>

        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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>

    </section>

    <section anchor="objectives" title="Venue Selection Objectives">
      <section anchor="core" title="Core Values">
        <t>Some IETF values pervade the selection process. These are often
          applicable to multiple requirements listed in this document. At a
	  minimum, they include the following:</t>
	  <dl newline="true">
	    <dt>Why we meet:</dt>
	    <dd>We meet to pursue the IETF's
              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
              cross-pollination of ideas and technologies.</dd>

            <dt>Inclusiveness:</dt>
	    <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
              diversity of perspectives represented in the 
              working sessions.</t>
	      <t>Every country has limits on who it will permit within its
	      borders. However, the IETF seeks to:</t>

	    <ol>
            <li>Minimize situations in which onerous entry regulations
                  inhibit, discourage, or prevent participants from
                  attending meetings; failing that, meeting locations are to
		  be distributed such that onerous entry
                  regulations are not always experienced by the same
                  attendees; and</li>
                <li>Avoid meeting in countries with laws that effectively exclude
                  people on the basis of race, ethnicity, religion, gender, sexual
                  orientation, national origin, citizenship, or gender
                  identity.</li>
            </ol>
	    </dd>

            <dt>Where we meet:</dt>
	    <dd>We meet in different
              global locations, in order to spread the difficulty and cost of
              travel among active participants, balancing travel time and
              expense across participants based in various regions.  Our
	      regional location policy is articulated in
              <xref target="RFC8719" />.</dd>

            <dt>Internet Access:</dt>
	    <dd>As an organization, we
              write specifications for the Internet, and we use it heavily.
              Meeting attendees need unfiltered access to the general Internet
              and their corporate networks.  "Unfiltered access", in this
              case, means that all forms of communication are allowed.
              This includes, but is not limited to, access to corporate networks
              via encrypted VPNs from the meeting Facility and Hotels, including
              Overflow Hotels. We also need open network access available at
              high enough data rates, at the meeting Facility, to support our
              work, which includes support of remote
              participation. Beyond this, we are the first users of
              our own technology. Any filtering may cause a problem
              with that technology development.  In some cases,
              local laws may require some filtering.  We seek to
              avoid such locales without reducing the
              pool of cities to an unacceptable level by stating a
              number of criteria below, one mandatory and others
              important, to allow for the case where local laws may
              require filtering in some circumstances.</dd>

	    <dt>Focus:</dt>
	    <dd>We meet to have focused
              technical discussions. These are not limited to
              scheduled breakout sessions, although of course those
              are important. They also happen over meals or drinks,
              through a specific type of non-session that we call a
              "Bar BOF", or in side meetings. Environments that are
              noisy or distracting prevent or reduce the
              effectiveness of these sessions and are therefore less desirable as a
              meeting Facility <xref target="RFC6771" />.</dd>

	    <dt>Economics:</dt>
	    <dd>Meeting attendees participate as
              individuals. While many are underwritten by employers or sponsors,
              many are self-funded. In order to reduce participation costs and
              travel effort, we therefore seek locations that provide convenient
              budget alternatives for food and lodging, and that minimize
              travel segments from major airports to the Venue. Within reason,
              one's budget should not be a barrier to accommodation.</dd>

	      <dt>Least Astonishment and Openness:</dt>
              <dd>Regular participants
              should not be surprised by meeting Venue selections, particularly
              when it comes to locales. To avoid surprise, the venue
              selection process, as with all other IETF processes,
              should be as open as practicable.  It should be possible
              for the community to engage in discussion early to express its views
              on prospective selections, so that the community and the
              IASA can exchange views as to appropriateness long 
              before a venue contract is considered.</dd>
            </dl>
      </section>

      <section anchor="nonobjectives" title="Venue Selection Non-objectives">
        <t>IETF meeting Venues are not selected or declined with the explicit
          purposes of:</t>

	  <dl newline="true">
	    <dt>Politics:</dt><dd>Endorsing or condemning
              particular countries, political paradigms, laws, regulations, or
              policies.</dd>

            <dt>Maximal attendance:</dt><dd>While the IETF strives to be as inclusive as possible,
              both online and in person, maximal
              meeting attendance in and of itself is not a goal. It
              would defeat a key goal of meeting if
              active contributors with differing
              points of view did not have the opportunity to resolve their
              disagreements, no matter how full the rooms.</dd>

            <dt>Tourism:</dt><dd>Variety in site-seeing
              experiences.</dd>
	  </dl>
      </section>

    </section>
    <section anchor="criteria" title="Meeting Criteria">
      <t>This section contains the criteria for IETF meetings.  It is
      broken down into three subsections: <xref target="mandatories">mandatory criteria</xref>,
      <xref target="importants">important criteria </xref>, and <xref target="otherconsiderations">other considerations</xref>, each as explained
      below.
      </t>
    <section anchor="mandatories" title="Mandatory Criteria">
     <t>If criteria in this subsection cannot be met, a particular
       location is unacceptable for selection, and the IASA <bcp14>MUST NOT</bcp14> 
       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
       matter on a case-by-case basis.</t>

       <ul spacing="normal">
       <li>The Facility <bcp14>MUST</bcp14> provide sufficient
         space in an appropriate layout to accommodate the 
         number of participants, leadership, and support staff expected to
         attend that meeting.</li>
       <li>The Facility and IETF Hotels <bcp14>MUST</bcp14> provide wheelchair access
	 to accommodate the number of people who are anticipated to
	 require it.</li>
       <li>It <bcp14>MUST</bcp14> be possible to provision
	 Internet Access to the Facility and IETF Hotels that allows
	 those attending in person to utilize the Internet for all their IETF,
	 business, and day-to-day needs; in addition, there must be sufficient
	 bandwidth and access for remote attendees. 
Provisions include, but are not
	 limited to, native and unmodified IPv4 and IPv6 connectivity,
	 and global reachability; there may be no additional limitation that would 
	 materially impact their Internet use. To ensure availability,
	 it <bcp14>MUST</bcp14> be possible to provision redundant paths to the
	 Internet.</li>
       </ul>

    </section>

    <section anchor="importants" title="Important Criteria">
      <t>The criteria in this subsection are not mandatory,
              but they are still highly significant. It may be necessary to
              trade-off one or more of these criteria against others.
              A Venue that meets more of these criteria is, on the
              whole, preferable to another that meets fewer of
              these criteria. Requirements classed as Important can
              also be balanced across Venue selections for multiple
              meetings. When a particular requirement in this section
              cannot be met but the Venue is selected anyway, the IASA <bcp14>MUST</bcp14> notify the community at the
              time of the venue announcement.  Furthermore, it may be
              appropriate for the IASA to assist those who, as a
              result, have been inconvenienced in some way.
      </t>
        <section title="Venue City Criteria">
	<t>The following requirements relate to the Venue city.</t>
	<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
            that the burden borne will generally be shared over the course of
            multiple years.</li>
          <li>The Venue is assessed as favorable for obtaining a host and
            sponsors. That is, the Meeting is in a location in which
            it is possible and probable to find a host and sponsors. </li>
	  <li>Travel barriers to entry, including visa requirements, are
	    likely to be such that an overwhelming majority of
	    participants who wish to do so can attend.  The term "travel
	    barriers" is to be read 
	    broadly by the IASA in the context of whether a
	    successful meeting can be had.</li>
          <li>Economic, safety, and health risks associated with this Venue are
            acceptable. </li>
	  <li>The selection of the venue comports with the practices described in
              <xref target="RFC8719" />.
	  </li>
	  </ul>
	</section>

	<section title="Basic Venue Criteria">
	<t>The following requirements relate to the Venue and Facilities.</t>

        <t>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
          local health, safety, and accessibility laws and regulations,
          and that they will remain in compliance throughout our stay.
	</t>
        <t>In addition:</t>

	<ul spacing="normal">
	  <li>There are sufficient places (e.g., a mix of hallways, bars, meeting
	    rooms, and restaurants) for people to hold ad hoc
	    conversations and group discussions in the combination of
	    spaces offered by the facilities, hotels, and
	    bars/restaurants in the surrounding area, within walking
	    distance (5-10 minutes).</li>
          <li>The cost of guest rooms, meeting space, meeting food and beverage
            is affordable, within the norms of business travel.</li>
          <li>The Facility is accessible, or
	  reasonable accommodations can be made to allow access, by people with
	  disabilities. </li>
	</ul>
	</section>

	<section title="Technical Meeting Needs">
	<t>The following criteria relate to technical meeting needs.</t>

	<ul spacing="normal">
          <li>The Facility's support technologies and services -- network,
            audio-video, etc. -- are sufficient for the anticipated activities
            at the meeting, or the Facility is willing to add such
            infrastructure, or these support technologies and services might be
            provided by a third party, all at no -- or at an acceptable -- cost
            to the IETF.</li>

          <li>The IETF Hotels directly provide, or else permit and facilitate,
            the delivery of a high performance, robust, unfiltered, and
            unmodified Internet service for the public areas and guest
            rooms; this service is to be included in the cost of
            the room.</li>
	</ul>
	</section>

	<section title="Hotel Needs">
	<t>The following criteria relate to IETF Hotels.</t>

	<ul spacing="normal">
          <li>The IETF Hotels are within close proximity to each other and the
            Facility.</li>
          <li>The guest rooms at the IETF Hotels are sufficient in number to
            house one-third or more of projected meeting attendees.</li>
          <li>Overflow Hotels can be placed under contract, within convenient
            travel time to and from the Facility and at a variety of guest room
            rates.</li>
          <li>The Facility environs include budget hotels within convenient travel
            time, cost, and effort.</li>
          <li>The IETF Hotels are accessible by people with disabilities.
          While we mandate wheelchair accessibility, other forms are
          important and should be provided for to the extent possible
          based on anticipated needs of the community.</li>
          <li>At least one IETF Hotel or the Facility has a space for use as a
	  lounge, conducive to planned and ad hoc meetings and chatting, as well
            as a space for working online. There are tables with seating, convenient for
            small meetings with laptops. These can be at an open bar or casual
            restaurant. Preferably the lounge area is centrally
            located, permitting easy access to participants.</li>
	</ul>
	</section>

	<section title="Food and Beverage">
	<t>The following criteria relate to food and
	beverage.</t>
	<ul spacing="normal">
          <li>The Facility environs, which include both on-site as well as areas
            within a reasonable walking distance or conveniently
            accessible by a short taxi ride or by local
            public transportation, have convenient and inexpensive
            choices for meals that can accommodate a wide range of dietary
            requirements.</li>
          <li>A range of attendees' health-related and religion-related dietary
            requirements can be satisfied with robust and flexible on-site
            service or through access to an adequate grocery store.</li>
          <li>The Facility environs include grocery shopping that will accommodate a
            wide range of dietary requirements, within a reasonable walking
            distance or conveniently accessible by a short taxi, bus, or subway
            ride from the Facility and IETF Hotels.</li>
	</ul>
	</section>
    </section>

    <section anchor="otherconsiderations" title="Other Considerations">
      <t>The following considerations are desirable, but they are not as
      important as the preceding requirements and thus should not be
      traded-off for them.
      </t>
      <ul spacing="normal">
          <li>We have something of a preference for an IETF meeting to
            be under "One Roof"; that is, qualified meeting space and guest rooms are available in the
            same facility.</li>
          <li>It is desirable for Overflow Hotels to provide reasonable,
            reliable, unfiltered Internet service for the public areas
            and guest rooms, and for this service be included in the
            cost of the room.</li> 
	  <li>It is desirable to enter into a multi-event contract with the
	    Facility and IETF Hotels or associated hotel chains in
	    case such a contract will reduce 
	    administrative costs, reduce direct attendee costs, or both.</li>
	  <li>When we are considering a city for the first
	    time, it is particularly desirable to have someone familiar with
	    both the locale and the IETF participate in the site
	    visit. Such a person can provide guidance 
	    regarding safety, location of local services, 
	    the best ways to get to and from the Venue, and
	    local customs, as well as how our requirements are
	    met.</li>
	    </ul>
    </section>
    </section>

    <section title="Documentation Requirements">
      <t>The IETF Community works best when it is well informed.  This
      memo does not specify processes nor who has responsibility for
      fulfilling our requirements for meetings.  Nevertheless, both of
      these aspects are important.  Therefore, the IASA <bcp14>SHALL</bcp14> publicly
      document and keep current both a list of roles and
      responsibilities relating to IETF meetings, as well as the
      selection processes they use in order to fulfill the
      requirements of the community.
	</t>
      </section>
	
    <section anchor="IANA" title="IANA Considerations">
      <t>This document has no IANA actions.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This note proposes no protocols and therefore introduces no new protocol
        insecurities.</t>
    </section>

    <section anchor="Privacy" title="Privacy Considerations">
      <t>Different places have different constraints on individual
	privacy.  The requirements in this memo are intended to
	provide for some limited protections.
	As meetings are announced, the IASA <bcp14>SHALL</bcp14> inform the IETF of
	any limitations to privacy they have become aware of in their
	investigations.  For example, participants would be informed
	of any regulatory authentication or logging requirements.</t>
    </section>

  </middle>

  <back>

    <references title="Normative References">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>


<reference anchor="RFC8719" target="https://www.rfc-editor.org/info/rfc8719">
<front>
<title>High-Level Guidance for the Meeting Policy of the IETF</title>
<author initials='S.' surname='Krishnan' fullname='Suresh Krishnan'>
  <organization/>
</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>
    </references>

    <references title="Informative References">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3935.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6771.xml"/>

<reference anchor="RFC8711" target="https://www.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="February" year="2020"/>
  </front>
  <seriesInfo name="BCP" value="101"/>
  <seriesInfo name="RFC" value="8711"/>
  <seriesInfo name="DOI" value="10.17487/RFC8711"/>
</reference>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements" numbered="false">
      <t>Contributions came from <contact fullname="Jari Arkko"/>, <contact
      fullname="Scott Bradner"/>,
        <contact fullname="Alissa Cooper"/>, <contact fullname="Dave
	Crocker"/>, <contact fullname="Jordi Palet Martinez"/>, <contact fullname="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>

    <section anchor="Contributors" title="Contributors" numbered="false">
      <t>The following people provided substantial text contributions
	to this memo. Specifically, Fred Baker originated this work.
      </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>

  </back>
</rfc>
