<?xml version='1.0' encoding='utf-8'?>
<!-- XML2RFC / RFCXML v2 -->
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Processing Instructions- PIs (for a complete list and description,
see file http://xml.resource.org/authoring/README.html.
       (?Link may have changed to ...tools.ietf.org )
     You may find that some sophisticated editors are not able to edit PIs when palced here.
     An alternative position is just inside the rfc elelment as noted below. -->
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<!-- Controls display of <cref> elements -->
<?rfc comments="yes" ?>
<!-- When no, put comments at end in comments section,
     otherwise, put inline -->
<?rfc inline="yes" ?>
<!-- When yes, insert editing marks: editing marks consist of a 
     string such as <29> printed in the blank line at the 
     beginning of each paragraph of text. -->
<?rfc editing="no" ?>
<!-- Create Table of Contents (ToC) and set some options for it.  
     Note the ToC may be omitted for very short documents,but idnits insists on a ToC 
     if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC.
   Can be overridden by 'toc="include"/"exclude"' on the section
   element-->
<!-- Choose the options for the references. 
     Some like symbolic tags in the references (and citations) and others prefer 
     numbers. The RFC Editor always uses symbolic tags.
     The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
			 This doesn't have any effect unless symrefs is "yes"
          also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each 
     main section on a new page but does not omit the blank lines between list items. 
     If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- Information about the document.
     category values: std, bcp, info, exp, and historic
     For Internet-Drafts, specify attribute "ipr".
         original ipr values are: full3978, noModification3978, noDerivatives3978), 
         2008 IETF Trust versions: trust200811,
           noModificationTrust200811, noDerivativeTrust200811
         2009/Current: trust200902, noModificationTrust200902,
           noDerivativesTrust200902,  pre5378Trust200902
     Also for Internet-Drafts, you must specify a value for attributes "docName" which is 
        typically the file name under which it is filed but need not be.
     If relevant, "iprExtract" may be specified to denote the anchor attribute value of a
        section that can be extracted for separate publication, it is only useful when the value
        of "ipr" does not give the Trust full rights.
     "updates" and "obsoletes" attributes can also be specified here, their arguments are
      comma-separated lists of RFC numbers (just the numbers)
      'consensus="true" usually goes with IETF Stream submissions; else false
      "submission types": IETF, IAB, IRTF, independent

	00a: Initial version, started 2023-08-05
	00b: Revision after proofreading and considering comments on the
		ietf-smtp list on 2023-08-06.  Posted 2023-08-07 with 6th
        retained in the date to avoid confusing that discussion.
    01a: Fixed the title.
    02a: Slightly edited, note added, reposted after 01 expired.
         Posting version 2024-02-09.
    03a: Update to have un-expired copy going into IETF 121 and IANA discussion
         planned for then.  Posted 2024-10-20.
    04a: New version started 2025-03-17 during IETF 122 for IANABIS discussion
        Fixed abbreviated title and removed introductory note pointing to 5321bis
        Posted 2025-04-14 to prevent expiration - next version probably belongs
          to IANABIS.

