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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM
	 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM
	 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC3935 SYSTEM
	 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3935.xml">
<!ENTITY RFC6771 SYSTEM
	 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6771.xml">
<!ENTITY I-D.ietf-mtgvenue-meeting-policy SYSTEM
	 "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mtgvenue-meeting-policy.xml">

]>
<?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" ?> "rfc2629-xhtml.ent">

<rfc number="8718" category="bcp"
  docName="draft-ietf-mtgvenue-iaoc-venue-selection-process-16" ipr="trust200902" submissionType="IETF" updates="" xml:lang="en">
     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="January" year="2020" />
    <area>General</area>
    <workgroup>mtgvenue</workgroup>
    <workgroup>Meeting Venue Working Group</workgroup>
    <keyword>Meeting Venues</keyword>
    <keyword>Meeting selection process</keyword>
    <keyword>IASA</keyword>
    <abstract>
      <t>The IASA has responsibility
      <t>
      The IETF Administration LLC (IETF LLC) is responsible
      for arranging the selection and operation of the IETF plenary meeting Venue
        selection and operation.
      venue. This memo specifies IETF community
      requirements for meeting venues, including hotels and meeting
        room
      space.  It also directs the IASA IETF LLC to make available additional
      process documents that describe the current meeting
      selection process.</t>
    </abstract>
  </front>

  <middle>

    <section anchor="Introduction" title="Introduction">
<!-- [rfced] Note that we changed instannces of "the LLC" to "the IETF LLC"
for consistency with other documents in this cluster.  Please let us know any
objections.
-->
      <t>The Internet Administrative Support Activity (IASA) has
        responsibility IETF Administration LLC (IETF LLC) <xref target="RFC8711"/> is
        responsible for arranging the selection and operation of the IETF
	plenary meeting venue
        selection and operation. venue.  The purpose of this document is to
        guide the IASA IETF LLC in their selection of regions, cities,
        facilities, and hotels.  The IASA applies IETF LLC 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

<t>    It remains the responsibility of the IASA IETF LLC to apply their best
        judgment. The IASA IETF LLC accepts input and feedback both during the
        consultation process and later (for instance instance, when there are
        changes in the situation at a chosen location). Any appeals remain subject to
	the provisions of <xref target="RFC4071">BCP101</xref>. As
        always, the community is encouraged to provide direct feedback
        to the IETF LLC Board about their performance as well as to the
        Nominations Committee (NOMCOM), the Internet Engineering Steering
        Group (IESG), and IAB regarding the discharge ISOC Board of Trustees, from which the IASA's
	performance.
        IETF LLC Board is constructed.
