manycouches D. York Internet-Draft Internet Society Intended status: Informational October 31, 2016 Expires: May 4, 2017 Thoughts on Completely Virtual IETF Meetings draft-manycouches-completely-virtual-meetings-01 Abstract This document captures initial thoughts about having IETF meetings that are completely virtual. It explores the issues involved with both a "planned" virtual meeting and an "emergency" virtual meeting. The intent is to evolve this document to provide answers to the questions posed throughout the text. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. York Expires May 4, 2017 [Page 1] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4 2. Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Meeting Structure . . . . . . . . . . . . . . . . . . . . 5 2.2. Timezones . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Deadlines . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Tutorials . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Hackathon / Code Sprint . . . . . . . . . . . . . . . . . 6 2.7. Remote Hubs . . . . . . . . . . . . . . . . . . . . . . . 6 3. User Journey / Experience . . . . . . . . . . . . . . . . . . 6 3.1. Registration / sign-up . . . . . . . . . . . . . . . . . 6 3.2. Side meetings . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Hallway conversations . . . . . . . . . . . . . . . . . . 7 3.4. Unstructured time . . . . . . . . . . . . . . . . . . . . 7 3.5. Participating in multiple sessions . . . . . . . . . . . 7 3.6. Serendipity - discovering other users . . . . . . . . . . 7 3.7. Voting / Hums . . . . . . . . . . . . . . . . . . . . . . 7 3.8. Microphone lines . . . . . . . . . . . . . . . . . . . . 7 3.9. Disruptive Behavior . . . . . . . . . . . . . . . . . . . 7 3.10. Mentoring . . . . . . . . . . . . . . . . . . . . . . . . 8 3.11. Inclusivity . . . . . . . . . . . . . . . . . . . . . . . 8 3.12. T-Shirts . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Technical Considerations . . . . . . . . . . . . . . . . . . 8 4.1. Infrastructure . . . . . . . . . . . . . . . . . . . . . 8 4.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 8 4.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Network Operation Center (NOC) . . . . . . . . . . . . . 9 5. Administrative . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Centralized Resources . . . . . . . . . . . . . . . . . . 9 5.2. Finances . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Initial Investment . . . . . . . . . . . . . . . . . 9 5.2.2. Registration Fees . . . . . . . . . . . . . . . . . . 9 5.2.3. Sponsorships . . . . . . . . . . . . . . . . . . . . 10 5.2.4. Long-term impact . . . . . . . . . . . . . . . . . . 10 5.3. Legal . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.1. Availability . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Learning from others . . . . . . . . . . . . . . . . . . 11 York Expires May 4, 2017 [Page 2] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 8.2. Trial? . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Appendix B. Development Note . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction What would a "completely virtual" IETF meeting look like? What would be issues? What would be the advantages? How could it work? The "manycouches" design team was convened to explore these issues and understand what might be involved in holding a completely virtual meeting. On 20 July 2017, members met with the IESG for a joint discussion at the IETF 96 meeting in Berlin. This document outlines many of the key issues and questions for discussion that emerged out of that Berlin meeting as well as mailing list conversations. Discussions identified two types of potential meetings the IETF could have that would be completely virtual: 1. PLANNED VIRTUAL MEETING - A "regular" meeting of the IETF that would be planned to be completely virtual. 2. EMERGENCY VIRTUAL MEETING - There could be a situation where a planned physical meeting suddenly needs to be virtual due to physical or political situations. For example, a natural disaster shortly before a meeting might cause people to not be able to attend. Tools and processes may be very similar between the two types of meetings. A key difference is that for an "emergency" meeting there may be the desire to replicate the planned schedule of the physical meeting as closely as possible. It is unclear if the IETF might ever choose to hold a planned virtual meeting, but this document is designed to facilitate the discussion around what that might look like. A desire is that some of this development may help with improving the current experience for remote attendees to today's physical IETF meetings. It may also be the case that some kind of "hybrid" meeting emerges with physical meetings taking place in multiple locations with virtual participants joining in remotely. York Expires May 4, 2017 [Page 3] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 1.1. Benefits Proponents of planned virtual meetings point to benefits such as: o No requirement to travel, removing an economic issue for many. o All participants are on an equal footing (versus current situation where physical participants have more interaction capability than remote attendees). o Ability to think differently about how the schedule of the meeting might look. o Potentially making participation accessible to more people by changes in the registration fees. (See Finance discussion below.) The sections below outline many of the questions and ideas, some of which may be benefits. 1.2. Challenges There are many challenges with hosting a completely virtual meeting. Some key issues are: o Inability to have the "high bandwidth" conversations enabled by face-to-face meetings. o No ability to have "hallway conversations" and casual meetings with other participants. The remainder of the document outlines many of the challenges and associated questions. Several participants voiced the opinion that replacing a physical meeting would be pretty much impossible. 1.3. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU WON'T)*" in this document are to interpreted as described in RFC 6919 [RFC6919]. York Expires May 4, 2017 [Page 4] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 2. Program 2.1. Meeting Structure With a completely virtual meeting, the structure of the meeting does not have to comply with the traditional IETF meeting schedule. It could, for instance, stretch out over the entire 24 hours of a day. Questions for discussion include: o Is the meeting still structured over a week? o Do the meetings still exist within certain hours? o Do multiple meetings exist at the same time as they do now? Again, in the case of an unplanned "emergency" virtual meeting the desire may be to stick with the already-planned schedule. But for a planned virtual meeting the schedule can be open for discussion. There was some discussion that a meeting could span more than the traditional week. However, the counterpoint is that keeping it within a week gives a focused block of time that people could allocate for participation in the virtual event. 2.2. Timezones What timezone does a virtual meeting operate in? Or does it operate in multiple timezones? One suggestion was that each working group might choose its own timezone based on the best timezone for the main contributors and leaders. (Although this might then limit participation from other areas of the world.) 2.3. Deadlines What do deadlines look like for a completely virtual meeting? Are the deadlines for agendas and drafts kept as they are for a regular meeting? 2.4. Plenaries What does a plenary look like in a virtual meeting? The same large session as today? York Expires May 4, 2017 [Page 5] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 2.5. Tutorials On the Sunday starting an IETF week we commonly have a series of tutorials. Are those still part of the program for a virtual meeting? 2.6. Hackathon / Code Sprint The Hackathon and Code Sprint have become popular activities before a physical meeting. Would they still exist for a virtual meeting? 2.7. Remote Hubs In recent years there has been an effort to establish "remote hubs" where groups of IETF members get together and participate remotely from that physical location. Would that continue as an option? Could the virtual meeting perhaps involve connecting together a series of remote hubs? (And if so, does this then again create a better experience for people who can go to a hub than for those who cannot?) 3. User Journey / Experience What is the experience of an "IETF attendee" in a virtual meeting? How does he or she experience the event? How could attendees be most effective in getting work done in a virtual setting? 3.1. Registration / sign-up What is the registration experience like? How do they initially "sign in" as an attendee? 3.2. Side meetings It is quite common for groups to decide during an IETF meeting to go off and have a side meeting. o How can this capability be reproduced in a virtual environment? o Could the system allow people to create ad hoc meetings in some fashion? York Expires May 4, 2017 [Page 6] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 3.3. Hallway conversations The casual hallway conversations are a key component of IETF physical meetings. How can some version of this capacity be made available? 3.4. Unstructured time How do you incorporate some concept of "unstructured" time where people can meet and connect? 3.5. Participating in multiple sessions It is currently possible for remote participants to join into multiple working group sessions at the same time. Users simply connect using multiple browser windows, multiple chat rooms or multiple computers. How does this impact users' experience? 3.6. Serendipity - discovering other users Part of a physical meeting involves discovering other people with common interests or backgrounds. How do you help people find others? 3.7. Voting / Hums What is the best way to have votes or hums in a virtual meeting? Most current audio conference systems would not make an actual audio hum possible. Votes in a chat could be possible but the lag time associated with remote connections would need to be taken into account. Some kind of system where votes take place over a period of time may need to be developed or used. This, though, does then introduce a delay into the meeting while there is a wait for the vote. 3.8. Microphone lines How do "mic lines" work in a completely virtual meeting? Would this in fact be a benefit as all attendees would be in the same queue? 3.9. Disruptive Behavior How do we deal with disruptive behavior in a virtual meeting? It can and does happen in meetings - and could potentially happen more easily in a virtual evironment where people cannot be physically stopped from going to a mic or could be removed from a room. What is the process to exclude someone who is being disruptive? Do we need moderators to be able to step in and mute or disable York Expires May 4, 2017 [Page 7] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 someone's connection? Who makes the decision that someone's behavior is disruptive? 3.10. Mentoring How would the "mentor" program work in a virtual meeting? The same as with a physical meeting? 3.11. Inclusivity How do you bring new people into sessions? How do people learn about side meetings? About hallway conversations? 3.12. T-Shirts Many attendees value the t-shirts that are provided for each IETF. How is it possible to provide a t-shirt to attendees of a virtual meeting? Does this just get skipped for the meeting? Do they get mailed out (incurring another expense)? 4. Technical Considerations Many technical questions need to be discussed. 4.1. Infrastructure What is the infrastructure used to host a completely virtual meeting? Are current systems (ex. Meetecho, Jabber chat rooms, audio streams) sufficient? Would new infrastructure need to be established? What kind of bandwidth would need to be available for the servers hosting the system? How would we handle connecting large numbers of people at the same time? 4.2. Capabilities Do virtual attendees have video connections? voice? chat? What kind of bandwidth would need to be available on the client end? 4.3. Authentication Today anyone can connect to the remote participation aspects of an IETF meeting. No authentication is required to join a jabber chat room, listen to an audio stream or connect to a Meetecho session. Would that need to change? Would "registration" give you a login to York Expires May 4, 2017 [Page 8] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 whatever system was used for the meeting? Would you not be able to participate without those login credentials? 4.4. Audio How do we address issues of lag, stutter, echo and other artifacts of current audio conferencing systems? Is there a "minimum voice quality" level that is acceptable? (George Michaelson has suggested the telco QDU concept is something to consider.) 4.5. Network Operation Center (NOC) Where does the NOC "exist" for a completly virtual meeting? What is its role? 5. Administrative 5.1. Centralized Resources What is the impact of a virtual meeting on centralized resources such as support staff? What is the full role of the Secretariat during the meeting? 5.2. Finances The financial model of a completely virtual meeting needs to be understood. What would be the financial costs associated with a meeting? 5.2.1. Initial Investment Would there need to be an initial investment in infrastructure for the first completely virtual meeting? Would there then be lower costs for the next virtual meeting? 5.2.2. Registration Fees Would we charge the same amount to attendees as a regular meeting? Lou Berger sent the following suggestions to the list related to registration fees: 1. Remote audio feed and jabber participation should continue to be unpaid and unregistered as now York Expires May 4, 2017 [Page 9] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 2. Access to session audio and video recordings should continue to be published as now, without fee or registration 3. Remote video/audio - registration should be per individual participant (i.e., anyone that speaks/presents) perhaps having hubs include some number of participants. 4. Non-registered/anonymous video (meetecho) listeners should be allowed, but their mic/text input should be disabled. 5.2.3. Sponsorships How do sponsorships work with a completely virtual meeting? Would sponsorships be required at the same level as the physical meetings? If a virtual meeting is sponsored, how is the sponsor given the visibility that is currently given with a physical meeting? For instance, with the signage, T-shirts, plenary slides, etc. 5.2.4. Long-term impact If we were successful in holding a completely virtual meeting, would companies no longer be willing to send attendees to physical meetings? In other words, would the first one start us on a path toward having all meetings in this fashion? (And are we okay with that?) 5.3. Legal How do we ensure all attendees, coming in at all times, see and agree to the Note Well statement? 6. Security Considerations There are many considerations related to security and privacy that need to be factored in to a virtual meeting. 6.1. Availability How do we ensure that an attack such as a distributed denial of service (DDoS) doesn't take out the entire virtual meeting? What about an attack against a particular region? Similarly, how do we protect against disruption caused by groups on the Internet who may simply want to disrupt the meeting for the fun of it? (See the section on "Authentication" earlier.) York Expires May 4, 2017 [Page 10] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 6.2. Integrity How do you know that the person who is logged into whatver system is used is in fact who they say they are? In a physical meeting: o We can see the person and physically identify them. o Users wear name badges that were issued at registration time. o There are typically other people who may know many individuals. How are these physical considerations replicated in a virtual meeting? 6.3. Privacy What level of privacy protection would be needed for conversations? for user information? Much of the IETF's work is all done on public email lists and archived remote sessions. What level of privacy is needed? 7. IANA Considerations Are there any IANA considerations associated with a virtual meeting? 8. Next Steps With this initial document published, the intent now is to go back and start to fill in the sections with possible ideas about how the questions might be answered. 8.1. Learning from others Suggestions were made to investigate what lessons can be learned from work by other organizations on virtual meetings. Initial suggestions included: o The Internet Society has now hosted two (2015 and 2016) global "InterCommunity" events bringing together ISOC members from around the world. The 2016 event, in particular, was designed to be a virtual event. o The conference industry has been exploring virtual and/or "hybrid" meetings. There may be value here. o Universities and specifically Internet2 may have some experience. York Expires May 4, 2017 [Page 11] Internet-Draft Thoughts on Completely Virtual Meetings October 2016 o George Michaelson stated: "Van Jacobsen did a lot of work on meeting behaviour online in the MBONE days, working on the whiteboard and vat. He has made observations about weighted-sum voting, speaking controls, inheritence of the state of the meeting." 8.2. Trial? How would it be possible to do a "trial run" of a virtual meeting? 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words for Use in RFCs to Indicate Requirement Levels", RFC 6919, DOI 10.17487/RFC6919, April 2013, . Appendix A. Acknowledgements This document reflects the input of many people who participated in both the manycouches design team as well as the discussion with the IESG on 20 July 2016 at IETF 96 in Berlin. Subsequent discussions on the manycouches mailing list also informed this document. The author would specifically like to thank Lou Berger, Benoit Claise, Stephen Farrell, George Michaelson and Greg Wood for their input. Appendix B. Development Note This document is being developed using a repository on Github at: Comments, issues and pull requests are welcome. Author's Address Dan York Internet Society Keene, NH USA Email: york@isoc.org York Expires May 4, 2017 [Page 12]