High-Level Guidance for the Meeting Policy of the IETFKaloomsuresh@kaloom.com
General
Meeting Venue Working Groupgeographic distribution locationIASAThis document describes a meeting location policy for the IETF and
the various stakeholders required to realize this policy.Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further information
on BCPs is available in Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. The 1-1-1-* Meeting Policy
. Implementation of the Policy
. Procedure for Initiating Proposals for Exploratory Meetings
. Re-evaluation and Changes to This Policy
. References
. Normative References
. Informative References
Acknowledgments
Author's Address
Introduction
The work of the IETF is primarily conducted on working group (WG)
mailing lists, while face-to-face WG meetings mainly provide a high-bandwidth
mechanism for working out unresolved issues. The IETF
currently strives to have a 1-1-1 meeting policy
where the goal is to distribute the meetings equally between North America,
Europe, and Asia (see "Meeting Location Distribution" (slides 14 and 15) of
for details). These are the
locations from which most of the IETF participants have come in the recent past.
This meeting rotation is mainly aimed at distributing the travel effort for
the existing IETF participants who physically attend meetings and for
distributing the timezone difficulty for those who participate remotely.
This policy has been neither defined precisely nor documented in an
IETF consensus document until now. This BCP RFC is meant to serve as a
consensus-backed statement of this policy.
The 1-1-1-* Meeting PolicyGiven that the majority of the current meeting participants come from
North America, Europe, and Asia , the
IETF policy is that the meetings should primarily be held in those
regions. That is, the meeting policy (let's call this the "1-1-1"
policy) is that meetings should rotate between North America,
Europe, and Asia. Note that the boundaries between those
regions have been purposefully left undefined. It
is important to note that such rotation and any effects to
distributing travel pain should be considered from a long-term
perspective. While a potential cycle in an IETF year may be a
meeting in North America in March, a meeting in Europe in July, and
a meeting in Asia on November, the 1-1-1 policy does not imply
such a cycle, as long as the distribution to these regions over
multiple years is roughly equal. There are many reasons why meetings
might be distributed differently in a given year. Meeting locations in
subsequent years should seek to rebalance the distribution, if
possible.While this meeting rotation caters to the current set of IETF
participants, it is important to recognize that due to the dynamic and
evolving nature of participation, there may be significant changes
to the regions that provide a major share of participants in the
future. Therefore, the 1-1-1-* meeting policy is a slightly modified version
of the aforementioned 1-1-1 meeting policy that allows for
additional flexibility in the form of an exploratory meeting (denoted with
an "*"). Exploratory meetings can be used to experiment with
exceptional meetings without extensively impacting the regular
meetings. For example, these exploratory meetings can include meetings in
other geographical regions, virtual meetings, and additional
meetings beyond the three regular meetings in a calendar year.
The timing and frequency of future exploratory meetings will be based
on IETF consensus as determined by the IETF chair. Once a meeting
proposal is initiated, the IESG will make a decision in consultation with
the IETF Administrative Support Activity (IASA) to ensure that the proposal can be realistically
implemented. The final decision will be communicated back to the
community to ensure that there is adequate opportunity to comment.
Implementation of the PolicyIASA should understand the policy
written in this document to be the aspiration of the IETF community. Similarly, any
exploratory meeting decisions will also be communicated to the IASA to
be implemented. The actual selection of the venue would be
performed by the IASA following the process described in .
As mentioned in , the IASA will also be responsible for the following:
assisting the community in the development of detailed meeting
criteria that are feasible and implementable, and
providing sufficient transparency in a timely manner
concerning planned meetings so that community feedback can be
collected and acted upon.
Given that the geographical location of the venue has a
significant influence on the venue selection process, it needs to
be considered at the same level as the other Important Criteria
specified in (including
potentially trading-off the geographical region to meet other
criteria and notifying the community if the geographical region
requirement cannot be met).Procedure for Initiating Proposals for Exploratory MeetingsSomeone who is interested in pursuing an exploratory venue
proposes it on the IETF discussion list or on a future
discussion list expressly set up and announced for this
purpose. The community gets to comment on the venue and offer
their opinions. If the IETF chair determines that there is
community consensus to pursue the venue further, the venue will
be put up for discussion on the venue-selection mailing
list <>.
This would allow the interested party(ies) to refine their proposal
based on insightful feedback regarding the logistics of the venue
from those tasked with evaluating it. Once the venue selection process
takes place, the final decision will be communicated back to the
community to ensure that there is adequate opportunity to comment.
Re-evaluation and Changes to This PolicyGiven the dynamic nature of participant distribution in the
IETF, it is expected that this policy will need to be periodically
evaluated and revised to ensure that the stated goals continue
to be met. The criteria that are to be met need to be agreed upon by the
community prior to initiating a revision of this document (e.g., try to
mirror draft author distribution over the preceding five years).
ReferencesNormative ReferencesStructure of the IETF Administrative Support Activity, Version 2.0Informative ReferencesNumber of attendees per continent across meetingsIETFIAOC Report IETF79IAOC Plenary PresentationIAOC Plenary PresentationIETF Plenary Meeting Venue Selection ProcessAcknowledgmentsThe author would like to thank
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
and
for their ideas
and comments to improve this document. Author's AddressKaloomsuresh@kaloom.com