</t>
      <t>Four
      <t>The following four terms describe the places for which the IETF contracts
          services:<list style="hanging">
          <t hangText="Venue:  "><vspace />This is an
          services:</t>
	  <dl newline="true">
          <dt>Venue:</dt><dd>An umbrella term for the
            city, meeting resources resources, and guest room resources.
	  </t>
          <t hangText="Facility:  "><vspace />The resources.</dd>
	  <dt>Facility:</dt><dd>The building that houses
            meeting rooms and associated resources. It may also
            house an IETF Hotel.
	  </t>
          <t hangText="IETF Hotels:  "><vspace />One 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 IETF LLC
            (e.g., the "IETF" SSID) are in use.</t>
	  <t hangText="Overflow Hotels: "><vspace />One 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
            usually
            are not usually connected to the IETF network and do not
            use network services managed by the IASA.</t>
        </list></t> IETF LLC.</dd>
	  </dl>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
   BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <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 often are often
          applicable to multiple requirements listed in this document. They are
          not limited to At a
	  minimum, they include the following, but at minimum include: <list
            style="hanging">
            <t hangText="Why following:</t>
	  <dl newline="true">
	    <dt>Why we meet?"><vspace />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.</t>

            <t hangText="Inclusiveness:"><vspace />We technologies.</dd>

            <dt>Inclusiveness:</dt>
	    <dd><t>We would like to facilitate
              the onsite 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> sessions.</t>
	      <t>Every country has limits on who it will permit within its
	      borders. However However, the IETF seeks to: <list style="numbers">
                <t>Minimize to:</t>

	    <ol>
            <li>Minimize situations in which onerous entry regulations
                  inhibit, discourage, or prevent participants from
                  attending meetings, or meetings; failing that
                  to distribute that, meeting locations are to
		  be distributed such that onerous entry
                  regulations are not always experienced by the same
                  attendees; and</t>
                <t>Avoid 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.</t>
              </list></t>

            <t hangText="Where
                  identity.</li>
            </ol>
	    </dd>

            <dt>Where we meet:"><vspace />We meet:</dt>
	    <dd>We meet in different
              locations globally,
              global locations, in order to spread the difficulty and cost of
              travel among active participants, balancing travel time and
              expense across the regions in which participants are
              based. based in various regions.  Our
	      regional location policy is articulated in
              <xref target="I-D.ietf-mtgvenue-meeting-policy" />.
	      </t>

            <t hangText="Internet Access:"><vspace />As 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" access", in this
              case
              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, including the 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.</t>

            <t hangText="Focus:"><vspace />We 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 that or reduce its
              effectiveness, the
              effectiveness of these sessions and are therefore less desirable as a
              meeting Facility.<xref Facility <xref target="RFC6771" /></t>

            <t hangText="Economics:"><vspace />Meeting />.</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 which that minimize
              travel segments from major airports to the Venue. Within reason,
              one's budget should not be a barrier to accommodation.</t>

            <t hangText="Least accommodation.</dd>

	      <dt>Least Astonishment and Openness:"><vspace />
              Regular 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
              IETF LLC can exchange views as to appropriateness long
              before a venue contract is considered.</t>
          </list></t> considered.</dd>
            </dl>
      </section>

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

            <t hangText="Politics:  "><vspace />Endorsing of:</t>

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

            <t hangText="Maximal attendance:  "><vspace />
	      While
              policies.</dd>

            <dt>Maximal attendance:</dt><dd>While the IETF strives to be as inclusive as possible 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.
            </t>
            <t hangText="Tourism:  "><vspace />Variety rooms.</dd>

            <dt>Tourism:</dt><dd>Variety in site-seeing
              experiences.</t>
          </list></t>
              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: mandatory criteria,
      important criteria, <xref target="mandatories">mandatory criteria</xref>,
      <xref target="importants">important criteria </xref>, and other considerations, <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 MUST NOT IETF LLC <bcp14>MUST NOT</bcp14>
       enter into a contract.  Should the IASA IETF LLC learn that a location
       can no longer can meet a mandatory requirement after having entered
       into a contract, it will inform the community and address the
       matter on a case by case case-by-case basis.</t>
     <t><list style="symbols">
       <t>The

       <ul spacing="normal">
       <li>The Facility MUST <bcp14>MUST</bcp14> provide sufficient
         space in an appropriate layout to accommodate the expected
         number of participants, leadership, and support staff expected to
         attend that meeting.</t>
       <t>The meeting.</li>
       <li>The Facility and IETF Hotels MUST <bcp14>MUST</bcp14> provide wheelchair access
	 to accommodate the number of people who are anticipated to
	 require it.</t>
       <t>It MUST 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 day-to-day needs; as well as in addition, there must be sufficient
	 bandwidth and access for remote attendees. This includes,
