Internet Engineering Task Force (IETF) S. KrishnanInternet-DraftRequest for Comments: 8490 KaloomIntended status:BCP: 219 October 2018 Category: Best Current PracticeJuly 2, 2018 Expires: January 3, 2019 High level guidanceISSN: 2070-1721 High-Level Guidance for themeeting policyMeeting Policy of the IETFdraft-ietf-mtgvenue-meeting-policy-07Abstract This document describes a meeting location policy for the IETF and the various stakeholdersfor realizing such arequired to realize this policy. Status of This Memo ThisInternet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are workingmemo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 ofsix monthsRFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 3, 2019.https://www.rfc-editor.org/info/rfc8490. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The 1-1-1-*meeting policyMeeting Policy . . . . . . . . . . . . . . . . . 2 3. Implementation of thepolicyPolicy . . . . . . . . . . . . . . . . 3 4. Procedure forinitiating proposalsInitiating Proposals forexploratory meetingsExploratory Meetings . 4 5. Re-evaluation andchangesChanges tothis policyThis Policy . . . . . . . . . . 4 6.AcknowledgmentsReferences . . . . . . . . . . . . . . . . . . . . . . . . . 47.6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . .5 7.1. Normative References. . . . . . . . . . 4 Acknowledgments . . . . . . . .5 7.2. Informative References. . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The work of the IETF is primarily conducted on the working group (WG) mailing lists, while face-to-face WG meetings mainly provide ahighhigh- bandwidth mechanism for working out unresolved issues. The IETF currently strives to have a 1-1-1 meeting policy[IETFMEET]where the goal is to distribute the meetings equally between North America, Europe, andAsia.Asia (see "Meeting Location Distribution" (slides 14 and 15) of [IETFMEET] for details). These are the locations most of the IETF participants have come from 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 hasneitherbeen neither defined precisely nor documented in an IETF consensus document until now. ThisdocumentBCP RFC is meant to serve as a consensus-backed statement of thispolicy published as a BCP.policy. 2. The 1-1-1-*meeting policyMeeting Policy Given that the majority of the current meeting participants come from North America, Europe, and Asia [CONT-DIST], the IETF policy is thatourthe meetings should primarily be held in those regions.i.e.,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.Please noteNote that the boundaries between those regionshashave 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 tore-balancerebalance thedistributiondistribution, 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.TheTherefore, 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 meetingdenoted(denoted as a"*". This exploratory meeting"*"). Exploratory meetings can be used to experiment with exceptional meetings without extensively impacting the regular meetings.e.g.For example, these exploratory meetings can include meetings in other geographical regions, virtualmeetingsmeetings, and additional meetingspastbeyond 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 Internet Administrative Support Activity (IASA) [RFC4071] 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. NOTE: There have not been a large number of meetings that would qualify as exploratory meetings under the current1-1-1-*1-1-1 policy (withIETF95IETF 95 in Buenos Aires andIETF47IETF 47 in Adelaide being the exceptional instances).IETF27IETF 27 (Amsterdam) andIETF54(Yokohama)IETF 54 (Yokohama) were earlier examples of exploratory meetings that pioneered Europe and Asia as regular IETF destinations. 3. Implementation of thepolicyPolicy IASA 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[I-D.ietf-mtgvenue-iaoc-venue-selection-process].[RFC8491]. As mentioned in[I-D.ietf-mtgvenue-iaoc-venue-selection-process],[RFC8491], the IASA will also be responsible for the following: oto assistassisting the community in the development of detailed meeting criteria that are feasible and implementable, and oto providefor 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 Section 3.2 of[I-D.ietf-mtgvenue-iaoc-venue-selection-process][RFC8491] (including potentially trading off the geographical region to meet othercriteria,criteria and notifying the community if the geographical region requirement cannot bemet)met). 4. Procedure forinitiating proposalsInitiating Proposals forexploratory meetingsExploratory Meetings Someone who is interested in pursuing an exploratory venue proposes it on the IETF discussion list or on a future discussion list expresslysetupset up and announced for this purpose. The community gets to comment on the venue and to 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 mailinglist.list <https://www.ietf.org/mailman/listinfo/venue- selection>. This would allow the interested party(ies) to refine their proposalwith those tasked with evaluating it and providing further insightfulbased on the insighful feedback regarding the logistics of thevenue.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. 5. Re-evaluation andchangesChanges tothis policyThis Policy Given the dynamic nature of participant distribution in the IETF, it is expected that this policyneedswill 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.(e.g., try to mirror draft author distribution over the preceding five years).7.6. References7.1.6.1. Normative References [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, <https://www.rfc-editor.org/info/rfc4071>.7.2.6.2. Informative References [CONT-DIST] IETF, "Number of attendees per continent across meetings",2016,<https://datatracker.ietf.org/stats/meeting/continent/>.[I-D.ietf-mtgvenue-iaoc-venue-selection-process][IETFMEET] Hinden, B. and R. Pelletier, "IAOC Report IETF79", November 2010, <https://www.ietf.org/proceedings/79/slides/ plenaryw-3.pdf>. [RFC8491] Lear, E., Ed., "IETF Plenary Meeting Venue Selection Process",draft-ietf-mtgvenue-iaoc-venue-selection-process-16 (work in progress), June 2018. [IETFMEET] IAOC Plenary Presentation, "IETF 1-1-1 Meeting Policy", 2010, <https://www.ietf.org/proceedings/79/slides/ plenaryw-3.pdf>. 6.BCP 219, RFC 8491, DOI 10.17487/RFC8491, October 2018, <https://www.rfc-editor.org/info/rfc8491>. Acknowledgments The author would like to thank Jari Arkko, Alia Atlas, Fred Baker, Brian Carpenter, Alissa Cooper, Dave Crocker, Spencer Dawkins, Stephen Farrell, Tobias Gondrom, Eric Gray, Bob Hinden, Ole Jacobsen, Olaf Kolkman, Eliot Lear, Andrew Malis, Yoav Nir, Ray Pelletier, Melinda Shore, John Klensin, Charles Eckel, Russ Housley, Andrew Sullivan, Eric Rescorla, Richard Barnes, Cullen Jennings, Ted Lemon, Lou Berger, John Levine, Adam Roach, Mark Nottingham, Tom Petch, Randy Bush, Roni Even, Julien Meuric, Lloyd Wood, AlvaroRetanaRetana, and Martin Vigoureux for their ideas and comments to improve this document. Author's Address Suresh Krishnan Kaloom Email: suresh@kaloom.com