idnits 2.17.1 draft-sullivan-mtgvenue-decisions-00.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 8, 2016) is 2842 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MTGVENUE A. Sullivan 3 Internet-Draft Dyn, Inc. 4 Intended status: Informational A. Cooper 5 Expires: January 9, 2017 Cisco Systems 6 July 8, 2016 8 Prioritized Objectives for Making Decisions in Selecting a Meeting Venue 9 draft-sullivan-mtgvenue-decisions-00 11 Abstract 13 Selecting a site for an IETF meeting necessarily involves balancing 14 various factors about the site and the goals of the IETF meeting. 15 Those who are faced with choosing a site need guidance on how to 16 prioritize objectives in making such decisions, since no algorithm is 17 possible. This memo provides a set of such objectives in order of 18 importance. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 9, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2.1. Inclusiveness . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Co-location of attendees . . . . . . . . . . . . . . . . 3 58 2.3. Network access . . . . . . . . . . . . . . . . . . . . . 4 59 2.4. Safety and security . . . . . . . . . . . . . . . . . . . 4 60 2.5. Affordability . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Non-Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. One roof . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Maximal attendance . . . . . . . . . . . . . . . . . . . 4 64 3.3. Geographic outreach . . . . . . . . . . . . . . . . . . . 5 65 4. Informative References . . . . . . . . . . . . . . . . . . . 5 66 Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 5 67 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 As [I-D.baker-mtgvenue-iaoc-venue-selection-process] makes clear, 73 there are myriad factors to balance in choosing an IETF meeting 74 venue. While that document outlines some important principles at 75 work in considering the factors, it offers only guidance about how to 76 decide among competing considerations. 78 This memo offers a list of objectives, in descending order of 79 importance, in an attempt to guide decision-makers. These are 80 objectives, not rules, and are intended to guide decisions in a way 81 that encourages the productivity and comity of the IETF community. 83 It is expected that the list will be initially controversial. It is 84 offered as a proposal in order to determine whether the community has 85 collective preferences. Expression of such collective preferences 86 can help those who are making venue selections be confident that they 87 understand what the community is likely to want. If it becomes clear 88 that the community cannot really come to a conclusion about how to 89 order these sorts of objectives, that too is information for those 90 undertaking venue selection. 92 2. Objectives 93 2.1. Inclusiveness 95 The purpose of an IETF meeting is above all to support the standards- 96 development work that is undertaken by IETF participants. Therefore, 97 when selecting venues, maximal inclusiveness is paramount, and must 98 trump other considerations. Maximizing inclusiveness carries a 99 number of implications: 101 Legal exclusions: Formal legal exclusions or differential treatment 102 by authorities in a candidate destination, on the basis of age, 103 gender or gender identity, sexuality, marital status, political 104 views, racial background, nationality, countries previously 105 visited, or any other category of irrelevant discrimination, in 106 general ought to disqualify a site from candidacy. Informal but 107 widely-experienced (or widely-announced) persistent discrimination 108 of the same sort, particularly at the point of immigration, should 109 also be treated as an extremely negative consideration, but is not 110 the same as formal legal sanction against an identifiable group. 112 Accessibility: IETF contributors have different physical abilities. 113 An acceptable venue must accommodate the ranges of physical 114 ability found across the community. This means that attendance at 115 every session and accommodation in meeting hotels must be a 116 practical possibility for those using a variety of assistive 117 devices. 119 Distribution of travel difficulty and cost: The composition of IETF 120 contributors changes over time, and the difficulty and cost of 121 travel ought to be shared throughout the community. This includes 122 difficulties relating to long journeys, different customs in modes 123 of travel, and cultural adjustment to local norms of visitor 124 behaviour. 126 Predictions are hard, especially about the future: Legal, political, 127 and economic realities sometimes change after an agreement is 128 signed, and nobody expects infallible predictions. The goal is 129 still maximal inclusiveness, even if that goal can be only 130 imperfectly realised. 132 2.2. Co-location of attendees 134 The IETF does not meet to make decisions: those are made on mailing 135 lists. The reason for the in-person meetings is twofold. First, it 136 is to address issues that can be better solved in person because of 137 the way in-person communication can often dissolve misunderstanding 138 more quickly than written communication can. Second, it is to 139 encourage the development of social bonds and informal understanding 140 so that later written communication can be easier. 142 Accordingly, sites to be selected must provide the necessary support 143 for informal interaction and random group work. In practice, this 144 means that: 146 o Venues need to be in urban areas in order to accommodate a wide 147 range of opportunities for these kinds of interaction. 149 o Meeting hotels need to be in close proximity to each other and the 150 venue. 152 2.3. Network access 154 Unfettered high-bandwidth access to the entire Internet, from all the 155 hotels associated with the meeting, is a necessary criterion for a 156 successful meeting. It should be treated as an extremely negative 157 consideration were mobile networks outside the hotels to be subject 158 to significant filtering or interference. 160 2.4. Safety and security 162 In keeping with the objective of inclusiveness noted in Section 2.1, 163 an acceptable venue will be in general safe for individuals. Health 164 risks and issues of safety from violence or personal crime are to be 165 regarded as worse than issues of crimes against property. 167 2.5. Affordability 169 Many IETF participants fund their own way to meetings, and many 170 others have limited employer support for travel. With the 171 understanding that the facilities necessary to achieve the goals of 172 meeting in person at all cannot be sacrificed, the cost to meeting 173 attendees for accommodation should be minimized. 175 3. Non-Objectives 177 3.1. One roof 179 While it can be convenient to hold a meeting in a venue under "one 180 roof" (e.g. a conference centre with an attached hotel, or a large 181 hotel with many meeting rooms), it is a secondary goal and may be 182 sacrificed whenever it is in tension with goals in Section 2. 184 3.2. Maximal attendance 186 Because the IETF garners a significant portion of its revenue from 187 IETF meeting fees, there is considerable incentive for decision- 188 makers to prefer a venue that will attract more attendees. It is 189 important to resist this temptation: a larger meeting in which key 190 contributors could not make it is not a better meeting; neither is 191 one with a lot of "tourists". 193 3.3. Geographic outreach 195 The IETF moves its meetings around to ensure that those who can 196 participate in person at the meetings share the difficulty and cost 197 of travel. The point of such moving is emphatically not to find new 198 or interesting places to visit, or to undertake outreach to new 199 communities who would not otherwise participate in the IETF. 201 4. Informative References 203 [I-D.baker-mtgvenue-iaoc-venue-selection-process] 204 Baker, F., "IAOC Plenary Meeting Venue Selection Process", 205 draft-baker-mtgvenue-iaoc-venue-selection-process-03 (work 206 in progress), July 2016. 208 Appendix A. Discussion Venue 210 This Internet-Draft is offered for discussion in the IETF MTGVENUE 211 working group, and on its mailing list 213 Appendix B. Change History 215 00: 217 * Initial version 219 Authors' Addresses 221 Andrew Sullivan 222 Dyn, Inc. 223 150 Dow St 224 Manchester, NH 03101 225 U.S.A. 227 Email: asullivan@dyn.com 229 Alissa Cooper 230 Cisco Systems 231 707 Tasman Drive 232 Milpitas, CA 95305 233 U.S.A. 235 Email: alcoop@cisco.com