Skip to main content

Thoughts on Completely Virtual IETF Meetings
draft-manycouches-completely-virtual-meetings-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Dan York
Last updated 2016-10-31
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-manycouches-completely-virtual-meetings-02
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-02

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.  This is currently a thought
   experiment.  There are no current plans to hold a completely virtual
   IETF meeting.

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

York                       Expires May 4, 2017                  [Page 1]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Why Do IETF Meetings Take Place?  . . . . . . . . . . . .   4
     1.2.  Why Hold a Completely Virtual IETF Meeting? . . . . . . .   4
     1.3.  Conventions and Terminology . . . . . . . . . . . . . . .   4
   2.  Program . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Meeting Structure . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Timezones . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Deadlines . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Plenaries . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.5.  Breaks  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.6.  Tutorials . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.7.  Hackathon / Code Sprint . . . . . . . . . . . . . . . . .   6
     2.8.  Other Physical Meeting Elements . . . . . . . . . . . . .   6
     2.9.  Sessions by non-IETF groups . . . . . . . . . . . . . . .   6
     2.10. Remote Hubs . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  User Journey / Experience . . . . . . . . . . . . . . . . . .   7
     3.1.  Registration / sign-up  . . . . . . . . . . . . . . . . .   7
     3.2.  Side meetings . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Hallway conversations . . . . . . . . . . . . . . . . . .   7
     3.4.  Unstructured time . . . . . . . . . . . . . . . . . . . .   8
     3.5.  Participating in multiple sessions  . . . . . . . . . . .   8
     3.6.  Serendipity - discovering other users . . . . . . . . . .   8
     3.7.  Voting / Hums . . . . . . . . . . . . . . . . . . . . . .   8
     3.8.  Microphone lines  . . . . . . . . . . . . . . . . . . . .   8
     3.9.  Disruptive Behavior . . . . . . . . . . . . . . . . . . .   8
     3.10. Mentoring . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.11. Inclusivity . . . . . . . . . . . . . . . . . . . . . . .   9
     3.12. T-Shirts  . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Technical Considerations  . . . . . . . . . . . . . . . . . .   9
     4.1.  Infrastructure  . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Capabilities  . . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  Authentication  . . . . . . . . . . . . . . . . . . . . .  10
     4.4.  Audio . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.5.  Network Operation Center (NOC)  . . . . . . . . . . . . .  10
   5.  Administrative  . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Centralized Resources . . . . . . . . . . . . . . . . . .  10
     5.2.  Finances  . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.2.1.  Initial Investment  . . . . . . . . . . . . . . . . .  10
       5.2.2.  Registration Fees . . . . . . . . . . . . . . . . . .  10
       5.2.3.  Sponsorships  . . . . . . . . . . . . . . . . . . . .  11
       5.2.4.  Long-term impact  . . . . . . . . . . . . . . . . . .  11
     5.3.  Legal . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12

York                       Expires May 4, 2017                  [Page 2]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

     6.1.  Availability  . . . . . . . . . . . . . . . . . . . . . .  12
     6.2.  Integrity . . . . . . . . . . . . . . . . . . . . . . . .  12
     6.3.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Next Steps  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Learning from others  . . . . . . . . . . . . . . . . . .  13
     8.2.  Trial?  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  13
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  14
   Appendix B.  Development Note . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

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

York                       Expires May 4, 2017                  [Page 3]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

   taking place in multiple locations with virtual participants joining
   in remotely.

   It is also worth noting that in discussions to date the sense has
   been that even if we held a completely virtual meeting, it would only
   happen once out of several meetings.  There would still be multiple
   physical IETF meetings during the year.

1.1.  Why Do IETF Meetings Take Place?

   [It may be good to insert some text here about WHY we have IETF
   meetings and what the overall goals are.  Both as a reminder of the
   point of the meetings and potentially to frame thinking about how we
   might move toward those goals by trying doing things a bit
   differently.]

