idnits 2.17.00 (12 Aug 2021) /tmp/idnits55255/draft-krishnan-ietf-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 (January 12, 2017) is 1948 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: 'IETFMEET' is defined on line 202, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) Summary: 3 errors (**), 0 flaws (~~), 2 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 Ericsson 4 Intended status: Best Current Practice January 12, 2017 5 Expires: July 16, 2017 7 High level guidance for the meeting policy of the IETF 8 draft-krishnan-ietf-meeting-policy-02 10 Abstract 12 This document describes a proposed meeting 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 http://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 July 16, 2017. 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 (http://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. Open items . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 66 the goal is to distribute the meetings equally between North America, 67 Europe, and Asia that are the locations most of the IETF participants 68 have come from in the recent past. This meeting rotation is mainly 69 aimed at distributing the travel pain for the existing IETF 70 participants who physically attend meetings and for distributing the 71 timezone pain for those who participate remotely. This policy has 72 neither been defined precisely nor documented in an IETF consensus 73 document. The goal of this document is to provide an initial 74 definition of the policy, and eventually to get a consensus-backed 75 version 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. It is important to 84 note that such rotation and any effects to distributing travel pain 85 should be considered from a long-term perspective. While the typical 86 cycle in an IETF year may be a meeting in North America in March, a 87 meeting in Europe in July, and a meeting in Asia on November, the 88 1-1-1 policy does not mandate such a cycle, as long as the 89 distribution to these regions over multiple years is roughy equal. 90 There are many reasons why meetings might be distributed differently 91 in a given year, and that is fine as long as the distribution in 92 subsequent years balances out the disruptions. 94 BACKGROUND NOTE:The IETF recognizes that we have not always been 95 successful in following this policy over the past few years. In 96 fact, at the time of writing, going back 6 years the meeting 97 locations resemble more the previous 3-2-1 policy (9 Americas, 6 98 Europe and 3 Asia). This is attributable to two reasons: 100 o we plan meetings 3 years ahead (meaning meetings for 3 of the 6 101 years had already been planned when the new policy was set) 103 o there were some logistical issues (venue availability, cost etc.). 105 While this meeting rotation caters to the current set of IETF 106 participants, we need to recognize that due to the dynamic and 107 evolving nature of participation, there may be significant changes to 108 the regions that provide a major share of participants in the future. 109 The 1-1-1-* meeting policy is a slightly modified version of the 110 aforementioned 1-1-1 meeting policy that allows for additional 111 flexibility in the form of a wildcard meeting denoted as a "*". This 112 wildcard meeting can be used to experiment with exceptional meetings 113 without extensively impacting the regular meetings. e.g. these 114 wildcard meetings can include meetings in other geographical regions, 115 virtual meetings and additional meetings past the three regular 116 meetings in a calendar year. 118 The wildcard meeting proposals will be initiated based on community 119 consent. After such a proposal is initiated the IESG will make a 120 decision in consultation with the IAOC [RFC4071] to ensure that the 121 proposal can be realistically implemented. The final decision will 122 be communicated back to the community to ensure that there is 123 adequate opportunity to comment. 125 NOTE: There have not been many such wildcard meetings in the past 126 (with IETF95 in Buenos Aires and IETF47 in Adelaide being the 127 exceptional instances). How often we intend to do such meetings in 128 the future should also be an open topic for discussion within the 129 community. 131 3. Implementation of the policy 133 Once this meeting policy has been agreed upon, the policy will be 134 provided to the IAOC as high level guidance. Similarly, any wildcard 135 meeting decisions will also be communicated to the IAOC to be 136 implemented. The actual selection of the venue would be performed by 137 the IAOC following the process described in 138 [I-D.baker-mtgvenue-iaoc-venue-selection-process]. 140 The IAOC will also be responsible 141 o to assist the community in the development of detailed meeting 142 criteria that are feasible and implementable, and 144 o to provide sufficient transparency in a timely manner concerning 145 planned meetings so that community feedback can be collected and 146 acted upon. 148 4. Re-evaluation and changes to this policy 150 Given the dynamic nature of participant distribution in the IETF, it 151 is expected that this policy needs to be periodically evaluated and 152 revised to ensure that the stated goals continue to be met. The 153 criteria that are to be met to initiate a revision need to be agreed 154 upon by the community prior to the publication of this document. 155 (e.g. try to mirror draft author distribution over the preceding five 156 years). 158 5. Open items 160 There has been some discussion on whether attracting new particpants 161 is one of the stated goals of this policy. This should be one of the 162 things to be discussed and agreed upon with the community as the 163 draft progresses. 165 This draft uses the terms North America, Europe and Asia without a 166 precise definition of the geographical regions. This might lead to 167 some ambiguities. Is this ambiguity something that is desirable or 168 not? Or should we redefine the regions based on other criteria such 169 as the distribution of RIRs (e.g. ARIN/RIPE/APNIC), the UN 170 statistical department's classification of macro geographical 171 regions? 173 Do we need to predefine success criteria for the wildcard meetings? 175 6. Acknowledgments 177 The author would like to thank Jari Arkko, Alissa Cooper, Spencer 178 Dawkins, Stephen Farrell, Bob Hinden, Ray Pelletier, Tobias Gondrom, 179 Eric Gray, Melinda Shore, Dave Crocker, Brian Carpenter, Eliot Lear, 180 Andrew Malis, Olaf Kolkman, Ole Jacobsen and Yoav Nir for their ideas 181 and comments to improve this document. 183 7. References 184 7.1. Normative References 186 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 187 IETF Administrative Support Activity (IASA)", BCP 101, 188 RFC 4071, DOI 10.17487/RFC4071, April 2005, 189 . 191 7.2. Informative References 193 [CONT-DIST] 194 arkko.com, "Distribution of authors by continent", 2016, 195 . 197 [I-D.baker-mtgvenue-iaoc-venue-selection-process] 198 Baker, F., "IAOC Plenary Meeting Venue Selection Process", 199 draft-baker-mtgvenue-iaoc-venue-selection-process-03 (work 200 in progress), July 2016. 202 [IETFMEET] 203 IAOC Plenary Presentation, "IETF 1-1-1 Meeting Policy", 204 2010, . 207 Author's Address 209 Suresh Krishnan 210 Ericsson 212 Email: suresh.krishnan@ericsson.com