<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-cooper-shmo-questions-00" category="info">

  <front>
    <title abbrev="Questions">Questions Arising Concerning In-Person Meeting Cancellation</title>

    <author initials="A." surname="Cooper" fullname="Alissa Cooper">
      <organization>Cisco</organization>
      <address>
        <email>alcoop@cisco.com</email>
      </address>
    </author>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
      <organization>Kaloom</organization>
      <address>
        <email>suresh.krishnan@gmail.com</email>
      </address>
    </author>

    <date />

    <area>General</area>
    
    

    <abstract>


<t>The COVID-19 pandemic has required the IETF community to confront complicated questions about the cancellation and replacement of in-person meetings. This document lists some general questions that have come up for discussion in the community as the IESG, the IRTF Chair, and the IETF LLC have been faced with making decisions about IETF 107 and IETF 108.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The COVID-19 pandemic has required the IETF community to confront complicated questions about the cancellation and replacement of in-person meetings. This document lists some general questions that have come up for discussion as the IESG, the IRTF Chair, and the IETF LLC have been faced with making decisions about whether IETF 107 and IETF 108 should be held as in-person meetings. In many places, inspiration was drawn from <xref target="RFC8718"/> and <xref target="RFC8719"/>.</t>

<t>This document is focused solely on questions concerning in-person meeting cancellation and it intentionally does not address planning for fully online meetings. This document is offered purely to frame discussion, and it is not intended to be published as an RFC.</t>

</section>
<section anchor="questions" title="Questions">

<t><xref target="RFC8719"/> summarized the goal for face-to-face meetings of IETF WGs as mainly to provide a high-bandwidth mechanism for working out unresolved issues.  Historically, these are held in locations from which most of the IETF participants have come in the recent past, with a goal of distributing the travel effort for the participants who attend in person and distributing the timezone difficulty for those who participate remotely.  In the current climate, the IETF leadership, in consultation with the community, needs to determine whether an in-person meeting will be safe and effective.</t>

<section anchor="participation-and-attendance" title="Participation and attendance">

<t>Questions that have come up about participation and attendance include:</t>

<t><list style="numbers">
  <t>Approximately how many in-person attendees are expected? How does this compare to previous in-person meetings in the same region or at the same time of year?</t>
  <t>Approximately how many WGs and RGs expect to have a productive in-person meeting based on their expected participation?</t>
  <t>Approximately how many WG and RG chairs and authors who would normally attend in person are expected to attend? How does this compare to previous in-person meetings in the same region or at the same time of year?</t>
  <t>Which of these measures should be used to assess the viability of an in-person meeting, if any?</t>
  <t>For any of these measures, what threshold of expected in-person attendance justifies going forward with an in-person meeting? A majority? A significant majority? Something else?  Is an in-person meeting with a small (by some definition) number of in-person attendees and a large number of remote attendees viable?</t>
</list></t>

</section>
<section anchor="travel-and-entry" title="Travel and entry">

<t><xref target="RFC8718"/> includes the following criteria related to travel and entry:</t>

<figure><artwork><![CDATA[
   "Travel to the Venue is acceptable based on cost, time, and
   burden for participants traveling from multiple regions.

   "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."
]]></artwork></figure>

<t>Questions that have come up related to travel and entry include:</t>

<t><list style="numbers">
  <t>Should there be meeting cancellation criteria related to travel cost, as there is for venue selection, since travel costs can change in relation to world events?</t>
  <t>Should there be meeting cancellation criteria related to travel availability, since this too can be affected by world events?</t>
  <t>Should the “overwhelming majority” criterion used for venue selection also apply to meeting cancellation criteria concerning entry?</t>
  <t>Should entry requirements related to health assessments of travelers, quarantine, or isolation requirements be factored in to decisions about in-person meeting cancellation, and if so, how? Should these requirements be evaluated both for the country where the meeting is being hosted and for the countries from which attendees are traveling? Is a “reasonable and nondiscriminatory” test appropriate for these kinds of requirements?</t>
  <t>How should corporate travel restrictions play into meeting cancellation decisions, if at all? Should they be evaluated directly using their own specific criteria, or should participation and attendance criteria be used without considering corporate travel restrictions?</t>
