idnits 2.17.1 draft-ietf-mtgvenue-iaoc-venue-selection-process-14.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 7, 2018) is 2179 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) == Outdated reference: A later version (-07) exists of draft-ietf-mtgvenue-meeting-policy-04 ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mtgvenue E. Lear, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Best Current Practice May 7, 2018 5 Expires: November 8, 2018 7 IETF Plenary Meeting Venue Selection Process 8 draft-ietf-mtgvenue-iaoc-venue-selection-process-14 10 Abstract 12 The IASA has responsibility for arranging IETF plenary meeting Venue 13 selection and operation. This memo specifies IETF community 14 requirements for meeting venues, including hotels and meeting room 15 space. It directs the IASA to make available additional process 16 documents around that describe the current meeting selection process. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 8, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Venue Selection Objectives . . . . . . . . . . . . . . . . . 3 54 2.1. Core Values . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Venue Selection Non-Objectives . . . . . . . . . . . . . 5 56 3. Meeting Criteria . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Mandatory Criteria . . . . . . . . . . . . . . . . . . . 5 58 3.2. Important Criteria . . . . . . . . . . . . . . . . . . . 6 59 3.3. Other Consideraitons . . . . . . . . . . . . . . . . . . 9 60 4. Documentation Requirements . . . . . . . . . . . . . . . . . 9 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 64 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 10.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 The Internet Administrative Support Activity (IASA) has 75 responsibility for arranging IETF plenary meeting venue selection and 76 operation. The purpose of this document is to guide the IASA in 77 their selection of regions, cities, facilities, and hotels. The IASA 78 applies this guidance at different points in the process in an 79 attempt to faithfully meet the requirements of the IETF community. 80 We specify a set of general criteria for venue selection and several 81 requirements for transparency and community consultation. 83 It remains the responsibility of the IASA to apply their best 84 judgment. The IASA accepts input and feedback both during the 85 consultation process and later (for instance when there are changes 86 in the situation at a chosen location). Any appeals remain subject 87 to the provisions of BCP101 [RFC4071]. As always, the community is 88 encouraged to provide direct feedback to the Nominations Committee 89 (NOMCOM), Internet Engineering Steering Group (IESG), and IAB 90 regarding the discharge of the IASA's performance. 92 Four terms describe the places for which the IETF contracts services: 94 Venue: 95 This is an umbrella term for the city, meeting resources and guest 96 room resources. 98 Facility: 99 The building that houses meeting rooms and associated resources. 100 It may also house an IETF Hotel. 102 IETF Hotels: 103 One or more hotels, in close proximity to the Facility, where the 104 IETF guest room block allocations are negotiated and where network 105 services managed by the IASA (e.g., the "IETF" SSID) are in use. 107 Overflow Hotels: 108 One or more hotels, usually in close proximity to the Facility, 109 where the IETF has negotiated a group rate for the purposes of the 110 meeting. Of particular note is that Overflow Hotels usually are 111 not connected to the IETF network and do not use network services 112 managed by the IASA. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119][RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 2. Venue Selection Objectives 122 2.1. Core Values 124 Some IETF values pervade the selection process. These often are 125 applicable to multiple requirements listed in this document. They 126 are not limited to the following, but at minimum include: 128 Why we meet? 129 We meet to pursue the IETF's mission [RFC3935], partly by 130 advancing the development of Internet-Drafts and RFCs. We also 131 seek to facilitate attendee participation in multiple topics and 132 to enable cross-pollination of ideas and technologies. 134 Inclusiveness: 135 We would like to facilitate the onsite or remote participation of 136 anyone who wants to be involved. Widespread participation 137 contributes to the diversity of perspectives represented in the 138 working sessions 140 Every country has limits on who it will permit within its borders. 141 However the IETF seeks to: 143 1. Minimize situations in which onerous entry regulations 144 inhibit, discourage, or prevent participants from attending 145 meetings, or failing that to distribute meeting locations such 146 that onerous entry regulations are not always experienced by 147 the same attendees; and 149 2. Avoid meeting in countries with laws that effectively exclude 150 people on the basis of race, religion, gender, sexual 151 orientation, national origin, citizenship, or gender identity. 153 Where we meet? 154 We meet in different locations globally, in order to spread the 155 difficulty and cost of travel among active participants, balancing 156 travel time and expense across the regions in which IETF 157 participants are based. Our regional location policy is 158 articulated in [I-D.ietf-mtgvenue-meeting-policy]. 160 Internet Access: 161 As an organization, we write specifications for the Internet, and 162 we use it heavily. Meeting attendees need unfiltered access to 163 the general Internet and their corporate networks. "Unfiltered 164 access" in this case means that all forms of communication are 165 allowed. This includes, but is not limited to, access to 166 corporate networks via encrypted VPNs from the meeting Facility 167 and Hotels, including Overflow Hotels. We also need open network 168 access available at high enough data rates, at the meeting 169 Facility, to support our work, including the support of remote 170 participation. Beyond this, we are the first users of our own 171 technology. Any filtering may cause a problem with that 172 technology development. In some cases, local laws may require 173 some filtering. We seek to avoid such locales without reducing 174 the pool of cities to an unacceptable level by stating a number of 175 criteria below, one mandatory and others important, to allow for 176 the case where local laws may require filtering in some 177 circumstances.[MeetingNet] 179 Focus: 180 We meet to have focused technical discussions. These are not 181 limited to scheduled breakout sessions, although of course those 182 are important. They also happen over meals or drinks -- including 183 a specific type of non-session that we call a "Bar BOF" [RFC6771] 184 - or in side meetings. Environments that are noisy or distracting 185 prevent that or reduce its effectiveness, and are therefore less 186 desirable as a meeting Facility. 188 Economics: 189 Meeting attendees participate as individuals. While many are 190 underwritten by employers or sponsors, many are self-funded. In 191 order to reduce participation costs and travel effort, we 192 therefore seek locations that provide convenient budget 193 alternatives for food and lodging, and which minimize travel 194 segments from major airports to the Venue. Within reason, budget 195 should not be a barrier to accommodation. 197 Least Astonishment and Openness: 198 Regular participants should not be surprised by meeting Venue 199 selections, particularly when it comes to locales. To avoid 200 surprise, the venue selection process, as with all other IETF 201 processes, should be as open as practicable. It should be 202 possible for the community to engage early to express its views on 203 prospective selections, so that the community and the IASA can 204 exchange views as to appropriateness long before a venue contract 205 is considered. 207 2.2. Venue Selection Non-Objectives 209 IETF meeting Venues are not selected or declined with the explicit 210 purposes of: 212 Politics: 213 Endorsing or condemning particular countries, political paradigms, 214 laws, regulations, or policies. 216 Maximal attendance: 217 While the IETF strives to be as inclusive as possible both online 218 and in person, maximal meeting attendance in and of itself is not 219 a goal. It would defeat a key goal of meeting if active 220 contributors with differing points of view did not have the 221 opportunity to resolve their disagreements, no matter how full the 222 rooms. 224 Tourism: 225 Variety in site-seeing experiences. 227 3. Meeting Criteria 229 This section contains the criteria for IETF meetings. It is broken 230 down into three subsections: mandatory criteria, important criteria, 231 and other considerations, each as explained below. 233 3.1. Mandatory Criteria 235 If criteria in this subsection cannot be met, a particular location 236 is unacceptable for selection, and the IASA MUST NOT enter into a 237 contract. Should the IASA learn that a location no longer can meet a 238 mandatory requirement after having entered into a contract, it will 239 inform the community and address the matter on a case by case basis. 241 o The Facility MUST provide sufficient space in an appropriate 242 layout to accommodate the expected number of participants, 243 leadership, and support staff to attend that meeting. 245 o The Facility and IETF Hotels MUST provide wheelchair access to 246 accommodate the number of people who are anticipated to require 247 it. 249 o It MUST be possible to provision Internet Access to the Facility 250 and IETF Hotels that allows those attending in person to utilize 251 the Internet for all their IETF, business, and day to day needs; 252 as well as sufficient bandwidth and access for remote attendees. 253 This includes, but is not limited to, native and unmodified IPv4 254 and IPv6 connectivity, global reachability, and no additional 255 limitation that would materially impact their Internet use. To 256 ensure availability, it MUST be possible to provision redundant 257 paths to the Internet. 259 o The facility MUST prohibit smoking in meeting rooms, interior 260 common spaces and corridors, indoor lobby bars which are open to 261 common spaces and corridors, and indoor restaurants. IETF primary 262 and secondary hotels MUST have blocks of rooms designated as "Non 263 Smoking" guest rooms. 265 3.2. Important Criteria 267 The criteria in this subsection are not mandatory, but are still 268 highly significant. It may be necessary to trade one or more of 269 these criteria off against others. A Venue that meets more of these 270 criteria is on the whole preferable than another that meets fewer of 271 these criteria. Requirements classed as Important can also be 272 balanced across Venue selections for multiple meetings. When a 273 particular requirement in this section cannot be met, the IASA MUST 274 notify the community at the time of the venue announcement. 275 Furthermore, it may be appropriate for the IASA to assist those who, 276 as a result, have been inconvenienced in some way. 278 3.2.1. Venue City Criteria 280 o Travel to the Venue is acceptable based on cost, time, and burden 281 for participants traveling from multiple regions. It is 282 anticipated that the burden borne will be generally shared over 283 the course of multiple years. 285 o The Venue is assessed as favorable for obtaining a host and 286 sponsors. That is, the Meeting is in a location that it is 287 possible and probable to find a host and sponsors. 289 o Travel barriers to entry, including visa requirements, are likely 290 to be such that an overwhelming majority of participants who wish 291 to do so can attend. The term "travel barriers" is to be read 292 broadly by the IASA in the context of whether a successful meeting 293 can be had. 295 o Economic, safety, and health risks associated with this Venue are 296 acceptable. 298 o The selection of the venue comports with 299 [I-D.ietf-mtgvenue-meeting-policy]. 301 3.2.2. Basic Venue Criteria 303 The following requirements relate to the Venue and Facilities. 305 The IETF operates internationally and adjusts to local requirements. 306 Facilities selected for IETF Meetings SHALL have provided written 307 assurance that they are in compliance with local health, safety and 308 accessibility laws and regulations, and will remain in compliance 309 throughout our stay. 311 In addition: 313 o There are sufficient places (e.g., a mix of hallways, bars, 314 meeting rooms, and restaurants) for people to hold ad hoc 315 conversations and group discussions in the combination of spaces 316 offered by the facilities, hotels and bars/restaurants in the 317 surrounding area, within walking distance (5-10 minutes). 319 o The cost of guest rooms, meeting space, meeting food and beverage 320 is affordable, within the norms of business travel. 322 o The Facility is accessible or reasonable accommodations can be 323 made to allow access by people with disabilities. 325 3.2.3. Technical Meeting Needs 327 The following criteria relate to technical meeting needs. 329 o The Facility's support technologies and services -- network, 330 audio-video, etc. -- are sufficient for the anticipated activities 331 at the meeting, or the Facility is willing to add such 332 infrastructure or these support technologies and services might be 333 provided by a third party, all at no -- or at an acceptable -- 334 cost to the IETF. 336 o The IETF Hotel(s) directly provide, or else permit and facilitate, 337 the delivery of a high performance, robust, unfiltered and 338 unmodified Internet service for the public areas and guest rooms; 339 this service is typically included in the cost of the room. 341 3.2.4. Hotel Needs 343 The following criteria relate to IETF Hotels. 345 o The IETF Hotel(s) are within close proximity to each other and the 346 Facility. 348 o The guest rooms at the IETF Hotel(s) are sufficient in number to 349 house 1/3 or more of projected meeting attendees. 351 o Overflow Hotels can be placed under contract, within convenient 352 travel time to and from the Facility and at a variety of guest 353 room rates. 355 o The Facility environs include budget hotels within convenient 356 travel time, cost, and effort. 358 o The IETF Hotel(s) are accessible by people with disabilities. 359 While we mandate wheelchair accessibility, other forms are 360 important, and should be provided to the extent possible, based on 361 anticipated needs of the community. 363 o At least one IETF Hotel or the Facility has a space for use as a 364 lounge, conducive to planned and ad hoc meetings and chatting, as 365 well as working online. There are tables with seating, convenient 366 for small meetings with laptops. These can be at an open bar or 367 casual restaurant. Preferably the lounge area is centrally 368 located, permitting easy access to participants. 370 3.2.5. Food and Beverage 372 It is said that an army travels on its stomach. So too does the 373 IETF. The following criteria relate to food and beverage. 375 o The Facility environs, which includes both onsite, as well as 376 areas within a reasonable walking distance or conveniently 377 accessible by a short taxi ride or by local public transportation, 378 have convenient and inexpensive choices for meals that can 379 accommodate a wide range of dietary requirements. 381 o A range of attendee's health-related and religion-related dietary 382 requirements can be satisfied with robust and flexible onsite 383 service or through access to an adequate grocery. 385 o The Facility environs include grocery shopping that will 386 accommodate a wide range of dietary requirements, within a 387 reasonable walking distance, or conveniently accessible by a short 388 taxi, bus, or subway ride, from the Facility and IETF Hotels. 390 3.3. Other Consideraitons 392 The following considerations are desirable, but not as important as 393 the preceding requirements, and thus should not be traded off for 394 them. 396 o We have something of a preference for an IETF meeting to be under 397 "One Roof". That is, qualified meeting space and guest rooms are 398 available in the same facility. 400 o It is desirable for Overflow Hotels provide reasonable, reliable, 401 unfiltered Internet service for the public areas and guest rooms; 402 this service is included in the cost of the room. 404 o It is desirable to enter into a multi-event contract with the 405 Facility and IETF Hotels or associated hotel chains in case such a 406 contract will either reduce administrative costs, reduce direct 407 attendee costs, or both. 409 o Particularly when we are considering a city for the first time, it 410 is desirable to have someone participate in the site visit who is 411 familiar with both the locale and the IETF. Such a person can 412 provide guidance regarding safety, location of local services, and 413 understanding best ways to get to and from the Venue, and local 414 customs, as well as identify how our requirements are met. 416 4. Documentation Requirements 418 The IETF Community works best when it is well informed. This memo 419 does not specify processes nor who has responsibility for fulfilling 420 our requirements for meetings. Nevertheless, both of these aspects 421 are important. Therefore, the IASA SHALL publicly document and keep 422 current both a list of roles and responsibilities relating to IETF 423 meetings, as well as the selection processes they use in order to 424 fulfill the requirements of the community. 426 5. IANA Considerations 428 This memo asks the IANA for no new parameters. 430 [The RFC-Editor may remove this section prior to publicaiton.] 432 6. Security Considerations 434 This note proposes no protocols, and therefore no new protocol 435 insecurities. 437 7. Privacy Considerations 439 Different places have different constraints on individual privacy. 440 The requirements in this memo are intended to provide for some 441 limited protections that attendees can apply. As meetings are 442 announced, IASA SHALL inform the IETF of any limitations to privacy 443 they have become aware of in their investigations. For example, 444 participants would be informed of any regulatory authentication or 445 logging requirements. This note reveals no personally identifying 446 information apart from its authorship. 448 8. Contributors 450 The following people provided substantial text contributions to this 451 memo: 453 Fred Baker 454 Email: fred.ietf@gmail.com 456 Fred originated this work. 458 Ray Pelletier 459 Email: Rpelletier13@gmail.com 461 Laura Nugent 462 Association Management Solutions 463 Email: lnugent@amsl.com 465 Lou Berger 466 LabN Consulting, L.L.C. 467 Email: lberger@labn.net 469 Ole Jacobsen 470 The Internet Protocol Journal 471 EMail: olejacobsen@me.com 473 Jim Martin 474 INOC 475 Email: jim@inoc.com 477 9. Acknowledgements 479 Additional contributions came from Jari Arkko, Scott Bradner, Alissa 480 Cooper, Dave Crocker, Jordi Palet Martinez, Andrew Sullivan, and 481 other participants in the mtgvenue working group. Those listed in 482 this section or as contributors may or may not agree with the content 483 of this memo. 485 10. References 487 10.1. Normative References 489 [I-D.ietf-mtgvenue-meeting-policy] 490 Krishnan, S., "High level guidance for the meeting policy 491 of the IETF", draft-ietf-mtgvenue-meeting-policy-04 (work 492 in progress), February 2018. 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, 496 DOI 10.17487/RFC2119, March 1997, 497 . 499 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 500 IETF Administrative Support Activity (IASA)", BCP 101, 501 RFC 4071, DOI 10.17487/RFC4071, April 2005, 502 . 504 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 505 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 506 May 2017, . 508 10.2. Informative References 510 [MeetingNet] 511 O'Donoghue, K., Martin, J., Elliott, C., and J. Jaeggli, 512 "IETF Meeting Network Requirements", WEB 513 https://iaoc.ietf.org/ietf-network-requirements.html. 515 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 516 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 517 . 519 [RFC6771] Eggert, L. and G. Camarillo, "Considerations for Having a 520 Successful "Bar BOF" Side Meeting", RFC 6771, 521 DOI 10.17487/RFC6771, October 2012, 522 . 524 Appendix A. Change Log 526 [RFC Editor: Please remove this section prior to publication.] 528 2016-01-12: Initial version 530 2016-01-21: Update to reflect https://iaoc.ietf.org/documents/ 531 VenueSelectionCriteriaJan2016.pdf and 532 https://iaoc.ietf.org/documents/VenueSelectionProcess11Jan16.pdf, 533 accessed from https://iaoc.ietf.org/private/privatemeetings.html. 535 2016-02-23: Reorganize and capture IAOC Meetings Committee 536 discussions. 538 2016-03-03: Final from Design Team. 540 2016-03-17: First update incorporating mtgvenue@ietf.org comments 542 2016-05-20 Updated in accordance with editing by Laura Nugent, Dave 543 Crocker, Lou Berger, Fred Baker, and others. 545 posting as working group draft August 2, 2016 547 Reorganized per Alissa Cooper outline Work in progress. In 548 addition, contributors were re-organized to be authors. 550 2016-10-28 Editor changeover. Further alignment with guidance by 551 Alissa Cooper, Andrew Sullivan and the mtgvenue working group. 552 Many various changes. 554 2016-11-16 Extensive editorial, format and polishing pass. A few 555 substance changes, including food section. 557 2016-11-30 Additions based on working group meeting and off-list 558 discussions; more editorial and format hacking. 560 2016-12-24 Various clarifying bits to provide some glue between the 561 high-level 'objectives' and the detailed criteria and roles, per 562 suggestions fronm Lear. Editorial changes, per 12/27 response to 563 Cooper. Refined uses of 'Facility' and 'Venue', per 12/4 response 564 to Carpenter; also added Carpenter 'lounge' text. Moved community 565 consultation to a separate criterion; removed 'acceptable to the 566 IETF Community from the 2 entries that had it. Removed Post- 567 Seroul Revisions and Text Carried Forward. 569 2016-12-24 Address comments made on list by Stephen Farrell 570 . Minor text change in Section 5. 571 Replaced links in sections 5.3 and 5.5. 573 2017-03-12 Add openness comment as requested by Stephen Farrell. 574 Add statement about 4071 as proposed by Brian and modified by 575 Jari. Elaborated on what "unfiltered" means, based on discussion 576 between Eliot and Stephen. Preface to Section 5 as discussed 577 between Lou and Stephen. Slight editorial tweak to that by Eliot. 578 IETF operates internationally, as proposed by Brian. 580 2017-04-18 Add new introductory text. Sharpen mandatory definition. 581 Split first criteria into two, and reword them to be more 582 actionable. Remove net cash positive requirement. Change many 583 critera from Mandatory to Important. Remove consensus text. 584 Modify chapeau. Add some normative MUSTs in Section 5, and 585 restructure Section 5.5. A bunch of other stuff as well. Use 586 diff. 588 2017-05-14 Happy Mother's Day. This version removes the tabular 589 format of requirements, moves mandatory requirements up front, 590 adds a desiderata section, adds a mandatory filtering requirement, 591 consolidates introductory text, moves procedural requirements into 592 Section 5, removes the definition of Headquarters Hotel, removes 593 the MUST in late changes, and adds a desire for a local 594 participant in site selection. 596 2017-09-12 These are last call edits. Big change is around Internet 597 requirements. Also, address Andrew Sullivan comments, as well as 598 SM comments. Brian Carpenter big scrub on IAOC to IASA. 600 2017-10-20 Final edits from WGLC based on Laura Nugent's review. 601 Most are editorial for clarity. Also, remove large table and link 602 to the live copy. 604 2018-01-10 Changes based on AD review. 606 2018-02-02 Changes based on genart review and IETF last call. 608 2018-05-07 Several versions of changes. Based on reorg of meetings 609 committee, Section 4 and 5 moved out. Also, final LC comments 610 addressed. In particular: no smoking added. Reference to RFC8174 611 added. Reference to meeting policy doc added. 613 Author's Address 614 Eliot Lear (editor) 615 Cisco Systems 616 Richtistrasse 7 617 Wallisellen CH-8304 618 Switzerland 620 Phone: +41 44 878 9200 621 Email: lear@cisco.com