-->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	      docName="draft-hardie-venue-reassessment-00"
	  	  ipr="trust200902" category="bcp" obsoletes="" updates="8718"
	      submissionType="IETF" consensus="true" xml:lang="en"
          tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- ***** FRONT MATTER ***** -->
  <front>
	 <title abbrev="IETF Venue Reassessment">
		IETF Venue Reassessment</title>
    <seriesInfo name="Internet-Draft"
			   value="draft-hardie-venue-reassessment-00"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->
    <author fullname="Ted Hardie" initials="T" surname="Hardie">
      <organization/>
      <address>
        <email>ted.ietf@gmail.com</email>
      </address>
    </author>
    <date month="November" day="07" year="2025"/>
    <!-- Meta-data Declarations    -->
	<area>General</area>

    <!-- WG name at the upper left corner of the doc,
         IETF fine for individual submissions.  You can also
         omit this element in which case it defaults to "Network Working Group" -
         a hangover from the ancient history of the IETF! -->
    <workgroup>GENDISPATCH</workgroup>

	<!-- You can add <keyword/> elements here.  They will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff output. -->
	<!-- <keyword>Text</keyword> (as many of those elements as needed -->

	
    <abstract>
      <t>The current venue selection procedures do not describe how to
      request reconsideration of a venue's suitability in the event of
      major changes related to the safety of a venue or the ability
      of IETF participants to enter the relevant jurisdicition.  This draft sets out a strawman
      process for this procedure.
      </t>
	</abstract>
	
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>  The IETF Administration Support Activity (IASA) is
      responsible for arranging the selection and operation of the
      IETF plenary meeting venue, according to the principles set out
      in <xref target="RFC8718"/>.  The specific procedures for meeting
      planning in place at  the time this document was written were found at <xref
      target="MeetingPlanning"/>
      </t>
	  
	  <t> The current meeting procedures set out in some detail how
	  meeting venues are identified and evaluated.  They also
	  contain specific information on how the evaluation of
	  exploratory meetings differs from those in the standard
	  rotation.  Under normal circumstances the decision to hold a
	  meeting at a specific venue, once taken, continues to guide
	  activity through the meeting at issue.</t>
	  
	  <t> There are, however, certain extraordinary circumstances
	  which may require that a decision be reconsidered.  This
	  document sets out a strawman process for that
	  reconsideration.</t>
	  

    <section anchor="ReconsiderationJustification" numbered="true" toc="default">
	   <name>When reconsideration is warranted</name>

	   <t> Reconsideration should be an extraordinary event,
	   occurring only when there have been substantive changes in
	   the circumstances relevant to the venue.  Changes in travel
	   costs, exchange rates, and other commercial circumstances
	   do not normally justify reconsideration.  </t>

	   <t>Large-scale changes to the set of participants who may
	   travel to the venue may be a justification for
	   reconsideration.  While it is a non-goal within the venue
	   selection process to insure maximal attendance,
	   the projected attendance and the composition of the set of
	   attendees are key elements used in assessing
	   whether or not the venue will support an
	   effective meeting. Changes in the set of  participants
	   who may travel may invalidate previous projections or
	   understandings of the inclusiveness supported by the venue, thus
	   justifying a reconsideration.</t>

	   <t>
	   Our procedures require that the safety and health risks
	   associated with a venue be acceptable.  If there are
	   substantive changes to the safety or  health risks
	   associated with the venue for some
	   or all of IETF participants, those changes may justify a
	   reconsideration. 
	   </t>

	   
	  </section>

	  <section anchor="ReconsiderationRequests" numbered="true" toc="default">
	    <name>Reconsideration requests</name>
	    
		 <t> A reconsideration may be triggered at any time by
		 the IETF LLC, based on its own information.</t>
		 
		 <t> A reconsideration may be requested informally by
		 any member or members of the community in any of the
		 normal venues for feedback, including email to the
		 IETF LLC board, attendance at its public meetings, or
		 at the IETF plenary.  Reconsiderations requested by
		 this method are handled at the discretion of the IETF
		 LLC. </t>
		 
		 <t> A formal request for reconsideration may be
		 presented to the chair of the board of the  IETF LLC
		 by any ten members of the
		 IETF community who meet the criteria set out below.
		 Such requests must specify the venue and the change
		 which justifies the request for reconsideration.  Any
		 evidence supplied supporting the request must include
		 information on the source of the evidence and a clear
		 statement of why it justifies the request for
		 reconsideration.</t>
		 		 <t>
		   A person may be eligible to participate in this
		   process because  they have
		   registered for and attended 3 out of the last 5
		   IETF meetings.  A person may also be eligible
		   because they served as a Working Group Chair or
		   Secretary within 3 years prior to the request.
		 </t>
		 <t> NOTE:  This follows the selection criteria for
		 NomCom members, but it does not reuse it because
		 those criteria exclude sitting members of IETF
		 leadership bodies.   Since those roles do not bear on
		 the individuals' assessment of a venue, they are not
		 excluded here.</t>
	  </section>

	  <section anchor="Reassessment" numbered="true" toc="default">		 
	    <name>Reassessment</name>
	    
		 <t> When changes have justified a reconsideration,
		 the form of the reassessment will depend on the specific
		 changes which have been brought forward.  Generally,
		 the IETF LLC will follow those steps in the current
		 meeting assessment process which relate to the
		 conditions which have changed, focusing on those
		 steps which are necessary to
		 confirm that the venue remains viable or to confirm
		 the impact on the meeting of the changes that have
		 been brought forward.
		 </t>

		 <t>If a formal
		 request for reconsideration has occurred, then the
		 reassessment must include a request for community
		 feedback and an assessment by the IESG of the meeting viability. 

	</t>
	  </section>
	  
	  
	</section>
		
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to those on the IETF main mailing list for their
      comments on this broad topic.</t>
	</section>
	
    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo has no actions for actions for IANA.</t> 
	</section>
	
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t> This specification
		 does not update the security considerations associated
      with venue selection.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->
  <back>
    <!-- References split to informative and normative -->

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8718.xml"/>

    </references>
	<references>
        <name>Informative References</name>

      <reference anchor="MeetingPlanning"
		  target=" https://www.ietf.org/meeting/planning/">  
        <front>
          <title>IETF Meeing Planning</title>
          <author>
            <organization>IASA</organization>
	        <address/>
          </author>
		  <date year="2025" month="November" day="5"/>

        </front>
      </reference> 
      
    </references>  <!-- end Informative -->
    </references>  <!-- end all references -->
	
  </back>
</rfc>
