idnits 2.17.1 draft-manycouches-completely-virtual-meetings-04.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 11, 2017) is 2655 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 manycouches D. York 3 Internet-Draft Internet Society 4 Intended status: Informational January 11, 2017 5 Expires: July 15, 2017 7 Thoughts on Completely Virtual IETF Meetings 8 draft-manycouches-completely-virtual-meetings-04 10 Abstract 12 This document captures initial thoughts about having IETF meetings 13 that are completely virtual. It explores the issues involved with 14 both a "planned" virtual meeting and an "emergency" virtual meeting. 15 The intent is to evolve this document to provide answers to the 16 questions posed throughout the text. This is currently a thought 17 experiment. There are no current plans to hold a completely virtual 18 IETF meeting. 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 July 15, 2017. 37 Copyright Notice 39 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Why Do IETF Meetings Take Place? . . . . . . . . . . . . 4 56 1.2. Why Hold a Completely Virtual IETF Meeting? . . . . . . . 4 57 1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4 58 2. Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Meeting Structure . . . . . . . . . . . . . . . . . . . . 5 60 2.2. Timezones . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Deadlines . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.4. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.5. Breaks . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.6. Tutorials . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.7. Hackathon / Code Sprint . . . . . . . . . . . . . . . . . 6 66 2.8. Other Physical Meeting Elements . . . . . . . . . . . . . 6 67 2.9. Sessions by non-IETF groups . . . . . . . . . . . . . . . 7 68 2.10. Remote Hubs . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. User Journey / Experience . . . . . . . . . . . . . . . . . . 7 70 3.1. Planning time to participate . . . . . . . . . . . . . . 7 71 3.2. Registration / sign-up . . . . . . . . . . . . . . . . . 8 72 3.3. Side meetings . . . . . . . . . . . . . . . . . . . . . . 8 73 3.4. Hallway conversations . . . . . . . . . . . . . . . . . . 8 74 3.5. Unstructured time . . . . . . . . . . . . . . . . . . . . 8 75 3.6. Participating in multiple sessions . . . . . . . . . . . 8 76 3.7. Serendipity - discovering other users . . . . . . . . . . 8 77 3.8. Building relationships . . . . . . . . . . . . . . . . . 8 78 3.9. Calendars for users . . . . . . . . . . . . . . . . . . . 8 79 3.10. Voting / Hums . . . . . . . . . . . . . . . . . . . . . . 9 80 3.11. Microphone lines . . . . . . . . . . . . . . . . . . . . 9 81 3.12. Disruptive Behavior . . . . . . . . . . . . . . . . . . . 9 82 3.13. Mentoring . . . . . . . . . . . . . . . . . . . . . . . . 9 83 3.14. Inclusivity . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.15. T-Shirts . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4. Technical Considerations . . . . . . . . . . . . . . . . . . 10 86 4.1. Infrastructure . . . . . . . . . . . . . . . . . . . . . 10 87 4.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . 10 88 4.3. Backup connectivity . . . . . . . . . . . . . . . . . . . 10 89 4.4. Persistent chat . . . . . . . . . . . . . . . . . . . . . 10 90 4.5. Authentication . . . . . . . . . . . . . . . . . . . . . 11 91 4.6. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 4.7. Network Operation Center (NOC) . . . . . . . . . . . . . 11 93 5. Administrative . . . . . . . . . . . . . . . . . . . . . . . 11 94 5.1. Centralized Resources . . . . . . . . . . . . . . . . . . 11 95 5.2. Finances . . . . . . . . . . . . . . . . . . . . . . . . 11 96 5.2.1. Initial Investment . . . . . . . . . . . . . . . . . 11 97 5.2.2. Registration Fees . . . . . . . . . . . . . . . . . . 12 98 5.2.3. Sponsorships . . . . . . . . . . . . . . . . . . . . 12 99 5.2.4. Long-term impact . . . . . . . . . . . . . . . . . . 13 100 5.3. Legal . . . . . . . . . . . . . . . . . . . . . . . . . . 13 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 102 6.1. Availability . . . . . . . . . . . . . . . . . . . . . . 13 103 6.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 13 104 6.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 106 8. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 14 107 8.1. Learning from others . . . . . . . . . . . . . . . . . . 14 108 8.2. Trial? . . . . . . . . . . . . . . . . . . . . . . . . . 14 109 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 110 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 111 Appendix B. Development Note . . . . . . . . . . . . . . . . . . 15 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 114 1. Introduction 116 What would a "completely virtual" IETF meeting look like? What would 117 be issues? What would be the advantages? How could it work? 119 The "manycouches" design team was convened to explore these issues 120 and understand what might be involved in holding a completely virtual 121 meeting. On 20 July 2016, members met with the IESG for a joint 122 discussion at the IETF 96 meeting in Berlin. The team met again at 123 IETF 97 in Seoul. This document outlines many of the key issues and 124 questions for discussion that emerged out of those meetings as well 125 as mailing list conversations. 127 Discussions identified two types of potential meetings the IETF could 128 have that would be completely virtual: 130 1. PLANNED VIRTUAL MEETING - A "regular" meeting of the IETF that 131 would be planned to be completely virtual. 133 2. EMERGENCY VIRTUAL MEETING - There could be a situation where a 134 planned physical meeting suddenly needs to be virtual due to 135 physical or political situations. For example, a natural 136 disaster shortly before a meeting might cause people to not be 137 able to attend. 139 Tools and processes may be very similar between the two types of 140 meetings. A key difference is that for an "emergency" meeting there 141 may be the desire to replicate the planned schedule of the physical 142 meeting as closely as possible. 144 It is unclear if the IETF might ever choose to hold a planned virtual 145 meeting, but this document is designed to facilitate the discussion 146 around what that might look like. A desire is that some of this 147 development may help with improving the current experience for remote 148 attendees to today's physical IETF meetings. It may also be the case 149 that some kind of "hybrid" meeting emerges with physical meetings 150 taking place in multiple locations with virtual participants joining 151 in remotely. 153 It is also worth noting that in discussions to date the sense has 154 been that even if we held a completely virtual meeting, it would only 155 happen once out of several meetings. There would still be multiple 156 physical IETF meetings during the year. 158 1.1. Why Do IETF Meetings Take Place? 160 [It may be good to insert some text here about WHY we have IETF 161 meetings and what the overall goals are. Both as a reminder of the 162 point of the meetings and potentially to frame thinking about how we 163 might move toward those goals by trying doing things a bit 164 differently.] 166 1.2. Why Hold a Completely Virtual IETF Meeting? 168 [At some point in the maturity of this document it would be valuable 169 to discuss the benefits and challenges of a completely virtual 170 meeting. Before that summary can be developed, though, further 171 investigation and development needs to happen. At a very high level, 172 one idea is that a completely virtual meeting might make the meeting 173 more accessible to more people in terms of schedules, lack of travel 174 and reduced costs. However, all of that thinking need considerably 175 more exploration. Several participants in discussions have voiced 176 the opinion that replacing physical IETF meetings will be close to 177 impossible. This document is being developed to explore all of these 178 issues.] 180 1.3. Conventions and Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC 2119 [RFC2119]. 186 Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", 187 "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU 188 WON'T)*" in this document are to interpreted as described in RFC 6919 189 [RFC6919]. 191 2. Program 193 2.1. Meeting Structure 195 With a completely virtual meeting, the structure of the meeting does 196 not have to comply with the traditional IETF meeting schedule. It 197 could, for instance, stretch out over the entire 24 hours of a day. 198 Questions for discussion include: 200 o Is the meeting still structured over a week? 202 o Do the meetings still exist within certain hours? 204 o Do multiple meetings exist at the same time as they do now? 206 Again, in the case of an unplanned "emergency" virtual meeting the 207 desire may be to stick with the already-planned schedule. But for a 208 planned virtual meeting the schedule can be open for discussion. 210 There was some discussion that a meeting could span more than the 211 traditional week. However, the counterpoint is that keeping it 212 within a week gives a focused block of time that people could 213 allocate for participation in the virtual event. 215 2.2. Timezones 217 What timezone does a virtual meeting operate in? Or does it operate 218 in multiple timezones? 220 One suggestion was that each working group might choose its own 221 timezone based on the best timezone for the main contributors and 222 leaders. (Although this might then limit participation from other 223 areas of the world.) 225 This timezone issue was identified by multiple participants as the 226 hardest aspect of planning a virtual meeting. 228 2.3. Deadlines 230 What do deadlines look like for a completely virtual meeting? Are 231 the deadlines for agendas and drafts kept as they are for a regular 232 meeting? 234 2.4. Plenaries 236 What does a plenary look like in a virtual meeting? The same large 237 session as today? 239 2.5. Breaks 241 There are breaks planned throughout the days of a physical IETF 242 meeting to enable people to move between sessions and to have 243 refreshments and restroom breaks. Similarly there are longer breaks 244 for lunch. 246 How are breaks structured in a completely virtual meeting? 248 o Can they be shorter? 250 o Do you need a longer "lunch break"? Or does that make no sense? 252 2.6. Tutorials 254 On the Sunday starting an IETF week we commonly have a series of 255 tutorials. Are those still part of the program for a virtual 256 meeting? 258 2.7. Hackathon / Code Sprint 260 The Hackathon and Code Sprint have become popular activities before a 261 physical meeting. Would they still exist for a virtual meeting? 263 2.8. Other Physical Meeting Elements 265 In a typical IETF physical meeting, there are other meetings and 266 activities that occur alongside the meetings of Working Groups and 267 BOFs. These include: 269 o Newcomers Meet and Greet 271 o Welcome Reception 273 o Bits-N-Bites 275 o Thursday Lunch Speaker Series 277 o Social Event 279 Do any of these additional sessions still make sense in a virtual 280 meeting? 282 The Thursday Lunch Speaker Series (by the Host organization) could 283 continue as webinar-style presentations. But the other elements 284 involve face-to-face interaction that would be difficult in a virtual 285 setting. 287 2.9. Sessions by non-IETF groups 289 Other organizations sometimes hold meetings during the time of the 290 IETF physical meeting and often use the same venue. For example, the 291 Internet Society usually offers an "ISOC@IETF Briefing Panel" during 292 the Tuesday lunch break. At some IETF meetings groups have shown 293 films or scheduled other meetings. These are not IETF meetings, but 294 make use of the opportunity of having the IETF attendees available. 296 Do these sessions still make sense? Would we offer the IETF virtual 297 meeting infrastructure to groups to use when it is not being used for 298 IETF meetings? 300 2.10. Remote Hubs 302 In recent years there has been an effort to establish "remote hubs" 303 where groups of IETF members get together and participate remotely 304 from that physical location. Would that continue as an option? 306 Could the virtual meeting perhaps involve connecting together a 307 series of remote hubs? (And if so, does this then again create a 308 better experience for people who can go to a hub than for those who 309 cannot?) 311 3. User Journey / Experience 313 What is the experience of an "IETF attendee" in a virtual meeting? 314 How does he or she experience the event? 316 How could attendees be most effective in getting work done in a 317 virtual setting? 319 3.1. Planning time to participate 321 It was noted that remote attendees should think about how they block 322 off time needed to participate in the meetings. This may be 323 challenging depending upon timezones and other activities. 325 An open question is whether attendees might be able to get time from 326 their employer to participate in the virtual meeting. If you fly 327 somewhere to participate, it is clear that you are "away" and 328 participating in the meeting. If you are still at your home or 329 office, it is harder for others to consider you "away". 331 3.2. Registration / sign-up 333 What is the registration experience like? How do they initially 334 "sign in" as an attendee? 336 3.3. Side meetings 338 It is quite common for groups to decide during an IETF meeting to go 339 off and have a side meeting. 341 o How can this capability be reproduced in a virtual environment? 343 o Could the system allow people to create ad hoc meetings in some 344 fashion? 346 3.4. Hallway conversations 348 The casual hallway conversations are a key component of IETF physical 349 meetings. How can some version of this capacity be made available? 351 3.5. Unstructured time 353 How do you incorporate some concept of "unstructured" time where 354 people can meet and connect? 356 3.6. Participating in multiple sessions 358 It is currently possible for remote participants to join into 359 multiple working group sessions at the same time. Users simply 360 connect using multiple browser windows, multiple chat rooms or 361 multiple computers. How does this impact users' experience? 363 3.7. Serendipity - discovering other users 365 Part of a physical meeting involves discovering other people with 366 common interests or backgrounds. How do you help people find others? 368 3.8. Building relationships 370 So much of the relationship-building that helps get work done happens 371 through the informal side meetings, going out to dinner, going off in 372 groups. How can any of this be replicated remotely? 374 3.9. Calendars for users 376 Could there be a way for users to be able to share when they are 377 going to be in different sessions? Or when they would be available 378 to "hang out" virtually? 379 What level of "presence" could be made visible for virtual attendees? 381 3.10. Voting / Hums 383 What is the best way to have votes or hums in a virtual meeting? 384 Most current audio conference systems would not make an actual audio 385 hum possible. Votes in a chat could be possible but the lag time 386 associated with remote connections would need to be taken into 387 account. 389 Some kind of system where votes take place over a period of time may 390 need to be developed or used. This, though, does then introduce a 391 delay into the meeting while there is a wait for the vote. 393 3.11. Microphone lines 395 How do "mic lines" work in a completely virtual meeting? Would this 396 in fact be a benefit as all attendees would be in the same queue? 398 3.12. Disruptive Behavior 400 How do we deal with disruptive behavior in a virtual meeting? It can 401 and does happen in meetings - and could potentially happen more 402 easily in a virtual evironment where people cannot be physically 403 stopped from going to a mic or could be removed from a room. 405 What is the process to exclude someone who is being disruptive? Do 406 we need moderators to be able to step in and mute or disable 407 someone's connection? Who makes the decision that someone's behavior 408 is disruptive? 410 3.13. Mentoring 412 How would the "mentor" program work in a virtual meeting? The same 413 as with a physical meeting? 415 3.14. Inclusivity 417 How do you bring new people into sessions? How do people learn about 418 side meetings? About hallway conversations? 420 3.15. T-Shirts 422 Many attendees value the T-shirts that are usually provided for each 423 IETF. Without a physical meeting it could be challenging and costly 424 to distribute T-shirts to attendees. 426 T-shirts are currently funded by the Host of the physical IETF 427 meeting. If there is no Host, or if the Host chooses not to fund a 428 T-shirt, there may be no T-shirt. 430 With a virtual meeting it may be that if there is a Host (see 431 "Sponsorships" below), the Host would have the same option as the 432 physical meeting - to provide a T-shirt or not. The Host could then 433 decide how they would distribute the T-shirt. 435 4. Technical Considerations 437 Many technical questions need to be discussed. 439 4.1. Infrastructure 441 What is the infrastructure used to host a completely virtual meeting? 442 Are current systems (ex. Meetecho, Jabber chat rooms, audio streams) 443 sufficient? Would new infrastructure need to be established? 445 What kind of bandwidth would need to be available for the servers 446 hosting the system? 448 How would we handle connecting large numbers of people at the same 449 time? 451 4.2. Capabilities 453 Do virtual attendees have video connections? voice? chat? What kind 454 of bandwidth would need to be available on the client end? 456 Recommendations should be developed for client-end infrastructure. 457 (To fully participate you need X, Y and Z...) 459 4.3. Backup connectivity 461 Virtual attendees need to have some kind of "backup connection" in 462 case their main Internet connection goes out. For instance, a PSTN 463 connection for calling into a session. (This implies that the system 464 hosting the virtual conference can accept connections through 465 different mechanisms.) 467 4.4. Persistent chat 469 Whatever system is used should have some kind of "persistent chat" so 470 that when people connect into a given "room" they can scroll back and 471 read through the history. Potentially that history might also 472 include audio or video links. 474 4.5. Authentication 476 Today anyone can connect to the remote participation aspects of an 477 IETF meeting. No authentication is required to join a jabber chat 478 room, listen to an audio stream or connect to a Meetecho session. 479 Would that need to change? Would "registration" give you a login to 480 whatever system was used for the meeting? Would you not be able to 481 participate without those login credentials? 483 4.6. Audio 485 How do we address issues of lag, stutter, echo and other artifacts of 486 current audio conferencing systems? 488 Is there a "minimum voice quality" level that is acceptable? (George 489 Michaelson has suggested the telco QDU concept is something to 490 consider.) 492 4.7. Network Operation Center (NOC) 494 Where does the NOC "exist" for a completly virtual meeting? What is 495 its role? 497 5. Administrative 499 The long-term impact of an idea such as this needs a great deal of 500 further thought. 502 5.1. Centralized Resources 504 What is the impact of a virtual meeting on centralized resources such 505 as support staff? What is the full role of the Secretariat during 506 the meeting? 508 5.2. Finances 510 The financial model of a completely virtual meeting needs to be 511 understood. What would be the financial costs associated with a 512 meeting? 514 5.2.1. Initial Investment 516 Would there need to be an initial investment in infrastructure for 517 the first completely virtual meeting? Would there then be lower 518 costs for the next virtual meeting? 520 5.2.2. Registration Fees 522 Would we charge the same amount to attendees as a regular meeting? 524 Lou Berger sent the following suggestions to the list related to 525 registration fees: 527 1. Remote audio feed and jabber participation should continue to be 528 unpaid and unregistered as now 530 2. Access to session audio and video recordings should continue to 531 be published as now, without fee or registration 533 3. Remote video/audio - registration should be per individual 534 participant (i.e., anyone that speaks/presents) perhaps having 535 hubs include some number of participants. 537 4. Non-registered/anonymous video (meetecho) listeners should be 538 allowed, but their mic/text input should be disabled. 540 5.2.3. Sponsorships 542 How do sponsorships work with a completely virtual meeting? Would 543 sponsorships be required at the same level as the physical meetings? 545 If a virtual meeting is sponsored, how is the sponsor given the 546 visibility that is currently given with a physical meeting? For 547 instance, with the signage, T-shirts, plenary slides, etc. 549 In particular, is there a sponsor designated as the "Host" of the 550 IETF meeting? The Host for physical meetings receives benefits 551 including: 553 o Prominent mention in materials and promotion of the IETF meeting. 555 o The "host presentation" speaking slot during the plenary. 557 o The "Thursday Lunch Speaker Series" time for whatever they wish to 558 present. 560 o Mention on the T-shirt for the event (if the Host chooses to fund 561 the creation of a T-shirt). 563 Would we have a "Host" for a virtual meeting? 565 5.2.4. Long-term impact 567 If we were successful in holding a completely virtual meeting, would 568 companies no longer be willing to send attendees to physical 569 meetings? In other words, would the first one start us on a path 570 toward having all meetings in this fashion? (And are we okay with 571 that?) 573 5.3. Legal 575 How do we ensure all attendees, coming in at all times, see and agree 576 to the Note Well statement? 578 6. Security Considerations 580 There are many considerations related to security and privacy that 581 need to be factored in to a virtual meeting. 583 6.1. Availability 585 How do we ensure that an attack such as a distributed denial of 586 service (DDoS) doesn't take out the entire virtual meeting? What 587 about an attack against a particular region? 589 Similarly, how do we protect against disruption caused by groups on 590 the Internet who may simply want to disrupt the meeting for the fun 591 of it? (See the section on "Authentication" earlier.) 593 6.2. Integrity 595 How do you know that the person who is logged into whatver system is 596 used is in fact who they say they are? In a physical meeting: 598 o We can see the person and physically identify them. 600 o Users wear name badges that were issued at registration time. 602 o There are typically other people who may know many individuals. 604 How are these physical considerations replicated in a virtual 605 meeting? 607 6.3. Privacy 609 What level of privacy protection would be needed for conversations? 610 for user information? Much of the IETF's work is all done on public 611 email lists and archived remote sessions. What level of privacy is 612 needed? 614 7. IANA Considerations 616 Are there any IANA considerations associated with a virtual meeting? 618 8. Next Steps 620 With this initial document published, the intent now is to go back 621 and start to fill in the sections with possible ideas about how the 622 questions might be answered. 624 8.1. Learning from others 626 Suggestions were made to investigate what lessons can be learned from 627 work by other organizations on virtual meetings. Initial suggestions 628 included: 630 o The Internet Society has now hosted two (2015 and 2016) global 631 "InterCommunity" events bringing together ISOC members from around 632 the world. The 2016 event, in particular, was designed to be a 633 virtual event. 635 o The conference industry has been exploring virtual and/or "hybrid" 636 meetings. There may be value here. 638 o Universities and specifically Internet2 may have some experience. 640 o George Michaelson stated: "Van Jacobsen did a lot of work on 641 meeting behaviour online in the MBONE days, working on the 642 whiteboard and vat. He has made observations about weighted-sum 643 voting, speaking controls, inheritence of the state of the 644 meeting." 646 8.2. Trial? 648 How would it be possible to do a "trial run" of a virtual meeting? 650 9. Normative References 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 658 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 659 DOI 10.17487/RFC6919, April 2013, 660 . 662 Appendix A. Acknowledgements 664 This document reflects the input of many people who participated in 665 both the manycouches design team as well as the discussion with the 666 IESG on 20 July 2016 at IETF 96 in Berlin. Another discussion was 667 help among design team members on 17 Nov 2016 at IETF 97 in Seoul. 668 Other discussions on the manycouches mailing list also informed this 669 document. The author would specifically like to thank Lou Berger, 670 Benoit Claise, Stephen Farrell, George Michaelson and Greg Wood for 671 their input. 673 Appendix B. Development Note 675 This document is being developed using a repository on Github at: 677 o 680 Comments, issues and pull requests are welcome. 682 Author's Address 684 Dan York 685 Internet Society 686 Keene, NH 687 USA 689 Email: york@isoc.org