Provisions include, but is are not
	 limited to, native and unmodified IPv4 and IPv6 connectivity,
	 global reachability,
	 and global reachability; there may be no additional limitation that would
	 materially impact their Internet use. To ensure availability,
	 it MUST <bcp14>MUST</bcp14> be possible to provision redundant paths to the
	 Internet.</t>
       </list>
       </t>
	 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
              trade-off one or more of these criteria off against others.
              A Venue that meets more of these criteria is is, on the
              whole
              whole, preferable than 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, met but the Venue is selected anyway, the IASA MUST IETF LLC <bcp14>MUST</bcp14> notify the community at the
              time of the venue announcement.  Furthermore, it may be
              appropriate for the IASA IETF LLC to assist those who, as a
              result, have been inconvenienced in some way.
      </t>
        <section title="Venue City Criteria">
	<t><list style="symbols">
          <t>Travel
	<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 be generally be shared over the course of
            multiple years.</t>
          <t>The years.</li>
          <li>The Venue is assessed as favorable for obtaining a host and
            sponsors. That is, the Meeting is in a location that in which
            it is possible and probable to find a host and sponsors. </t>
	  <t>Travel </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 IETF LLC in the context of whether a
	    successful meeting can be had.</t>
          <t>Economic, had.</li>
          <li>Economic, safety, and health risks associated with this Venue are
            acceptable. </t>
	  <t>The </li>
	  <li>The selection of the venue comports with the practices described in
              <xref target="I-D.ietf-mtgvenue-meeting-policy" target="RFC8719" />.
	  </t>
	  </list>
	</t>
	  </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 SHALL meetings <bcp14>SHALL</bcp14>
	  have provided written assurance that they are in compliance with
          local health, safety safety, and accessibility laws and regulations,
          and that they will remain in compliance throughout our stay.
	</t>
        <t>In addition:</t>
	<t>
	  <list style="symbols">
	  <t>There

	<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 hotels, and
	    bars/restaurants in the surrounding area, within walking
	    distance (5-10 minutes).</t>
          <t>The minutes).</li>
          <li>The cost of guest rooms, meeting space, meeting food and beverage
            is affordable, within the norms of business travel.
	  </t>
          <t>The travel.</li>
          <li>The Facility is accessible accessible, or
	  reasonable accommodations can be made to allow access access, by people with
	  disabilities.
	    </t>
	  </list>
	</t> </li>
	</ul>
	</section>

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

	<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
            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.</t>

          <t>The IETF.</li>

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

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

	<ul spacing="normal">
          <li>The IETF Hotel(s) Hotels are within close proximity to each other and the
            Facility.</t>
          <t>The
            Facility.</li>
          <li>The guest rooms at the IETF Hotel(s) Hotels are sufficient in number to
            house 1/3 one-third or more of projected meeting attendees.</t>
          <t>Overflow 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.</t>
          <t>The
            rates.</li>
          <li>The Facility environs include budget hotels within convenient travel
            time, cost, and effort.</t>
          <t>The effort.</li>
          <li>The IETF Hotel(s) Hotels are accessible by people with disabilities.
          While we mandate wheelchair accessibility, other forms are
          important,
          important and should be provided for to the extent possible, possible
          based on anticipated needs of the community.</t>
          <t>At 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.</t>
	  </list>
	</t> participants.</li>
	</ul>
	</section>

	<section title="Food and Beverage">
	<t>The following criteria relate to food and
	beverage.</t>
	<t>
	<list style="symbols">
          <t>The
	<ul spacing="normal">
          <li>The Facility environs, which includes include both onsite, 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.</t>
          <t>A
            requirements.</li>
          <li>A range of attendee's attendees' health-related and religion-related dietary
            requirements can be satisfied with robust and flexible onsite on-site
            service or through access to an adequate grocery.</t>
          <t>The grocery store.</li>
          <li>The Facility environs include grocery shopping that will accommodate a
            wide range of dietary requirements, within a reasonable walking
            distance,
            distance or conveniently accessible by a short taxi, bus, or subway
            ride,
            ride from the Facility and IETF Hotels.</t>
	  </list>
	</t> Hotels.</li>
	</ul>
	</section>
    </section>

    <section anchor="otherconsiderations" title="Other Consideraitons"> Considerations">
      <t>The following considerations are desirable, but they are not as
      important as the preceding requirements, requirements and thus should not be
      traded off
      traded-off for them.
      </t>
      <t>
      <list style="symbols">
          <t>We
      <ul spacing="normal">
          <li>We have something of a preference for an IETF meeting to
            be under "One Roof". That Roof"; that is, qualified meeting space and guest rooms are available in the
            same facility.</t>
          <t>It facility.</li>
          <li>It is desirable for Overflow Hotels to provide reasonable,
            reliable, unfiltered Internet service for the public areas
            and guest rooms, and that for this service be included in the
            cost of the room.</t>
	  <t>It 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 either reduce
	    administrative costs, reduce direct attendee costs, or both.</t>
	  <t>Particularly when both.</li>
	  <li>When we are considering a city for the first
	    time, it is particularly desirable to have someone participate in the site
	    visit who is familiar with
	    both the locale and the IETF. IETF participate in the site
	    visit. Such a person can provide guidance
	    regarding safety, location of local services, and
	    understanding
	    the best ways to get to and from the Venue, and
	    local customs, as well as identify how our requirements are
	    met.
	  </t>
      </list>
      </t>
	    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 SHALL IETF LLC <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 memo asks the IANA for document has no new parameters.</t>
      <t>[The RFC-Editor may remove this section prior to publicaiton.]</t> IANA actions.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This note proposes no protocols, 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, IASA SHALL the IETF LLC <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>

    <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>

  <back>
    <!--references split to informative and normative -->
    <references title="Normative References">
      &RFC2119;
      &RFC8174;
<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"/>

<!-- ietf-mtgvenue-meeting-policy -->
<reference anchor="RFC4071"
        target="http://www.rfc-editor.org/info/rfc4071"> anchor="RFC8719" target="https://www.rfc-editor.org/info/rfc8719">
<front>
          <title>Structure
<title>High-Level Guidance for the Meeting Policy of the IETF Administrative Support Activity
            (IASA)</title>
          <author fullname="R. Austein" initials="R." role="editor"
            surname="Austein">
            <organization />
          </author> IETF</title>
<author fullname="B. Wijnen" initials="B." role="editor"
            surname="Wijnen">
            <organization /> initials='S.' surname='Krishnan' fullname='Suresh Krishnan'>
  <organization/>
</author>
<date month="April" year="2005" />
          <abstract>
            <t>This document describes the structure of the IETF Administrative
              Support Activity (IASA) as an activity housed within the Internet
              Society (ISOC). It defines the roles and responsibilities of the
              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> month='January' year='2020'/>
