manycouches D. York
Internet-Draft October 31, 2016
Intended status: Informational
Expires: May 4, 2017

Initial Thoughts on Completely Virtual IETF Meetings


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.

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

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

Table of Contents

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.

1.1. Benefits

Proponents of planned virtual meetings point to benefits such as:

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:

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

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:

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?

3. User Journey / Experience

3.1. Participating in multiple sessions

It is currently possible for remote participants to join into multiple working group sessions at the same time. Users simply run Meetecho in multiple browser windows or multiple computers. How does this impact users' experience?

3.2. Side meetings

It is quite common for groups to decide during an IETF meeting to go off and have a side meeting.

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. 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.6. 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.7. Mentoring

How would the "mentor" program work in a virtual meeting? The same as with a physical meeting?

3.8. Inclusivity

How do you bring new people into sessions? How do people learn about side meetings? About hallway conversations?

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 such as Meetecho sufficient? Would new infrastructure need to be established?

What kind of bandwidth would need to be available?

4.2. Capabilities

Do virtual attendees have video connections? voice? chat?

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

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?

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:

How are these physical considerations replicated in a virtual meeting?

7. IANA Considerations

There are no IANA considerations associated with this document.

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

The author thanks all of the participants of the manycouches design team as well as the IESG members who participated in the discussion on 20 July 2016 at IETF 96 in Berlin.

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 Keene, NH, USA EMail: