idnits 2.17.00 (12 Aug 2021) /tmp/idnits17195/draft-ietf-mtgvenue-meeting-policy-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 1412 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4071' is defined on line 192, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) == Outdated reference: draft-ietf-mtgvenue-iaoc-venue-selection-process has been published as RFC 8718 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Krishnan 3 Internet-Draft Kaloom 4 Intended status: Best Current Practice July 2, 2018 5 Expires: January 3, 2019 7 High level guidance for the meeting policy of the IETF 8 draft-ietf-mtgvenue-meeting-policy-07 10 Abstract 12 This document describes a meeting location policy for the IETF and 13 the various stakeholders for realizing such a policy. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 3, 2019. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. The 1-1-1-* meeting policy . . . . . . . . . . . . . . . . . 2 51 3. Implementation of the policy . . . . . . . . . . . . . . . . 3 52 4. Procedure for initiating proposals for exploratory meetings . 4 53 5. Re-evaluation and changes to this policy . . . . . . . . . . 4 54 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 57 7.2. Informative References . . . . . . . . . . . . . . . . . 5 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 The work of the IETF is primarily conducted on the working group 63 mailing lists, while face-to-face WG meetings mainly provide a high 64 bandwidth mechanism for working out unresolved issues. The IETF 65 currently strives to have a 1-1-1 meeting policy [IETFMEET] where the 66 goal is to distribute the meetings equally between North America, 67 Europe, and Asia. These are the locations most of the IETF 68 participants have come from in the recent past. This meeting 69 rotation is mainly aimed at distributing the travel effort for the 70 existing IETF participants who physically attend meetings and for 71 distributing the timezone difficulty for those who participate 72 remotely. This policy has neither been defined precisely nor 73 documented in an IETF consensus document until now. This document is 74 meant to serve as a consensus-backed statement of this policy 75 published as a BCP. 77 2. The 1-1-1-* meeting policy 79 Given that the majority of the current participants come from North 80 America, Europe, and Asia [CONT-DIST], the IETF policy is that our 81 meetings should primarily be in those regions. i.e., the meeting 82 policy (let's call this the "1-1-1" policy) is that meetings should 83 rotate between North America, Europe, and Asia. Please note that the 84 boundaries between those regions has been purposefully left 85 undefined. It is important to note that such rotation and any 86 effects to distributing travel pain should be considered from a long- 87 term perspective. While a potential cycle in an IETF year may be a 88 meeting in North America in March, a meeting in Europe in July, and a 89 meeting in Asia on November, the 1-1-1 policy does not imply such a 90 cycle, as long as the distribution to these regions over multiple 91 years is roughly equal. There are many reasons why meetings might be 92 distributed differently in a given year. Meeting locations in 93 subsequent years should seek to re-balance the distribution if 94 possible. 96 While this meeting rotation caters to the current set of IETF 97 participants, it is important to recognize that due to the dynamic 98 and evolving nature of participation, there may be significant 99 changes to the regions that provide a major share of participants in 100 the future. The 1-1-1-* meeting policy is a slightly modified 101 version of the aforementioned 1-1-1 meeting policy that allows for 102 additional flexibility in the form of an exploratory meeting denoted 103 as a "*". This exploratory meeting can be used to experiment with 104 exceptional meetings without extensively impacting the regular 105 meetings. e.g. these exploratory meetings can include meetings in 106 other geographical regions, virtual meetings and additional meetings 107 past the three regular meetings in a calendar year. 109 The timing and frequency of future exploratory meetings will be based 110 on IETF consensus as determined by the IETF chair. Once a meeting 111 proposal is initiated, the IESG will make a decision in consultation 112 with the Internet Administrative Support Activity (IASA) to ensure 113 that the proposal can be realistically implemented. The final 114 decision will be communicated back to the community to ensure that 115 there is adequate opportunity to comment. 117 NOTE: There have not been a large number of meetings that would 118 qualify as exploratory meetings under the current 1-1-1-* policy 119 (with IETF95 in Buenos Aires and IETF47 in Adelaide being the 120 exceptional instances). IETF27 (Amsterdam) and IETF54(Yokohama) were 121 earlier examples of exploratory meetings that pioneered Europe and 122 Asia as regular IETF destinations. 124 3. Implementation of the policy 126 IASA should understand the policy written in this document to be the 127 aspiration of the IETF community. Similarly, any exploratory meeting 128 decisions will also be communicated to the IASA to be implemented. 129 The actual selection of the venue would be performed by the IASA 130 following the process described in 131 [I-D.ietf-mtgvenue-iaoc-venue-selection-process]. 133 As mentioned in [I-D.ietf-mtgvenue-iaoc-venue-selection-process], the 134 IASA will also be responsible 136 o to assist the community in the development of detailed meeting 137 criteria that are feasible and implementable, and 139 o to provide sufficient transparency in a timely manner concerning 140 planned meetings so that community feedback can be collected and 141 acted upon. 143 Given that the geographical location of the venue has a significant 144 influence on the venue selection process, it needs to be considered 145 at the same level as the other Important Criteria specified in 146 Section 3.2 of [I-D.ietf-mtgvenue-iaoc-venue-selection-process] 147 (including potentially trading off the geographical region to meet 148 other criteria, and notifying the community if the geographical 149 region requirement cannot be met) 151 4. Procedure for initiating proposals for exploratory meetings 153 Someone who is interested in pursuing an exploratory venue proposes 154 it on the IETF discussion list or on a future discussion list 155 expressly setup and announced for this purpose. The community gets 156 to comment on the venue and to offer their opinions. If the IETF 157 chair determines that there is community consensus to pursue the 158 venue further, the venue will be put up for discussion on the venue- 159 selection mailing list. This would allow the interested party(ies) 160 to refine their proposal with those tasked with evaluating it and 161 providing further insightful feedback regarding the logistics of the 162 venue. Once the venue selection process takes place, the final 163 decision will be communicated back to the community to ensure that 164 there is adequate opportunity to comment. 166 5. Re-evaluation and changes to this policy 168 Given the dynamic nature of participant distribution in the IETF, it 169 is expected that this policy needs to be periodically evaluated and 170 revised to ensure that the stated goals continue to be met. The 171 criteria that are to be met need to be agreed upon by the community 172 prior to initiating a revision of this document (e.g. try to mirror 173 draft author distribution over the preceding five years). 175 6. Acknowledgments 177 The author would like to thank Jari Arkko, Alia Atlas, Fred Baker, 178 Brian Carpenter, Alissa Cooper, Dave Crocker, Spencer Dawkins, 179 Stephen Farrell, Tobias Gondrom, Eric Gray, Bob Hinden, Ole Jacobsen, 180 Olaf Kolkman, Eliot Lear, Andrew Malis, Yoav Nir, Ray Pelletier, 181 Melinda Shore, John Klensin, Charles Eckel, Russ Housley, Andrew 182 Sullivan, Eric Rescorla, Richard Barnes, Cullen Jennings, Ted Lemon, 183 Lou Berger, John Levine, Adam Roach, Mark Nottingham, Tom Petch, 184 Randy Bush, Roni Even, Julien Meuric, Lloyd Wood, Alvaro Retana and 185 Martin Vigoureux for their ideas and comments to improve this 186 document. 188 7. References 190 7.1. Normative References 192 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 193 IETF Administrative Support Activity (IASA)", BCP 101, 194 RFC 4071, DOI 10.17487/RFC4071, April 2005, 195 . 197 7.2. Informative References 199 [CONT-DIST] 200 IETF, "Number of attendees per continent across meetings", 201 2016, 202 . 204 [I-D.ietf-mtgvenue-iaoc-venue-selection-process] 205 Lear, E., "IETF Plenary Meeting Venue Selection Process", 206 draft-ietf-mtgvenue-iaoc-venue-selection-process-16 (work 207 in progress), June 2018. 209 [IETFMEET] 210 IAOC Plenary Presentation, "IETF 1-1-1 Meeting Policy", 211 2010, . 214 Author's Address 216 Suresh Krishnan 217 Kaloom 219 Email: suresh@kaloom.com