idnits 2.17.1 draft-ietf-mtgvenue-meeting-policy-06.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 (May 14, 2018) is 2174 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 187, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) == Outdated reference: A later version (-16) exists of draft-ietf-mtgvenue-iaoc-venue-selection-process-15 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 May 14, 2018 5 Expires: November 15, 2018 7 High level guidance for the meeting policy of the IETF 8 draft-ietf-mtgvenue-meeting-policy-06 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 November 15, 2018. 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. Re-evaluation and changes to this policy . . . . . . . . . . 4 53 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 54 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 56 6.2. Informative References . . . . . . . . . . . . . . . . . 5 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1. Introduction 61 The work of the IETF is primarily conducted on the working group 62 mailing lists, while face-to-face WG meetings mainly provide a high 63 bandwidth mechanism for working out unresolved issues. The IETF 64 currently strives to have a 1-1-1-* meeting policy [IETFMEET] where 65 the goal is to distribute the meetings equally between North America, 66 Europe, and Asia. These are the locations most of the IETF 67 participants have come from in the recent past. This meeting 68 rotation is mainly aimed at distributing the travel effort for the 69 existing IETF participants who physically attend meetings and for 70 distributing the timezone difficulty for those who participate 71 remotely. This policy has neither been defined precisely nor 72 documented in an IETF consensus document until now. This document is 73 meant to serve as a consensus-backed statement of this policy 74 published as a BCP. 76 2. The 1-1-1-* meeting policy 78 Given that the majority of the current participants come from North 79 America, Europe, and Asia [CONT-DIST], the IETF policy is that our 80 meetings should primarily be in those regions. i.e., the meeting 81 policy (let's call this the "1-1-1" policy) is that meetings should 82 rotate between North America, Europe, and Asia. Please note that the 83 boundaries between those regions has been purposefully left 84 undefined. It is important to note that such rotation and any 85 effects to distributing travel pain should be considered from a long- 86 term perspective. While a potential cycle in an IETF year may be a 87 meeting in North America in March, a meeting in Europe in July, and a 88 meeting in Asia on November, the 1-1-1 policy does not imply such a 89 cycle, as long as the distribution to these regions over multiple 90 years is roughly equal. There are many reasons why meetings might be 91 distributed differently in a given year. Meeting locations in 92 subsequent years should seek to re-balance the distribution if 93 possible. 95 BACKGROUND NOTE: The IETF recognizes that we have not achieved a 96 1-1-1 distribution over the past few years. At the time of writing, 97 going back 6 years the meeting locations resemble more the previous 98 3-2-1 policy (9 Americas, 6 Europe and 3 Asia). This is attributable 99 to two reasons: 101 o We plan meetings 3 years ahead (meaning meetings for 3 of the 6 102 years had already been planned when the new policy was set) 104 o There were some logistical issues (venue availability, cost etc.). 106 While this meeting rotation caters to the current set of IETF 107 participants, we need to recognize that due to the dynamic and 108 evolving nature of participation, there may be significant changes to 109 the regions that provide a major share of participants in the future. 110 The 1-1-1-* meeting policy is a slightly modified version of the 111 aforementioned 1-1-1 meeting policy that allows for additional 112 flexibility in the form of an exploratory meeting denoted as a "*". 113 This exploratory meeting can be used to experiment with exceptional 114 meetings without extensively impacting the regular meetings. e.g. 115 these exploratory meetings can include meetings in other geographical 116 regions, virtual meetings and additional meetings past the three 117 regular meetings in a calendar year. 119 The exploratory meeting proposals will be initiated based on 120 community consent. After such a proposal is initiated the IESG will 121 make a decision in consultation with the Internet Administrative 122 Support Activity (IASA) to ensure that the proposal can be 123 realistically implemented. The final decision will be communicated 124 back to the community to ensure that there is adequate opportunity to 125 comment. 127 NOTE: There have not been a large number of such exploratory meetings 128 under the current 1-1-1-* policy (with IETF95 in Buenos Aires and 129 IETF47 in Adelaide being the exceptional instances). IETF27 130 (Amsterdam) and IETF54(Yokohama) were earlier examples of exploratory 131 meetings that pioneered Europe and Asia as regular IETF destinations. 132 The timing and frequency of future exploratory meetings will be based 133 on IETF consensus as determined by the IETF chair. 135 3. Implementation of the policy 137 IASA should understand the policy written in this document to be the 138 aspiration of the IETF community. Similarly, any exploratory meeting 139 decisions will also be communicated to the IASA to be implemented. 140 The actual selection of the venue would be performed by the IASA 141 following the process described in 142 [I-D.ietf-mtgvenue-iaoc-venue-selection-process]. 144 As mentioned in [I-D.ietf-mtgvenue-iaoc-venue-selection-process], the 145 IASA will also be responsible 147 o to assist the community in the development of detailed meeting 148 criteria that are feasible and implementable, and 150 o to provide sufficient transparency in a timely manner concerning 151 planned meetings so that community feedback can be collected and 152 acted upon. 154 Given that the geographical location of the venue has a significant 155 influence on the venue selection process, it needs to be considered 156 at the same level as the other Important Criteria specified in 157 Section 3.2 of [I-D.ietf-mtgvenue-iaoc-venue-selection-process] 158 (including potentially trading off the geographical region to meet 159 other criteria, and notifying the community if the geographical 160 region requirement cannot be met) 162 4. Re-evaluation and changes to this policy 164 Given the dynamic nature of participant distribution in the IETF, it 165 is expected that this policy needs to be periodically evaluated and 166 revised to ensure that the stated goals continue to be met. The 167 criteria that are to be met need to be agreed upon by the community 168 prior to initiating a revision of this document (e.g. try to mirror 169 draft author distribution over the preceding five years). 171 5. Acknowledgments 173 The author would like to thank Jari Arkko, Alia Atlas, Fred Baker, 174 Brian Carpenter, Alissa Cooper, Dave Crocker, Spencer Dawkins, 175 Stephen Farrell, Tobias Gondrom, Eric Gray, Bob Hinden, Ole Jacobsen, 176 Olaf Kolkman, Eliot Lear, Andrew Malis, Yoav Nir, Ray Pelletier, 177 Melinda Shore, John Klensin, Charles Eckel, Russ Housley, Andrew 178 Sullivan, Eric Rescorla, Richard Barnes, Cullen Jennings, Ted Lemon, 179 Lou Berger, John Levine, Adam Roach, Mark Nottingham, Tom Petch, 180 Randy Bush, Roni Even, Julien Meuric and Lloyd Wood for their ideas 181 and comments to improve this document. 183 6. References 185 6.1. Normative References 187 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 188 IETF Administrative Support Activity (IASA)", BCP 101, 189 RFC 4071, DOI 10.17487/RFC4071, April 2005, 190 . 192 6.2. Informative References 194 [CONT-DIST] 195 IETF, "Number of attendees per continent across meetings", 196 2016, 197 . 199 [I-D.ietf-mtgvenue-iaoc-venue-selection-process] 200 Lear, E., "IETF Plenary Meeting Venue Selection Process", 201 draft-ietf-mtgvenue-iaoc-venue-selection-process-15 (work 202 in progress), May 2018. 204 [IETFMEET] 205 IAOC Plenary Presentation, "IETF 1-1-1 Meeting Policy", 206 2010, . 209 Author's Address 211 Suresh Krishnan 212 Kaloom 214 Email: suresh@kaloom.com