</list></t>

</section>
<section anchor="safety-and-health" title="Safety and health">

<t><xref target="RFC8718"/> includes the following criteria related to safety and health:</t>

<figure><artwork><![CDATA[
   "Economic, safety, and health risks associated with this Venue are
   acceptable."
]]></artwork></figure>

<t>Questions related to safety and health have centered around multiple dimensions:</t>

<t><list style="numbers">
  <t>Risks to attendees and others once they are at the venue or in the country where the meeting is taking place. These include getting sick, causing other attendees and staff to become sick, and getting stuck in-country.</t>
  <t>Risks to attendees and others while traveling to the venue. These include getting sick, causing other people to get sick, and being quarantined.</t>
  <t>Risks to attendees and others once they arrive home from the venue. These include getting sick, causing other people to get sick, and being quarantined..</t>
</list></t>

</section>
<section anchor="meeting-host-and-sponsors" title="Meeting host and sponsors">

<t><xref target="RFC8718"/> includes a criterion that says:</t>

<figure><artwork><![CDATA[
   "The Venue is assessed as favorable for obtaining a host and
   sponsors."
]]></artwork></figure>

<t>While communication with IETF 107 and IETF 108 hosts and sponsors has been frequent, criteria related to host and sponsorship availability have not currently been used for determining cancellation plans for IETF 107 and IETF 108. We are thankful for the unconditional support of hosts and sponsors during these uncertain times, but we need to determine whether host and sponsor availability related criteria need to be included in the future.</t>

</section>
<section anchor="venue" title="Venue">

<t>Discussions about IETF 107 and IETF 108 have assumed that the meetings would be cancelled if the venues where the meetings were scheduled to be held were closed or otherwise unable to provide the contracted meeting services. Similarly, if mass gatherings in the venue city or country are banned, then it has been assumed our meetings would be cancelled.</t>

</section>
<section anchor="timing" title="Timing">

<t>Questions have arisen about how far in advance of a meeting a cancellation decision needs to be made. The level of flexibility around this depends on the circumstances, but when there is some flexibility, there has been discussion about whether a cancellation date should be chosen to give participants higher certainty further in advance or to be able to evaluate circumstances as close to the original meeting date as possible, or somewhere in between.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This note proposes no protocols and therefore introduces no new protocol insecurities.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document has no IANA actions.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor="RFC8718" target='https://www.rfc-editor.org/info/rfc8718'>
<front>
<title>IETF Plenary Meeting Venue Selection Process</title>
<author initials='E.' surname='Lear' fullname='E. Lear' role='editor'><organization /></author>
<date year='2020' month='February' />
<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>
<seriesInfo name='BCP' value='226'/>
<seriesInfo name='RFC' value='8718'/>
<seriesInfo name='DOI' value='10.17487/RFC8718'/>
</reference>