</front>
<seriesInfo name="BCP" value="101" /> value="226"/>
<seriesInfo name="RFC" value="4071" /> value="8719"/>
<seriesInfo name="DOI" value="10.17487/RFC4071" /> value="10.17487/RFC8719"/>
</reference>
      &I-D.ietf-mtgvenue-meeting-policy;

    </references>
    <references title="Informative References">
      &RFC3935;
      &RFC6771;
    </references>
    <section anchor="log" title="Change Log">
      <t>[RFC Editor: Please remove

<!-- [rfced] When this section prior document was initially in AUTH48, we received notice
that a reference to publication.]</t>
      <t>
        <list style="hanging">
          <t hangText="2016-01-12:">Initial version</t>
          <t hangText="2016-01-21:">Update draft-ietf-iasa2-rfc4071bis should be added.  We have
added an informative reference to reflect
            https://iaoc.ietf.org/documents/VenueSelectionCriteriaJan2016.pdf
            and
            https://iaoc.ietf.org/documents/VenueSelectionProcess11Jan16.pdf,
            accessed from
            https://iaoc.ietf.org/private/privatemeetings.html.</t>
          <t hangText="2016-02-23:">Reorganize and capture IAOC Meetings
            Committee discussions.</t>
          <t hangText="2016-03-03:">Final from Design Team.</t>
          <t hangText="2016-03-17:">First update incorporating mtgvenue@ietf.org
            comments</t>
          <t hangText="2016-05-20">Updated in accordance with editing by Laura
            Nugent, Dave Crocker, Lou Berger, Fred Baker, and others.</t>
          <t hangText="posting as working group draft">August 2, 2016</t>
          <t hangText="Reorganized per Alissa Cooper outline">Work in progress. RFC-to-be 8711.  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 we added a
citation where the high-level 'objectives' and LLC is first mentioned in the detailed criteria Introduction.  Please review
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 let us know if any updates are needed.

Notes about including a separate criterion; removed 'acceptable reference 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 draft-ietf-iasa2-rfc4071bis:

- Date: Wed, 12 Dec 2018
Following up 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 our earlier thread, it has become apparent that
draft-ietf-iasa2-rfc4071bis is now needed as proposed by Brian and modified by
	    Jari.  Elaborated on what "unfiltered" means, based on
	    discussion between Eliot and Stephen.  Preface a reference from
draft-ietf-mtgvenue-iaoc-venue-selection-process rather than an earlier draft
that was mentioned.  Barring objections from Alissa, please update your
records for draft-ietf-mtgvenue-iaoc-venue-selection-process to Section
	    5 as discussed between Lou and Stephen.  Slight editorial
	    tweak indicate a
MISSREF to draft-ietf-iasa2-rfc4071bis.

Date: Thu, 14 Mar 2019
Returning to this draft 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 there was some confusion about, I think
draft-ietf-mtgvenue-iaoc-venue-selection-process will need to
	    be more actionable.  Remove net cash
	    positive requirement.  Change many critera from Mandatory reference
draft-ietf-iasa2-rfc4071bis and not draft-ietf-iasa2-struct.  Originally we
were planning to Important.  Remove consensus text.  Modify chapeau.
	    Add some normative MUSTs in Section 5, reference 4071, 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 it was not clear that there would be a mandatory
	    filtering requirement, consolidates introductory text,
	    moves procedural requirements into Section 5, removes
4071bis.  The only reason we’re referencing either of these drafts is that we
are tied to the definition term “IASA”.
-->

    </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://rfc-editor.org/info/rfc8711">
  <front>
    <title>Structure of Headquarters Hotel, removes the MUST in
	    late changes, IETF Administrative Support Activity,
    Version 2.0</title>
    <author initials="B." surname="Haberman">
      <organization/>
    </author>
    <author initials="J." surname="Hall">
      <organization/>
    </author>
    <author initials="J." surname="Livingood">
      <organization/>
    </author>
    <date month="January" year="2020"/>
  </front>
  <seriesInfo name="BCP" value="101"/>
  <seriesInfo name="RFC" value="8711"/>
  <seriesInfo name="DOI" value="10.17487/RFC8711"/>
</reference>
    </references>

    <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 adds a desire for a local participant other participants 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 the MTGVENUE Working
        Group. Those listed in this section or 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 contributors may or
        may not agree with 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 content of meetings
	    committee, Section 4 and 5 moved out.  Also, final LC
	    comments addressed.  In particular: no smoking added.
	    Reference to RFC8174 added.  Reference this memo.</t>
    </section>

    <section anchor="Contributors" title="Contributors" numbered="false">
      <t>The following people provided substantial text contributions
	to meeting policy
	    doc added.
	  </t>
	  <t hangText="2018-05-11">
	    Remove no smoking.
	  </t>
        </list> 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>