1.2.  Why Hold a Completely Virtual IETF Meeting?

   [At some point in the maturity of this document it would be valuable
   to discuss the benefits and challenges of a completely virtual
   meeting.  Before that summary can be developed, though, further
   investigation and development needs to happen.  At a very high level,
   one idea is that a completely virtual meeting might make the meeting
   more accessible to more people in terms of schedules, lack of travel
   and reduced costs.  However, all of that thinking need considerably
   more exploration.  Several participants in discussions have voiced
   the opinion that replacing physical IETF meetings will be close to
   impossible.  This document is being developed to explore all of these
   issues.]

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].

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

York                       Expires May 4, 2017                  [Page 4]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

   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.)

   This timezone issue was identified by multiple participants as the
   hardest aspect of planning a virtual meeting.

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?

2.5.  Breaks

   There are breaks planned throughout the days of a physical IETF
   meeting to enable people to move between sessions and to have
   refreshments and restroom breaks.  Similarly there are longer breaks
   for lunch.

York                       Expires May 4, 2017                  [Page 5]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

   How are breaks structured in a completely virtual meeting?

   o  Can they be shorter?

   o  Do you need a longer "lunch break"?  Or does that make no sense?

2.6.  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.7.  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.8.  Other Physical Meeting Elements

   In a typical IETF physical meeting, there are other meetings and
   activities that occur alongside the meetings of Working Groups and
   BOFs.  These include:

   o  Newcomers Meet and Greet

   o  Welcome Reception

   o  Bits-N-Bites

   o  Thursday Lunch Speaker Series

   o  Social Event

   Do any of these additional sessions still make sense in a virtual
   meeting?

   The Thursday Lunch Speaker Series (by the Host organization) could
   continue as webinar-style presentations.  But the other elements
   involve face-to-face interaction that would be difficult in a virtual
   setting.

2.9.  Sessions by non-IETF groups

   Other organizations sometimes hold meetings during the time of the
   IETF physical meeting and often use the same venue.  For example, the
   Internet Society usually offers an "ISOC@IETF Briefing Panel" during
   the Tuesday lunch break.  At some IETF meetings groups have shown

York                       Expires May 4, 2017                  [Page 6]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

   films or scheduled other meetings.  These are not IETF meetings, but
   make use of the opportunity of having the IETF attendees available.

   Do these sessions still make sense?  Would we offer the IETF virtual
   meeting infrastructure to groups to use when it is not being used for
   IETF meetings?

2.10.  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?

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?

York                       Expires May 4, 2017                  [Page 7]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

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
   someone's connection?  Who makes the decision that someone's behavior
   is disruptive?

York                       Expires May 4, 2017                  [Page 8]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

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 usually provided for each
   IETF.  Without a physical meeting it could be challenging and costly
   to distribute T-shirts to attendees.

   T-shirts are currently funded by the Host of the physical IETF
   meeting.  If there is no Host, or if the Host chooses not to fund a
   T-shirt, there may be no T-shirt.

   With a virtual meeting it may be that if there is a Host (see
   "Sponsorships" below), the Host would have the same option as the
   physical meeting - to provide a T-shirt or not.  The Host could then
   decide how they would distribute the T-shirt.

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?

York                       Expires May 4, 2017                  [Page 9]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

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
   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?

York                       Expires May 4, 2017                 [Page 10]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

   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

   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.

   In particular, is there a sponsor designated as the "Host" of the
   IETF meeting?  The Host for physical meetings receives benefits
   including:

   o  Prominent mention in materials and promotion of the IETF meeting.

   o  The "host presentation" speaking slot during the plenary.

   o  The "Thursday Lunch Speaker Series" time for whatever they wish to
      present.

   o  Mention on the T-shirt for the event (if the Host chooses to fund
      the creation of a T-shirt).

   Would we have a "Host" for a virtual meeting?

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?)

York                       Expires May 4, 2017                 [Page 11]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

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.)

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?

York                       Expires May 4, 2017                 [Page 12]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

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.

   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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [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,
              <http://www.rfc-editor.org/info/rfc6919>.

York                       Expires May 4, 2017                 [Page 13]
Internet-Draft   Thoughts on Completely Virtual Meetings    October 2016

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.  Other 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:

   o  <https://github.com/danyork/draft-york-manycouches-completely-
      virtual-meetings>

   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 14]