<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='S. Krishnan'><organization /></author>
<date year='2020' month='February' />
<abstract><t>This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.</t></abstract>
</front>
<seriesInfo name='BCP' value='226'/>
<seriesInfo name='RFC' value='8719'/>
<seriesInfo name='DOI' value='10.17487/RFC8719'/>
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIAKEbvF4AA+VZTXPcuBG981egtJekamZK9ia1ti6ySrZ3VbtJdiWVfUil
UhgQHGIFElwAnPGsy/7ted0AOaQ0nnzV5hJfzCGBRn+8ft1oLZfLIppo9YU4
+6nXIRrXBnHlTTDtRly7Vmnf0uNNu/xR++Ba8SetI3+U+GitpC1nhVyvvd5e
iFFIUTrVygaCSy+ruFTOddovQ9245S/DouX5eVHKiEUfX1/dv/lUKPzYOL+/
EKatXGE6fyGi70N8fn7+8vx5Ib2WF+Jb3WovbVGEKNvy79K6FiL2OhSduRB/
jU4tRHA+el0FPO2b9ACNGtl1UP5vRSH7WDt/UYhlIfDPtOFCXK1gMqnJr5L2
V9aEIKfvnd9ciGsTlOOfupHGXghpycJXit6vlGv420z67Up85/pg9X4i/rYP
Yfaapb8zG2PFnVa9N3G/ED/8cM0fBy/Pv0/VqJOoV1taEbRiVWZq3K3E94hv
3cp2osdd73Wo519Yle/h3WxNPiLw0tVDXvpqQ6/TOa3zDQCx1RdFQQEcf9H2
27fXL7559mL64yXWLZdL2BWilyoWxX2txfVf3t28Xj57KTpEVzdGiVoG4fUv
vfG6FBFLbt7cvxU4sulbOEBEhx9t5V0b6W1nDQGpFCPQcILrI29VE9wKHADB
nZVKNxqbXQUnLbuE9CYhPazEfW0CwafnRUBEDABYo8UmIXFyUKxlhL5bTYpo
0XcCbhAlYIFI05GmTWqMysuQTbr7dpGebmHcdS2NX7CCo8GAQRK91roVFZQu
xc7EWjTygVKy1IDfxFze9Oz8G5aSf7xYJZc3piytLoqvkNrRu7JXpP//QwB+
O3/vao29/rjfRUBu2hKyRK3xP9Q4ZukNfsh2L9glIC3kbGd8ctYOe8CmO+ji
XSM+fswp9ekTnzT8fvnp04oCOXUZnis8B1gQnNV2LyDv4DR1YPonSj0NmIG8
NkIsXkgLWaXTQbQuClmWIIdA2rcsjXxf9ZbPs6bVX4wpnl1VacJXB4KxjKnK
g5wmsVuMx6fjWIuSIOnIr12/BjRqzc6VLZHMihB+KErFxEcgsqaR3vyaIb1x
wBHrC88vo1vS/6O+hEwO5ftvA4kH6bVJyc67rSm1kKI2m3q5hoo7UxJKtKpl
a0LDUnfOM2gIKH0LLzm7xcmoLtBuJcR3ALXzyBs4i3EZINJnsIA0rFMyBYuD
v6uNwhEucM6MkO2kj0YZJC4y5JAFmXS8VuTrToa4SEiWyWyIgJejN+ueQ06L
wchbbYWuoH1kE+jt7IBd7YSMFAM6IcOGQvRUmGn0ryjT+FJVRvUWpJFEOthJ
ckbBkfRsXAQG4JabTJe996S6sgY1RS8OFlstSxxcm46ShZAcID0nDJk4Y9uF
aLUuA8Wt1FH7hjA55K1sj6B/Z6wlcAVZabYNDtGKyhph6yvx46j3kB7JI5Q0
RfHTCV5KpNGd2A91lO1LKqfPVuKqA9Q+sP1AXu12iSkOKqeNGrlIwNEfOuip
y0v0F7uUopFSjviZvjN09dagYzjCRANkAmWg1xtSDvGS8fCWYkrI2WvpL0VR
PP+iipwzsOwW/ye16HR2hqT84eqz1Ue8v5ZEWY51MX60ae61y6L4+sTZ+Wih
iOKTIqn7SwDeMS1z60I89RTPE1+S2mnB/8arRfGHlXjPqZ6yPBAjSW7BJgWF
eZ1UC4HYl2RtjVwbS7UZG48BG9lCH/Y4448r8Za0aPdPTwFP1KweNX0Ox2HF
6I3H0GPM/ox23VQGCm5cLgE76XPlPKbJpbhCqH521MvSczCbFgJQduLk/R2y
Bp6GQI3G9hLMEL6UsMxrgcIpfrfep0ah1JUBAcDhvxdt36yR7rNeY5I7hA9h
pd/oycpESZNl5GCrL5kD7hNVMjugm9of6gzV5pzEKS6Vs9btuKzCLu2NhGgr
M7biI0FI/M+fP1PHfJbPoEUQ8063vaYyKJXSXSRVDrmiHPE7AYkLJm1f976k
HgZhnjF4OpDDRFWlAXWazg7YDKC4ydlr6b2Bu0gJVm+RbaP9WxPk0CNSRQdy
kA+03ZqHXM+JRntVJy5E8NxWe5CvbUjAEGry9lRHEsF5itLOvO0QUWpKcjCo
k0DagMvFWZwrekYeinxPW5NNEtninSyhDXDBJeTq7urQkqOd+MD1dKwIpC/6
sIAehqRMWiJu5GS5OuMInST6EwGeM/xdymg6mprO4x3YCdykwKcG1+vU9Hmx
ZawEbTX3+LgRG8rTyZ7ABlG3suFegSXTWZHo0UMlvaWQXjLJ/7dayi0ujJmd
RmVqjpQbPCu5yGIb4vRIg6+nGoizoxg6G86HJkyOR/yAKztwJLsuYfO0FZMG
meOWmDnrkSI5xf7U6lpLS4zE3Jy+EsuyL4DRBdpw6QF0dCILKgYGnWE6fSYR
TkFDihaReTc1MPPrx+nOPffOFZJnQdXxcuLFoJ+cpbfS9mzC2kH7of1Trmdj
dxx8ejOcZWgbPaCjo2102nwXlYRJ7zrvVkYiumRiF2fIVpjCxEaiWtfSPcAb
xFnCCwhxRMZR/LzrEKKoh+NgDTrtMiTaPpiVYkZlO1dO5XznPO3MyESNg5oq
5THuMJSeX4LG6P1USKGJtVOf7udeLKGFioBaH3JPjHbG4SoXUEup2o1YYxBk
DU82hyM4hw6AKh8BgXpg3Eg863zKxlS97tDZ0hwC0hNW/+PyFR5LmtSvN9DK
NYZGc7xqMVkmvAkPdK0KThkWljt3gCpVulxKDtXuKe+e0iPzMVDAN0zpAcjy
UO1KlMqWg5l4+JbVGXu9oStwRHmAVSIsRJiAm3u3RC6Uvu0/T5SY5gd8x+fy
FcZWX2x05GXBqIcFIJfw4lI5mqkTIlgylVWuNGkHfRllxF49EC9kbVbM36et
Q3LaSToODQfb9+/o2mlHrsV2rJrolkjiwHnliin9X3e5p5tCTQYzmfzGyqVL
3jD0Jm5Lvu8AFtwgvpAqclJ/uB8Ich+mzdyshePKkKYWldwiW4n0iMzcOkrD
RUeOR9P+4fQhCd5zzPIlV03uvscnUTWX/KkZPOBLUy5iTOTJ4miCP7Ef1+5Z
PU+JRrOZfGOnVovkjlV4uHY/IVSaGaWG5fjcUrxPAxH4s31APzZWl75VVBzS
NAoNW9fRwALkf8TOsveZfgNv1J48zL0yiHxNQzzNI4LjE4LH9s9tHxw1em4Q
tB5RWQ78UPUR16uELkZCUbwe51wnB7j53hxC3/DkKhPQeMXcDbfC7F3NVX9M
k/CUkvCK3gRV67K3o8o8eeIvyjq+WviUPujEyXkM08kAbOihaZKP1QPfBe23
RtGM6w7FG/cqmm9BowYmiI0kgdOrcSJSxRcBP9IoBX4tW2Qkj35aGgKOmB18
4Xp/yg3J2ffUQWymhSP5EyWIRLHfaXhQSeZyWW652NItejRJHm8FDrMl6opl
mShJWE11FwIqqz+YjJVcgrjElbrT3K/k0mG86hv625YaQUkmj009X2gnwhb5
0+iQ6bR7Npl+rDj1BYcxgqJhHLeWG+LY+SzRbEhAThia3vWeRU595LPtAzKG
9mduEvEcI2qoLWjZN4Zyd/Av64VVnYMRkJVaIlidoGvoihB3sJTHu8Pfwejv
ldz3yDzs5QlzS9d26hFxIP2i5+iUs2EY9nsNJiGp6e8gaVWrd+NKGsKnM9DC
8pE3V3++On7cONCmYEAOr5Sp3cp/ellL9VAU/wBt7PvOex0AAA==

-->

</rfc>

