idnits 2.17.1 draft-ietf-mtgvenue-meeting-policy-02.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 (December 4, 2017) is 2334 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 172, 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-10 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 December 4, 2017 5 Expires: June 7, 2018 7 High level guidance for the meeting policy of the IETF 8 draft-ietf-mtgvenue-meeting-policy-02 10 Abstract 12 This document describes a proposed meeting location policy for the 13 IETF and 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 June 7, 2018. 32 Copyright Notice 34 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . 4 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 that are the locations most of the IETF participants 67 have come from in the recent past. This meeting rotation is mainly 68 aimed at distributing the travel pain for the existing IETF 69 participants who physically attend meetings and for distributing the 70 timezone pain for those who participate remotely. This policy has 71 neither been defined precisely nor documented in an IETF consensus 72 document. This document is meant to serve as a consensus-backed 73 statement of this policy published as a BCP. 75 2. The 1-1-1-* meeting policy 77 Given that the majority of the current participants come from North 78 America, Europe, and Asia [CONT-DIST], the IETF policy is that our 79 meetings should primarily be in those regions. i.e., the meeting 80 policy (let's call this the "1-1-1" policy) is that meetings should 81 rotate between North America, Europe, and Asia. It is important to 82 note that such rotation and any effects to distributing travel pain 83 should be considered from a long-term perspective. While the typical 84 cycle in an IETF year may be a meeting in North America in March, a 85 meeting in Europe in July, and a meeting in Asia on November, the 86 1-1-1 policy does not mandate such a cycle, as long as the 87 distribution to these regions over multiple years is roughy equal. 88 There are many reasons why meetings might be distributed differently 89 in a given year, and that is fine as long as the distribution in 90 subsequent years balances out the disruptions. 92 BACKGROUND NOTE:The IETF recognizes that we have not always been 93 successful in following this policy over the past few years. In 94 fact, at the time of writing, going back 6 years the meeting 95 locations resemble more the previous 3-2-1 policy (9 Americas, 6 96 Europe and 3 Asia). This is attributable to two reasons: 98 o we plan meetings 3 years ahead (meaning meetings for 3 of the 6 99 years had already been planned when the new policy was set) 101 o there were some logistical issues (venue availability, cost etc.). 103 While this meeting rotation caters to the current set of IETF 104 participants, we need to recognize that due to the dynamic and 105 evolving nature of participation, there may be significant changes to 106 the regions that provide a major share of participants in the future. 107 The 1-1-1-* meeting policy is a slightly modified version of the 108 aforementioned 1-1-1 meeting policy that allows for additional 109 flexibility in the form of an exploratory meeting denoted as a "*". 110 This exploratory meeting can be used to experiment with exceptional 111 meetings without extensively impacting the regular meetings. e.g. 112 these exploratory meetings can include meetings in other geographical 113 regions, virtual meetings and additional meetings past the three 114 regular meetings in a calendar year. 116 The exploratory meeting proposals will be initiated based on 117 community consent. After such a proposal is initiated the IESG will 118 make a decision in consultation with the Internet Administrative 119 Support Activity (IASA) to ensure that the proposal can be 120 realistically implemented. The final decision will be communicated 121 back to the community to ensure that there is adequate opportunity to 122 comment. 124 NOTE: There have not been a large number of such exploratory meetings 125 under the current 1-1-1-* policy (with IETF95 in Buenos Aires and 126 IETF47 in Adelaide being the exceptional instances). IETF27 127 (Amsterdam) and IETF54(Yokohama) were earlier examples of exploratory 128 meetings that pioneered Europe and Asia as regular IETF destinations. 129 How often we intend to do such meetings in the future should also be 130 an open topic for discussion within the community. 132 3. Implementation of the policy 134 Once this meeting policy has been agreed upon, the policy will be 135 provided to the IASA as high level guidance. Similarly, any 136 exploratory meeting decisions will also be communicated to the IASA 137 to be implemented. The actual selection of the venue would be 138 performed by the IASA following the process described in 139 [I-D.ietf-mtgvenue-iaoc-venue-selection-process]. 141 The IASA will also be responsible 142 o to assist the community in the development of detailed meeting 143 criteria that are feasible and implementable, and 145 o to provide sufficient transparency in a timely manner concerning 146 planned meetings so that community feedback can be collected and 147 acted upon. 149 4. Re-evaluation and changes to this policy 151 Given the dynamic nature of participant distribution in the IETF, it 152 is expected that this policy needs to be periodically evaluated and 153 revised to ensure that the stated goals continue to be met. The 154 criteria that are to be met to initiate a revision need to be agreed 155 upon by the community prior to the publication of this document. 156 (e.g. try to mirror draft author distribution over the preceding five 157 years). 159 5. Acknowledgments 161 The author would like to thank Jari Arkko, Alia Atlas, Fred Baker, 162 Brian Carpenter, Alissa Cooper, Dave Crocker, Spencer Dawkins, 163 Stephen Farrell, Tobias Gondrom, Eric Gray, Bob Hinden, Ole Jacobsen, 164 Olaf Kolkman, Eliot Lear, Andrew Malis, Yoav Nir, Ray Pelletier, 165 Melinda Shore, John Klensin, and Charles Eckel for their ideas and 166 comments to improve this document. 168 6. References 170 6.1. Normative References 172 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 173 IETF Administrative Support Activity (IASA)", BCP 101, 174 RFC 4071, DOI 10.17487/RFC4071, April 2005, 175 . 177 6.2. Informative References 179 [CONT-DIST] 180 arkko.com, "Distribution of authors by continent", 2016, 181 . 183 [I-D.ietf-mtgvenue-iaoc-venue-selection-process] 184 Lear, E., "IETF Plenary Meeting Venue Selection Process", 185 draft-ietf-mtgvenue-iaoc-venue-selection-process-10 (work 186 in progress), October 2017. 188 [IETFMEET] 189 IAOC Plenary Presentation, "IETF 1-1-1 Meeting Policy", 190 2010, . 193 Author's Address 195 Suresh Krishnan 196 Kaloom 198 Email: suresh@kaloom.com