draft-ietf-genarea-rps-reqs-03.txt   draft-ietf-genarea-rps-reqs-04.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational March 9, 2012 Intended status: Informational May 7, 2012
Expires: September 10, 2012 Expires: November 8, 2012
Requirements for Remote Participation Services for the IETF Requirements for Remote Participation Services for the IETF
draft-ietf-genarea-rps-reqs-03 draft-ietf-genarea-rps-reqs-04
Abstract Abstract
The IETF has provided some tools for remote participation in its The IETF has provided some tools for remote participation in its
activities for many years, and some IETF participants have also used activities for many years, and some IETF participants have also used
their own tools when they felt the need arise. The IETF now wishes their own tools when they felt the need arise. The IETF now wishes
to support enhanced remote participation that is as seamless as to support enhanced remote participation that is as seamless as
possible, approaching the quality of direct physical attendance for possible, improving the experience for the remote attendee without
the various roles, including chair, presenter and simple attendee. degrading the experience for the people that are physically present.
Before deploying the new tools and services needed for this enhanced Before deploying the new tools and services needed for this enhanced
remote participation, the requirements for such tools and services remote participation, the requirements for such tools and services,
must be defined. This document is meant to be that definition. and the impacts they will make on the current procedures and
infrastructure, must be defined. This document is meant to be that
definition.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2012. This Internet-Draft will expire on November 8, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. About This Document . . . . . . . . . . . . . . . . . . . 5 1.1. Goals for an Improved RPS . . . . . . . . . . . . . . . . 4
2. Scenarios Required to be Supported . . . . . . . . . . . . . . 7 1.2. About This Document . . . . . . . . . . . . . . . . . . . 5
3. Interactions with Current RPS Tools Used by the IETF . . . . . 8 2. Requirements for Supporting Remote Participation in
3.1. Technologies Currently Used at Regular IETF Meetings . . . 8 Regular IETF Meetings . . . . . . . . . . . . . . . . . . . . 6
3.2. Locating the Meeting Information . . . . . . . . . . . . . 9 2.1. Registration for Remote Participation . . . . . . . . . . 7
3.2.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Instant Messaging . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Instant Messaging . . . . . . . . . . . . . . . . . . 10 2.3. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Audio to Remote Attendees . . . . . . . . . . . . . . 9
3.3. Remote Participation at IETF Meetings . . . . . . . . . . 10 2.3.2. IM-to-Mic Relay of Comments from Remote Attendees . . 9
3.3.1. Remotely Speaking at the Mic . . . . . . . . . . . . . 10 2.3.3. Audio for Presentations from Remote Attendees . . . . 10
3.3.2. Remotely Presenting . . . . . . . . . . . . . . . . . 13 2.3.4. Audio from Remote Attendees to the Room for
3.3.3. Floor Control . . . . . . . . . . . . . . . . . . . . 13 Comments . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Remote Participation at IETF Interim WG Meetings . . . . . 14 2.4. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Face-to-Face Interim Meetings . . . . . . . . . . . . 14 2.4.1. Video from the Room to Remote Attendees . . . . . . . 12
3.4.2. Virtual Interim Meetings . . . . . . . . . . . . . . . 14 2.4.2. Video from Remote Attendees to the Room . . . . . . . 13
4. Requirements for Supporting Remote Participation in 2.5. Slide Presentations and Distribution . . . . . . . . . . . 13
Regular IETF Meetings . . . . . . . . . . . . . . . . . . . . 15 2.6. Shared Text Document Editing . . . . . . . . . . . . . . . 14
4.1. Registration for Remote Participation . . . . . . . . . . 17 2.7. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.8. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. IM-to-Mic Relay of Comments from Remote 2.9. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 16
Participants . . . . . . . . . . . . . . . . . . . . . 18 2.10. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 16
4.2.2. Audio from Remote Participants to the Room . . . . . . 19 2.11. Preparation . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.11.1. Preparation for WG Chairs . . . . . . . . . . . . . . 16
4.3.1. Video from the Room to Remote Participants . . . . . . 21 2.11.2. Preparation for Remote Attendees . . . . . . . . . . . 17
4.3.2. Video from Remote Participants to the Room . . . . . . 22 3. Requirements for Supporting Remote Participation in
4.4. Instant Messaging . . . . . . . . . . . . . . . . . . . . 22 Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Slide Presentations . . . . . . . . . . . . . . . . . . . 23 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
4.6. Slide Distribution . . . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
4.7. Shared Document Editing . . . . . . . . . . . . . . . . . 24 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
4.8. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Informative References . . . . . . . . . . . . . . . . . . . . 19
4.9. Transcription . . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Background on IETF Remote Participation . . . . . . . 20
4.10. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.1. How the IETF Meets . . . . . . . . . . . . . . . . . . . . 20
4.11. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 26 A.2. Technologies Currently Used at Regular IETF Meetings . . . 22
4.12. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 26 A.3. Locating the Meeting Information . . . . . . . . . . . . . 22
4.13. Additional Requirements for Remote Participation . . . . . 27 A.3.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Requirements for Supporting Remote Participation in A.3.2. Instant Messaging . . . . . . . . . . . . . . . . . . 23
Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 28 A.3.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Requirements for Supporting Remote Participation in A.4. Remote Participation at IETF Meetings . . . . . . . . . . 24
Face-to-Face Interim Meetings . . . . . . . . . . . . . . 28 A.4.1. Remotely Speaking at the Mic . . . . . . . . . . . . . 24
5.2. Requirements for Supporting All-Remote Interim Meetings . 29 A.4.2. Remotely Presenting . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 A.4.3. Floor Control . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 A.5. Remote Participation at IETF Interim WG Meetings . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 A.5.1. Face-to-Face Interim Meetings . . . . . . . . . . . . 29
9. Informative References . . . . . . . . . . . . . . . . . . . . 30 A.5.2. Virtual Interim Meetings . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
There are two types of participants at the three-times-a-year IETF There are two types of participants at the three-times-a-year IETF
meetings: the people who are physically at the meeting ("local meetings: the people who are physically at the meeting ("local
attendees") and people that are not physically at the meeting but are attendees") and people that are not physically at the meeting but are
following the meeting online ("remote attendees"). For more than a following the meeting online ("remote attendees"). For more than a
decade, the IETF has tried to make it easier for remote attendees to decade, the IETF has tried to make it easier for remote attendees to
participate in its face-to-face meetings in a meaningful fashion by participate in its face-to-face meetings in a meaningful fashion by
providing supported and experimental online services. employing various tools.
At the same time, many IETF Working Groups (WGs) have started to have At the same time, many IETF Working Groups (WGs) have started to have
interim meetings that are scheduled between the regular IETF interim meetings that are scheduled between the regular IETF
meetings; these are described (briefly) in [RFC2418]. Some of these meetings; these are briefly described in [RFC2418]. Some of these
interim meetings are face-to-face meetings with remote attendees, interim meetings are face-to-face meetings with remote attendees,
while other interim meetings only take place over the Internet or on while other interim meetings only take place over the Internet or on
the phone; the latter type of meeting is often called a "virtual the phone; the latter type of meeting is often called a "virtual
interim". There are also interim meetings that do not support remote interim". There are also interim meetings that do not support remote
participation. participation.
The IETF's current remote participation system ("RPS") for the The IETF's current remote participation system ("RPS") for the
official three-times-a-year meetings ("regular IETF meetings") official three-times-a-year meetings ("regular IETF meetings")
consists of a real-time audio stream carried over HTTP, textual consists of a real-time audio stream carried to remote attendees over
instant messaging (IM) carried over Jabber, as well as experimental HTTP, textual instant messaging (IM) carried over Jabber, and slides
support for two integrated tools, WebEx and Meetecho. Some WGs distributed on the IETF web site. Experimental support for two
employ ad-hoc tools such as Skype. For interim WG meetings, the IETF integrated tools, WebEx and Meetecho, are used to sync the audio and
provides access to WebEx. The IETF's leadership regularly uses slides during the meeting, and also replay them in the proceedings.
telephone, Jabber, and WebEx for the many meetings that happen Some WGs also employ ad-hoc tools such as Skype. For interim WG
between the IETF meetings. meetings, the IETF provides access to WebEx. The IETF's leadership
regularly uses telephone, Jabber, and WebEx for the many meetings
that happen between the IETF meetings. Many meetings use a mixture
of tools, with each tool providing only part of the overall desired
functionality. A more detailed description of the current IETF RPS
can be found in Appendix A.
1.1. Goals for an Improved RPS
The IETF wants to improve the tools provided in the RPS for many The IETF wants to improve the tools provided in the RPS for many
reasons. reasons.
o A better RPS would allow more people to participate in regular o A better RPS would allow current remote IETF attendees to
IETF meetings more effectively, hopefully leading to better WG participate in regular IETF meetings more effectively, and would
outcomes such as faster progression of WG documents, more also allow more people to become remote IETF attendees. This in
reviewers of WG documents, and more discussion of changes needed turn would hopefully lead to better WG outcomes. There are many
to those documents during the WG process. There are many people people who are active in many WGs who rarely or never come to IETF
who are active in many WGs who rarely or never come to IETF meetings; good RPS tools could allow some of these people to
meetings; good RPS tools could allow these people to contribute contribute better during meetings.
significantly during meetings like they do on the mailing lists.
o The improved RPS tools would also be used outside IETF meetings. o The improved RPS tools would also be used outside IETF meetings.
They would be available to WGs for interim meetings, both to allow They would be available to WGs for interim meetings, both to allow
remote participation in face-to-face interims as well as to remote participation in face-to-face interims as well as to
facilitate "virtual interims" where none of the participants are facilitate virtual interims where none of the attendees are in the
in the same location. same location.
o The plenary sessions of IETF meetings currently only allow remote o The plenary sessions of IETF meetings currently only allow remote
attendees to hear the speakers and read a real-time transcript. attendees to hear the speakers and read a real-time transcript.
Improved RPS tools would allow remote attendees to see the Improved RPS tools would allow remote attendees to see the
speakers and be able to comment at the mics like people in the speakers, to see the slides synchronized with the audio, and be
room. able to comment at the mics like people in the room.
o The IETF leadership (the IAB, IESG, IAOC, and probably others) o The IETF leadership (the IAB, IESG, IAOC, and probably others)
could use the new tools to help make their own meetings more could use the new tools to help make their own meetings more
effective. effective.
1.1. About This Document o There is a desire to better capture the contributions to the IETF
(as defined in [BCP78]) of remote attendees in the official record
The purpose of this document is to develop the requirements and of regular IETF and interim meetings.
functional specifications for the IETF's RPS that enables enhanced
remote participation in meeting sessions. The RPS described in this
document might augment and/or replace the current set of IETF RPS
tools. The intention is for the experience of remote attendees to
rival those of local attendees.
After the tools that meet the requirements in this document are The are many IETF-related activities that can be aided by remote
deployed, there will probably be a change in the participation in participation tools. The scenarios in which the RPS described in
regular IETF meetings. this document is expected to be used are WG sessions at regular IETF
meetings, plenaries at regular IETF meetings, AD-sponsored lunch
meetings at regular IETF meetings, face-to-face interim WG meetings,
and IETF leadership meetings.
o Some people who would make an effort to come to a particular IETF 1.2. About This Document
meeting might be more likely to attend remotely. Such a change
will reduce the number of local attendees, which will both reduce
the amount that the IETF makes from registration fees and makes
the informal gatherings during the IETF meeting less valuable
because of the reduced networking effects.
o People who are active on WG mailing lists but not in the regular The purpose of this document is to develop the requirements for the
meetings are more likely to participate in the meetings remotely. IETF's RPS that enables enhanced remote participation in meeting
Such a change might cause more effective meetings for WGs that are sessions. The RPS described in this document might augment and/or
lagging in energy because more people will participate. WG replace the current set of IETF RPS tools. The intention is to
meetings that already have lots of participants will probably improve as much as possible of the experience of remote attendees in
become busier. Presentations on documents where none of the meetings while not significantly affecting the experiences of local
authors come to regular IETF meetings will be much more likely to attendees and WG chairs.
be given by the authors instead of by their proxies.
o If the tools make regular IETF meetings and interim meetings much This document differentiates between requirements that have higher
more effective, the IETF might be able to reduce the number of and lower priorities. Higher-priority requirements are intended to
regular meetings each year from three to two. This would be delivered as soon as possible, but lower-priority requirements
significantly reduce the impact of travel on regular IETF might be delivered later. For example, a high-priority requirement
participants and make meeting planning much easier, but could might be "remote attendees must be able to know which slide is being
significantly change the finances for the IETF and also reduce the discussed" and a related, lower-priority requirement might be "remote
amount of side-meeting value per year for participants. attendees must be able to see the speaker pointing to the slide with
a laser pointer". The eventual tools will be rolled out based on the
priorities, making it likely that the community will learn more about
additional requirements for lower priority items before they are
deployed.
Note that some of the requirements in this document for particular Note that some of the requirements in this document for particular
functionality may not be desired by all WG chairs. The tools functionality may not be desired by all WG chairs. Different WG
proposed will not force a particular WG to use all the features chairs prefer to use different tools, and that will be true when the
proposed. additional tools described in this document are deployed. The use of
some tools is currently required by the IETF procedures, such as the
audio recordings that are put in the proceedings. This document does
not mandate the use of any particular tool by a WG, but such a
requirement might be made by others, such as an Area Director
requiring the use of a particular tool by one or more WGs in their
area.
This document is being produced at the request of the IAOC. The This document is being produced at the request of the IAOC. The
request for proposals that led to this document can be found at request for proposals that led to this document can be found at
[RPS-RFP]. This document does not specify specific technologies or [RPS-RFP]. This document does not specify specific technologies or
instantiations of tools. Instead, it is meant to be used as a guide instantiations of tools. Instead, it is meant to be used as a guide
for the IAOC to later contract the development and deployment of the for the IAOC to later contract the development and deployment of the
tools described here. tools described here.
Requirements in this document are numbered, such as "**Requirement Requirements in this document are numbered, such as "**Requirement
03-00**". In the IETF, there is an active (and never-ending) debate 04-00**".
about what is a "requirement". In the context of this document, a
requirement is something that must appear in one of the iterations of
the eventual RPS in order to support the mission of enabling useful
remote participation in meeting sessions.
Later versions of this document will differentiate between
requirements that must be met by the first version of the RPS and
requirements that must be met by future versions of the RPS. For
example, a requirement for the first version of the RPS might be
"chairs must be able to specify which remote attendee can speak
next", whereas a requirement for a later version of the RPS might be
"chairs must be able to perform many or all chair duties at a regular
IETF meeting while participating remotely". [[[ TODO: come up with a
way to differentiate these two and start marking them as such. ]]]
A functional specification is an approach to meeting one or more
requirement. For example, a requirement might be "chairs must be
able to specify which remote attendee can speak next" and a
function's specification associated with that requirement might be
"floor control can be done through a stand-alone application or web
form". Functional specifications are called out in this document as
"**Functional spec 03-00**".
The requirements and functional specifications covered in this The requirements covered in this document apply almost exclusively to
document apply almost exclusively to tools and services that are used tools and services that are used for remote participation in real-
for remote participation in real-time meetings. The document does time meetings. The document does not cover the many other tools used
not cover the many other tools used by WGs for non-real-time by WGs for non-real-time communication such as mailing lists, issue
communication such as mailing lists, issue trackers, document flow trackers, document flow control systems, and so on. Many of the non-
control systems, and so on. Many of the non-real-time tools are also real-time tools are also being improved over time, but they are not
being improved over time, but they are not the subject of this the subject of this document.
document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document is being discussed on the vmeet@ietf.org mailing list. This document is being discussed on the vmeet@ietf.org mailing list.
See <https://www.ietf.org/mailman/listinfo/vmeet> for more See <https://www.ietf.org/mailman/listinfo/vmeet> for more
information. information.
2. Scenarios Required to be Supported 2. Requirements for Supporting Remote Participation in Regular IETF
Meetings
The are many IETF-related activities that can be aided by remote This section covers the requirements for effective remote
participation tools. The scenarios in which the RPS described in participation in meetings where most members are in regular IETF
this document is expected to be used are: face-to-face meetings. Some of the requirements in this section
overlap with those in Section 3, but many are unique to meetings that
have a large number of attendees physically present.
**Requirement 04-01**: The specifications in the RPS MUST rely upon
IETF and other open standards for all communications and interactions
wherever possible unless there is an identified gap that cannot be
met by those standards.
**Requirement 04-02**: All tools in the RPS SHOULD be able to be run
on the widest possible array of computers. The tools may be stand-
alone applications, may be run from a modern web browser, or from the
command line. The highest priority is that the tool need to be
available on all of (at least) MacOS version 10.6 or later, Windows 7
or later, and any common Linux distribution produced in 2010 or
later. A lower priority is that the tools be able to run on IOS and
Android platforms. The tools MUST NOT rely on Adobe Flash to work
correctly.
**Requirement 04-03**: Audio, video, instant messaging, and slide
streams going to and from remote attendees SHOULD be delivered in as
close to real-time as is practically possible. When possible, the
delivery SHOULD have delays of less than 200 milliseconds to remote
attendees who are on fast Internet connections. A common complaint
with the current RPS is that the streaming audio can take more than
10 seconds (and sometimes as much as 30 seconds) to reach the remote
attendee. This causes many of the problems listed in Appendix A.4.1.
**Requirement 04-04**: The outgoing audio, video, and slide streams
MUST have the same delays so the remote attendee does not get
confused during slide presentations.
**Requirement 04-05**: All streaming information from the RPS SHOULD
be usable over Internet connections running at 56Kbps. Many remote
attendees will be in places with limited bandwidth.
**Requirement 04-06**: Both local and remote attendees SHOULD be able
to easily contact a single entity who is available throughout the
meeting if they find problems with any of the RPS tools, and to get
fairly rapid response. This entity needs to be able to handle as RPS
tool problems in the meeting rooms, or be able to quickly contact
someone who can address those problems.
**Requirement 04-07**: Any tools that are used by remote attendees
MUST also be available to local attendees as well. At many IETF
meetings, some local attendees act as remote attendees in WG meetings
that they are not sitting in, so they can attend two WGs at once.
2.1. Registration for Remote Participation
Remote attendees who make contributions to the IETF (as defined in
[BCP78]) are bound by the "Note Well" text. By allowing registration
before participating remotely, remote attendees can be better alerted
to, and thus bound to, the requirements of contributors. This is
particularly important because it is easy in the IETF process to
change from being an observer to being a contributor. For example,
many people who say things in a WG's IM room do not realize that they
are bound by the "Note Well" text.
**Requirement 04-08**: All remote attendees at regular IETF meetings
and interim meetings who make contributions MUST register with the
IETF Secretariat before contributing using any of the RPS tools.
**Requirement 04-09**: Remote attendees who will only be listening
and/or watching, but not making contributions, MUST NOT be required
to register.
**Requirement 04-10**: Registration for remote attendees SHOULD be no
more onerous than joining a WG mail list. Basically, the registrant
should acknowledge the Note Well, prove that they are at the given
email address, and receive confirmation that they are registered.
The confirmation will also include any passwords needed for the RPS
tools.
**Requirement 04-11**: The RPS tools (particularly the registration
tool) MUST gracefully handle multiple attendees who have the same
name.
The cost for remote attendees to register, if any, is not covered in
this document but will instead be determined by the IETF at a later
time. There are many ideas on the subject (tiered costs for
different services, no cost at all for the first year, and others),
but the effects of different cost structures is beyond the scope of
this document.
2.2. Instant Messaging
Instant messaging (IM) is used both as a remote participation tool
and as a communication tool for local attendees at a regular meeting.
Although the current tool's Jabber room is a good way to get
questions to the mic, it also becomes a second communications channel
that only a few people in the room are participating in. The instant
messaging system is also useful for remote users to ask about the
status of the room ("is anyone there?").
**Requirement 04-12**: The IM system MUST allow anyone to see all
messages in the WG's or BoF's room.
**Requirement 04-13**: The IM system MUST allow any registered user
to post messages in the WG's or BoF's room.
**Requirement 04-14**: The date and time that a message appears in an
IM stream MUST be retained. IM clients MUST be able to show an
indication of the date and time for all messages. Someone coming
into a meeting late requires context for which messages in an instant
messaging room are recent and which are old.
2.3. Audio
Audio from face-to-face meetings travels in two directions: from the
room to remote attendees, and (potentially) from remote attendees to
the room. Comments on early drafts of this document indicated that
the latter may not really be a requirement for all attendees if IM-
to-mic is made predictable. Given this, reliable IM-to-mic relay for
comments to speakers is highest priority, audio from remote attendees
giving presentations is a second priority, and audio from remote
attendees giving comments to the room is a third priority.
2.3.1. Audio to Remote Attendees
**Requirement 04-15**: Remote attendees MUST be able to hear what is
said by local attendees and chairs at any mic in the meeting.
**Requirement 04-16**: Remote attendees SHOULD be able to hear the
audio stream over the PSTN.
2.3.2. IM-to-Mic Relay of Comments from Remote Attendees
As described in Appendix A.4.1, the current tools support an informal
method for remote attendees to speak at the mic: in the Jabber room,
they enter the string "mic:" before their comment and hope that the
designated scribe or someone else goes to the mic to relay the
comment. This method works, but the current implementation has
significant flaws described in that section.
**Requirement 04-17**: Relay of messages from IM to the mic MUST be
able to happen as quickly as if the remote attendee was local.
**Requirement 04-18**: The person relaying from IM to the mic must be
available throughout the WG meeting. To date, this has been done by
WG volunteers in the room. In the future, it could be done the same
way, or maybe could be facilitated by hiring people to attend
meetings for the specific purpose of being IM-to-mic scribes, or
maybe could be done with tools that allow copy-and-paste of text from
IM to a speech synthesizer that reads it to the room.
**Requirement 04-19**: If multiple remote attendees want to comment
at the same time, the person relaying from IM to the mic MUST be able
to relay for all of them.
Note: during the development of this document, there have been many
suggestions for how WG chairs can better manage the IM-to-mic
relaying (for example, with planned pauses, better tracking of the IM
room, and so on). Because these are actually about improving WG
chairs, not the RPS tools, they are out of scope for this document.
2.3.3. Audio for Presentations from Remote Attendees
In order for a remote attendee to be a presenter, their voice needs
to be heard in the meeting room. This functionality is different
than allowing remote attendees from giving comments (covered in
Section 2.3.4) in that the the WG chair needs much less floor control
for one speaker than for many.
**Requirement 04-20**: A remote attendee giving a presentation MUST
be able to have their speaking be heard by all local and remote
attendees.
**Requirement 04-21**: A WG chair MUST be able to control the sound
coming from a remote attendee. This control MUST allow reduction in
volume, all the way to complete muting, of the remote speaker.
**Requirement 04-22**: Audible echo in the audio stream MUST be
damped and/or eliminated by the tools. The RPS MUST recognize
audible echo and automatically take measures to reduce it to a level
which won't distract listeners.
**Requirement 04-23**: The audio system used by the RPS MUST be able
to integrate with systems commonly used in the venues used for IETF
meetings.
2.3.4. Audio from Remote Attendees to the Room for Comments
Note that the requirements here assume a very large change in the way
that remote participation will happen. Instead of a remote attendee
typing something into the Jabber room that someone will repeat at a
mic in the room, remote attendees will use their own mics to speak to
the meeting. Some of the requirements from Section 2.3.3 will apply
here as well.
**Requirement 04-24**: Remote attendees MUST be able to speak
directly to a meeting without going through a local attendee, and
have their speaking be heard by local attendees. (Note that the
ability to speak is controlled by the chair; see Section 2.3.4.1.)
**Requirement 04-25**: Local attendees MUST be able to determine
which remote attendee is speaking.
**Requirement 04-26**: When a remote attendee connects to the audio
stream to the room, their mic SHOULD start off muted. This will
prevent problems such as those common with WebEx where a remote
attendee doesn't realize that they can be heard.
**Requirement 04-27**: A lower-priority requirement is for remote
attendees to be able to speak to the room by originating from the
PSTN.
2.3.4.1. Floor Control for Chairs for Audio from Remote Attendees
It is not yet clear how the set of remote attendees would be treated
for queueing. Some tools have each remote attendee being considered
separately, while others pool all remote attendees into one group.
This affects the chair knowing and being able to act on the order
that remote attendees ask to speak.
Note that, if the remote video to room requirements from
Section 2.4.2 need to be met, it is very likely that a related
requirement to those below is that "the audio and video floor
controls must be in the same tool".
**Requirement 04-28**: Remote attendees MUST have an easy and
standardized way of requesting the attention of the chair when the
remote attendee wants to speak. The remote attendee MUST also be
able to easily cancel an attention request.
**Requirement 04-29**: The RPS MUST allow a remote attendee's request
for attention to include an optional short text string. A remote
attendee might want to indicate that they are asking a question of
the presenter, or answering a question that someone else asked at the
mic, or want to bring up a new topic.
**Requirement 04-30**: Remote attendee's requests MUST be part of the
floor control tool, not in the instant messaging system.
**Requirement 04-31**: The floor control portion of the RPS MUST give
a remote attendee who is allowed to speak a clear signal when they
should and should not speak.
**Requirement 04-32**: The chair MUST be able to see all requests
from remote attendees to speak at any time during the entire meeting
(not just during presentations) in the floor control system.
**Requirement 04-33**: The floor control system MUST allow a chair to
easily turn off and on an individual's ability to speak over the
audio at any time.
**Requirement 04-34**: The floor control system MUST allow a chair to
easily mute all remote attendees.
**Requirement 04-35**: The floor control system MUST allow a chair to
easily allow all remote attendees to speak without requesting
permission; that is, the chair MUST be able to easily turn on all
remote attendees mics at once.
**Requirement 04-36**: The floor control system for the chair MUST be
able to be run by at least two users at the same time. It is common
for a chair to leave the room, to have a side discussion with an AD,
or to become a presenter. They should be able to do so without
having to do a handoff of the floor control capability.
**Requirement 04-37**: The RPS MUST authenticate users who can use
the floor control system in a particular meeting using simple
passwords.
**Requirement 04-38**: The IETF Secretariat MUST be able to easily
set up the individuals allowed to use the floor control system for a
particular meeting and to change the settings at any time, including
during the meeting.
**Requirement 04-39**: The chair SHOULD be able to monitor the sound
levels of the audio being delivered to remote attendees to be sure
that they can hear what is going on in the room.
2.4. Video
The IETF has experimented with one-way and two-way video at some
meetings in the past few years. Remote attendees have said that
seeing people in the meetings gave them a better understanding of the
meeting; at a recent meeting, a remote presenter was able to see the
people in line at the mic and was better able to interact with them.
The requirements for video from remote attendees to meeting rooms
parallel the requirements for audio from remote attendees to meeting
rooms. The IETF video may need to integrate with the video systems
at some meeting venues.
2.4.1. Video from the Room to Remote Attendees
**Requirement 04-40**: Remote attendees MUST be able to see the
presenter at a meeting. A lower-priority requirement is that remote
attendees SHOULD be able to see who is speaking at the mics in the
room.
**Requirement 04-41**: Remote attendees MUST be able to see local
attendees at any mic in the meeting.
2.4.2. Video from Remote Attendees to the Room
Note that the requirements in this section have the same priorities
as for audio for remote presentations (Section 2.3.3) and audio from
remote attendees to the room for comments (Section 2.3.4).
**Requirement 04-42**: When video is allowed for remote attendees to
give presentations (as described in Section 2.3.3), the audience in
the room SHOULD be able to see the presenter speaking.
**Requirement 04-43**: When video is allowed for remote attendees for
comments, the floor management tool for audio (as described in
Section 2.3.4.1) MUST also control video as well.
**Requirement 04-44**: The RPS MUST have the capability of showing
video of the remote attendee who is speaking over the audio to the
local attendees.
**Requirement 04-45**: A remote attendee who is speaking MUST be able
to choose what is shown to local attendees: video of them speaking, a
still picture of their face or avatar, or just their name.
**Requirement 04-46**: The RPS MUST give a remote attendee a clear
indication when their video image or selected image is being shown to
the local attendees.
2.5. Slide Presentations and Distribution
**Requirement 04-47**: The RPS MUST be able to handle both PDF and
PowerPoint formats (".ppt" and ".pptx") for distributed slides.
**Requirement 04-48**: The RPS MUST automatically convert PowerPoint
presentations to PDF and make both available for distribution at the
same time.
**Requirement 04-49**: Presenters MUST be able to update their slides
on the IETF site up to just before their presentation, if such update
is allowed by the WG chairs.
**Requirement 04-50**: Chairs MUST be able to approve or disapprove
of any slide submission or updates, with the default being that all
submissions are allowed.
In many current remote participation systems, slide presentations and
the video coming from in-meeting cameras are sent as two separate
streams (called the "slide stream" and the "camera stream"). The
slide stream is usually much lower bandwidth than the camera stream,
so remote attendees with limited bandwidth can choose to watch just
the slide stream. Separating the streams allows remote attendees to
see the slide stream and the camera streams in separate windows that
can be independently sized.
**Requirement 04-51**: The RPS MUST transmit the slide stream
separately from the camera stream.
**Requirement 04-52**: The slide stream MUST represent the slides as
they are projected in the room, allowing the presenter to go back and
forth, as well as to edit slides in real time. This makes it clear
to the remote attendees which set of slides, and which slide number,
is being currently shown.
**Requirement 04-53**: When remote presentations are supported (see
Section 2.3.3), the remote presenter SHOULD be able to control the
slides. This is a lower-priority requirement because this could be
easily done by a local attendee listening to the remote presenter.
2.6. Shared Text Document Editing
In some WG meetings, there is an attempt to edit a text document with
input from the local attendees. This is typically done for proposed
charter changes, but sometimes happens on a WG document or the
meeting's agenda. This is usually unsuccessful, given the amount of
text and the size of what can be displayed on the screen. In recent
meetings, shared text document editing has been used for editing
charters and for taking minutes of meetings.
An RPS tool for shared text document editing would be equally useful
for local and remote attendees watching the edits happen in real-
time. There is a good chance that this tool would be watched by
local attendees on their laptops instead of being projected on the
screen because of the small size of the the text. This, in turn,
means that local attendees who aren't using their laptops at the
moment would not be able to participate by watching.
**Requirement 04-54**: Shared real-time editing of text documents
MUST be supported. This system must allow at least three people to
have write access and hundreds of people to have read access to any
particular document.
**Requirement 04-55**: It MUST be easy to start a new text shared
document and to import existing text into a shared document.
**Requirement 04-56**: Remote attendees MUST be able to be either the
writers or the readers of shared documents.
**Requirement 04-57**: Those with read access MUST be able to see the
edits made by those with write access within less that five seconds
after each edit.
**Requirement 04-58**: It MUST be easy to change the permissions for
who gets write access to a document during an editing session.
**Requirement 04-59**: A much-lower priority requirement is the
ability for group-editing of graphics.
2.7. Archiving
Archived recordings of the events of the meetings are valuable for
remote attendees who are not able to hear everything in real time.
**Requirement 04-60**: The RPS MUST support storage and distribution
of recordings of the audio, video, and slide presentations for all WG
meetings.
**Requirement 04-61**: Transcripts of the instant messaging for all
meetings MUST be kept for distribution after IETF meetings.
**Requirement 04-62**: The recordings and transcripts SHOULD be made
available during the meetings, within a day of them being made.
**Requirement 04-63**: Users MUST be able to easily find the archives
of the recordings and instant messaging transcripts of a particular
WG or BoF session at a particular meeting.
**Requirement 04-64**: The RPS SHOULD support indexing of archived
audio and video for particular events in meetings such as when
speakers change.
**Requirement 04-65**: The RPS MUST support recording and storage of
recordings of the audio, video, and slide presentations of interim
meetings as well as regular IETF meetings.
**Requirement 04-66**: Given that interim meetings are run without
the help of the IETF Secretariat, making these recordings MUST be
easy for WG chairs.
2.8. Polling
The common IETF method of assessing support is a straw poll,
sometimes managed by audible humming, sometimes by raising hands.
**Requirement 04-67**: A system for yes/no/abstain polling meeting
attendees, including remote attendees at the same time, MUST be
provided. It MUST be easy to set up a simple poll, and it must be
easy for all local and remote attendees to find the poll and
participate. Note that this would add a requirement that everyone in
a meeting be using their computer to participate in the poll.
2.9. Plenaries
**Requirement 04-68**: Remote attendees SHOULD be able to make
comments at the mic approximately as well as if they were local
attendees. This means that either remote audio to the plenary room
speakers be available, or that IM-to-room relay be available.
**Requirement 04-69**: Transmitting real-time transcription of
plenary speakers to remote attendees MUST be supported. The lag in
transmission MUST be less than five seconds.
2.10. Use by IETF Leadership
The requirements for bodies like the IESG and IAB to use the RPS
during regular IETF meetings are similar to those of most WGs. The
main difference is that they need a way to limit who can participate
remotely.
**Requirement 04-70**: The chair or meeting facilitator MUST be able
to easily limit remote access of all tools (both for listening/
observing and contributing) to meetings on a room-by-room basis.
**Requirement 04-71**: The IETF Secretariat must be able to limit
attendees in restricted meetings using a simple authentication
mechanism.
Note that the IETF leadership will also heavily use the remote
participation tools between IETF meetings in a manner that is very
similar to virtual interim meetings.
2.11. Preparation
Both WG chairs and attendees need to be able to prepare for an IETF
meeting and individual WG meetings. The more tools that might be
used in a meeting, the more important it is that the chairs and
attendees be able to prepare easily.
2.11.1. Preparation for WG Chairs
**Requirement 04-72**: WG chairs MUST be able to test whether or not
the tools for their session are working at least 30 minutes before
the meeting begins (unless, of course, there is already another
meeting occurring in the room during that time).
**Requirement 04-73**: There MUST be written operational
documentation for each RPS tool that is accessible at all times.
This will help reduce problems where a WG chair is having problems
during a meeting that is affecting the meeting as a whole.
**Requirement 04-74**: There SHOULD be training materials for WG
chairs in how to use the RPS tools.
**Requirement 04-75**: There SHOULD be a tool that allows a WG chair
to prepare each tool that will be used in their WG meeting. Such a
tool would let the WG chair specify which RPS tools they will use.
**Requirement 04-76**: There SHOULD be a custom checklist for each WG
that helps the chair prepare for their meeting. The checklist would
enumerate the steps needed before the meeting begins, to start the
meeting, during the meeting, to close the meeting, and after a
meeting.
2.11.2. Preparation for Remote Attendees
**Requirement 04-77**: Remote attendees MUST be able to easily find
all the material they need to effectively participate, including
links to audio, video, instant messaging, slides, and so on. This
material MUST be available well before the time of the meeting. The
page with the meeting material SHOULD allow the remote attendee to
easily perform a time conversion to and from the local time at the
IETF meeting.
**Requirement 04-78**: There MUST be a constantly-running testing
service that covers all interactive tools (audio, video, slide
display, and so on) for at least a week before the meeting begins.
Remote attendees need to be able to test the remote participation
setup before a regular meeting, and even during the meeting.
**Requirement 04-79**: The testing service MUST run throughout the
meeting so that last-minute joiners can test their systems.
**Requirement 04-80**: The testing service SHOULD allow remote
attendees to also test whether their outgoing audio, video, and slide
control works.
**Requirement 04-81**: A remote attendee who starts using one or more
tools after a meeting has begun MUST be able to tell what is
happening in the meeting. In specific, there MUST be an indication
if the meeting has not started, if the meeting is happening (even if
there is silence on the mics), and if the meeting is over.
3. Requirements for Supporting Remote Participation in Interim Meetings
One of the goals of this document is to increase the effectiveness of
interim meetings. Interim meetings are now uncommon, but might
become more common (and more effective) if the remote participation
becomes more useful.
The requirements for meetings that are all remote (that is, with no
local attendees) are mostly a subset of the requirements for remote
participation in a regular IETF meetings and face-to-face interim
meeting.
**Requirement 04-82**: The RPS SHOULD have a central location where
the specifics about how remote participation is supported for every
WG interim meeting. This will reduce the problems often seen where
messages about how to participate in an interim meeting get buried in
the WG mailing list.
**Requirement 04-83**: There SHOULD be documentation and training for
the RPS tools specifically targeted at WG chairs who will lead
interim meetings.
**Requirement 04-84**: The RPS tools MUST be at least partially
usable at face-to-face meetings other than regular IETF meetings.
The number of the tools that might be available will be different for
different venues for the virtual interims, but at a minimum, the
following MUST be supported for remote attendees:
o Registration
o Room audio
o Instant messaging
o Slide distribution
o Slide presentation
o Shared document editing
4. IANA Considerations
None. [[ ...and thus this section can be removed before publication
as an RFC... ]]
5. Security Considerations
People who participate remotely in face-to-face IETF meetings might
expect the same level of privacy as they have when they participate
directly in those meetings. Some of the proposed tools might cause
it to be easier to know which WGs a remote attendee was following.
When RPS tools are deployed, the IETF should describe the privacy
implications of using such a tool to the users so they can decide
whether or not to use the tools.
The eventual RPS tools will have some user authentication that will
associate people with actions. For example, a remote user might need
to authenticate to the system in order to give a presentation or
speak during a session. The credentials needed for this
authentication will need to be managed in a secure fashion, both by
the system and by the people who are being identified.
6. Acknowledgements
Many of the ideas in this document were contributed by members of the
IETF community based on their experiences during recent IETF
meetings. There are also many contributions from people on the
vmeet@ietf.org mailing list, WG chairs, and attendees in the RPSREQS
BoF at IETF 83 in Paris.
Some of the text in this document originated in the request for
proposals that was issued by the IAOC that led to this document.
7. Informative References
[BCP78] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 6121, March 2011.
[RPS-RFP] IAOC, "Request for Proposals for Requirements Development
for Remote Participation Services", 2011, <http://
iaoc.ietf.org/documents/
RPS-Specifications-RFP-2011-10-19.pdf>.
Appendix A. Background on IETF Remote Participation
The IETF has a long history of using remote participation tools.
This history causes many IETF participants to have strong opinions
about what future tools should provide and who should benefit from
those tools. The purpose of this section is to describe many of the
common perceptions of the current tools so that the reader
understands what might be expected of future tools.
Users' experience with the current IETF tools vary widely. Some
participants think the tools are fine and are grateful that they
exist. Other participants find them barely acceptable because they
have used better tools in other environments. Often, local attendees
mostly forget that the remote attendees are participating until one
gets gets reminded, such as by something said at the mic. Local
attendees don't have a feeling for how many remote attendees are just
listening like most of the local attendees.
The variety of current experiences can help inform the discussion of
how to improve the tools. The experiences described in this appendix
are derived from the current tools. It is important to note that
people who attend IETF meetings often experience the tools quite
differently than those who participate remotely.
The IETF has years of experience with the three primary tools used at
its regular meetings: prepared slides that are distributed before and
during the meeting, Jabber for IM, and streaming audio. This section
discusses some of the reactions of users -- those in the meetings and
those who have participated remotely -- to the current tools.
Remote attendees typically participate by asking questions or making
statements during or after presentations, and they also participate
in discussions in the instant messaging channel. Local attendees who
are using the RPS typically don't participate "remotely": they are
using the tools to be able to see what is happening in different
rooms when they need to be two or more places at once.
A.1. How the IETF Meets
o WG sessions at regular IETF meetings -- A typical regular IETF o WG sessions at regular IETF meetings -- A typical regular IETF
meeting has about 150 sessions, with up to 8 of those sessions meeting has about 150 sessions lasting one to two and one half
happening at the same time. A session might have between 20 and hours each, with up to 8 of those sessions happening at the same
200 local attendees in the room, and might have only a few or many time. A session might have between 20 and 200 local attendees in
dozens of remote attendees. WG sessions typically have one to the room, and might have only a few or many dozens of remote
three co-chairs at the front of the room and a series of attendees. WG sessions typically have one to three co-chairs at
individuals who come to the front to present; some presentations the front of the room and a series of individuals who come to the
are made by small panels. front to present; some presentations are made by small panels.
o Plenaries at regular IETF meetings -- There are usually two o Plenaries at regular IETF meetings -- There are usually two
plenaries at a regular IETF meeting, with on-site attendance of plenaries at a regular IETF meeting, with on-site attendance of
about 700 local attendees and dozens of remote attendees. There about 700 local attendees and dozens of remote attendees. There
are from 1 to 20 presenters; presentations may be made by multiple are from 1 to 20 presenters; presentations may be made by multiple
people. people.
o AD-sponsored lunch meetings at regular IETF meetings -- These
meetings are scheduled by the IETF Secretariat. Regular IETF
meetings are more than just a group of WG meetings. Remote
attendees may want to participate in the other parts of a regular
meeting as well.
o Face-to-face interim WG meetings -- Between regular IETF meetings, o Face-to-face interim WG meetings -- Between regular IETF meetings,
some WGs hold interim meetings where participants get together at some WGs hold interim meetings where attendees get together at a
a site (often a company's meeting room, but sometimes a meeting site (often a company's meeting room, but sometimes a meeting room
room rented at a hotel). At such meetings, there are between a rented at a hotel). At such meetings, there are between a handful
handful and a few dozen local attendees and a similar number of and a few dozen local attendees and a similar number of remote
remote attendees. Presentations are common. attendees, if remote participation is supported. Presentations
are common. There are typically fewer than 15 face-to-fact
interim meetings a year.
o Virtual interim WG meetings -- Between regular IETF meetings, some o Virtual interim WG meetings -- Between regular IETF meetings, some
WGs hold virtual interim meetings where there are no local WGs hold virtual interim meetings where there are no local
attendees because there is no central meeting location. There are attendees because there is no central meeting location. There are
between a handful and a few dozen attendees. Presentations are between a handful and a few dozen attendees. Presentations are
common. common. There are typically fewer than 25 face-to-fact interim
meetings a year.
o IETF leadership meetings -- The IETF leadership (the IESG, IAOC, o IETF leadership meetings -- The IETF leadership (the IESG, IAOC,
IAB, and probably others) have periodic virtual meetings, usually IAB, and probably others) have periodic virtual meetings, usually
with presentations. These groups also meet at the regular IETF with presentations. These groups also meet at the regular IETF
meetings, and sometimes have remote attendees at those meetings meetings, and sometimes have remote attendees at those meetings
(such as members who cannot attend the IETF meeting or presenters (such as members who cannot attend the IETF meeting or presenters
who are not part of the leadership group). who are not part of the leadership group).
[[[ TODO: Count the number of f2f and virtual interims from the past The form of "presentations" changes from meeting to meeting, but
few years. ]]] almost always includes prepared static slides and audio of the
speaker. Presentations sometimes also includes non-static slides
3. Interactions with Current RPS Tools Used by the IETF (usually animations within a slide) and sometimes video.
Users' experience with the current IETF tools vary widely. Some
participants think the tools are fine and are grateful that they
exist. Other participants find them barely acceptable because they
have used better tools in other environments. Often, local attendees
mostly forget that the remote attendees are participating until one
gets something said at the mic. Local attendees don't have a feeling
for how many remote attendees are just listening like most of the
local attendees.
The variety of current experiences can help inform the discussion of
how to improve the tools. The requirements here are derived from the
current tools; later sections derive requirements from needs that are
not at all met by the current tools.
The IETF has years of experience with the two primary tools used at
its regular meetings (Jabber for IM and streaming audio). This
section discusses some of the reactions of users -- those in the
meetings and those who have participated remotely -- to the current
tools.
3.1. Technologies Currently Used at Regular IETF Meetings A.2. Technologies Currently Used at Regular IETF Meetings
There are three tools that are used by remote attendees for WG There are three tools that are used by remote attendees for WG
participation at regular IETF meetings: real-time audio, instant participation at regular IETF meetings: real-time audio, instant
messaging, and slides. messaging, and slides.
For the past few years, the IETF has used audio streamed over HTTP For the past few years, the IETF has used audio streamed over HTTP
over TCP. TCP is often buffered at many places between (and in) the over TCP. TCP is often buffered at many places between (and in) the
origination in the IETF meeting venue and the users' computer. At origination in the IETF meeting venue and the users' computer. At
recent meetings, delays of around 30 seconds have been recorded, with recent meetings, delays of around 30 seconds have been recorded, with
minimum delays typically being five seconds. This delay is caused by minimum delays typically being five seconds. This delay is caused by
skipping to change at page 8, line 49 skipping to change at page 22, line 27
computer. At recent IETF meetings, remote attendance is almost computer. At recent IETF meetings, remote attendance is almost
always less than 10% of local attendance, and is often less than 5%. always less than 10% of local attendance, and is often less than 5%.
(There are more remote attendees when the IETF meeting is in the (There are more remote attendees when the IETF meeting is in the
U.S.) Each stream is represented by an MP3 playlist (sometimes called U.S.) Each stream is represented by an MP3 playlist (sometimes called
an "m3u file"). an "m3u file").
The IETF long ago standardized on Jabber / XMPP ([RFC6120], The IETF long ago standardized on Jabber / XMPP ([RFC6120],
[RFC6121], and others) for instant messaging used within the IETF. [RFC6121], and others) for instant messaging used within the IETF.
Jabber rooms (formally called "multi-user conferences" or "MUCs") Jabber rooms (formally called "multi-user conferences" or "MUCs")
exist for every WG, and those rooms are live all the time, not just exist for every WG, and those rooms are live all the time, not just
during regular IETF meetings. There are also stable Jabber rooms for during regular IETF meetings. BoFs have jabber rooms that are
the plenaries and certain other activities. BoFs are usually available during IETF meetings. There are also stable Jabber rooms
for the plenaries and certain other activities. BoFs are usually
assigned Jabber rooms before a regular meeting. assigned Jabber rooms before a regular meeting.
Presentation slides normally are stored either as PDFs or in one of Presentation slides normally are stored either as PDFs or in one of
Microsoft's formats for PowerPoint. They are projected on a local Microsoft's formats for PowerPoint. They are projected on a local
screen from someone's laptop computer. screen from someone's laptop computer. Proceedings are currently
stored as PDF of the slides, although they used to be stored as HTML.
There has been experience at recent meetings with two tools, WebEx There has been experience at recent meetings with two tools, WebEx
and Meetecho, which are supported experimentally by the IETF. Each and Meetecho, which are supported experimentally by the IETF. Each
tool was used by a handful of WGs with mixed success. The tools tool was used by a handful of WGs with mixed success. The tools
require remote attendees to use specific clients, and installation of require remote attendees to use specific clients, and installation of
those clients caused problems for some people. On the other hand, those clients caused problems for some people. On the other hand,
the tools have much more robust meeting control features, and the tools have much more robust meeting control features, and
participants appreciated the real-time showing of slides during attendees appreciated the real-time showing of slides during
presentations. presentations.
3.2. Locating the Meeting Information A.3. Locating the Meeting Information
Finding information for the real-time audio, instant messaging, and Finding information for the real-time audio, instant messaging, and
slides for an upcoming or current regular meeting is complicated by slides for an upcoming or current regular meeting is complicated by
that information being in many different locations on the IETF web that information being in many different locations on the IETF web
site, and the fact that the relevant URLs can change before and even site, and the fact that the relevant URLs can change before and even
during the meeting. Further, a WG chair might copy the latest during the meeting. Further, a WG chair might copy the latest
information and send it to the WG mailing list, but there can be information and send it to the WG mailing list, but there can be
later changes. Experienced remote attendees have gotten used to later changes. Experienced remote attendees have gotten used to
checking just before the meeting itself, but even that does not checking just before the meeting itself, but even that does not
always guarantee the correct information. always guarantee the correct information.
skipping to change at page 9, line 42 skipping to change at page 23, line 21
o The official agenda on the IETF Datatracker includes links to o The official agenda on the IETF Datatracker includes links to
venue maps, WG charters, agendas, and Internet-Drafts. For venue maps, WG charters, agendas, and Internet-Drafts. For
example, see example, see
<https://datatracker.ietf.org/meeting/82/agenda.html>. <https://datatracker.ietf.org/meeting/82/agenda.html>.
o The unofficial "tools-style agenda" includes the same links as the o The unofficial "tools-style agenda" includes the same links as the
official agenda plus links to the presentations, audio, minutes, official agenda plus links to the presentations, audio, minutes,
Jabber room, and Jabber logs 9represnted as small icons). For Jabber room, and Jabber logs 9represnted as small icons). For
example, see <http://tools.ietf.org/agenda/82/>. example, see <http://tools.ietf.org/agenda/82/>.
3.2.1. Audio A.3.1. Audio
The URL for the audio stream for a WG or BoF meeting is based on the The URL for the audio stream for a WG or BoF meeting is based on the
room that the meeting is in. The audio streams are announced on the room that the meeting is in. The audio streams are announced on the
general IETF mailing list (ietf@ietf.org) before each meeting. general IETF mailing list (ietf@ietf.org) before each meeting.
A common complaint is that when a WG meeting moves to a different A common complaint is that when a WG meeting moves to a different
room, remote users need to know about the move so that they can use room, remote users need to know about the move so that they can use
the proper URL to hear the audio stream. The room changes are often, the proper URL to hear the audio stream. The room changes are often,
but not always, announced on WG mailing lists; when they are not but not always, announced on WG mailing lists; when they are not
announced, there is no easy way for a remote attendee to find out announced, there is no easy way for a remote attendee to find out
which audio stream they should be listening to. Sometimes, room which audio stream they should be listening to. Sometimes, room
changes happen just as a WG meeting is starting, making it nearly changes happen just as a WG meeting is starting, making it nearly
impossible for a remote attendee to know about the change in streams. impossible for a remote attendee to know about the change in streams.
3.2.2. Instant Messaging IETF meetings happen in venues such as hotels and conference centers,
most of which have their own audio setups. The IETF Secretariat
contracts with those venues for the use of some or all of their audio
system. Without such integration, audio from remote attendees might
not be reliably heard by local attendees.
A.3.2. Instant Messaging
The Jabber rooms used by WGs and BoFs do not change between IETF The Jabber rooms used by WGs and BoFs do not change between IETF
meetings, so finding the right Jabber room is relatively easy. Some meetings, so finding the right Jabber room is relatively easy. Some
Jabber clients have odd interfaces for joining Jabber rooms, and this Jabber clients have odd interfaces for joining Jabber rooms, and this
can cause some problems; even though participants can test their can cause some problems; even though attendees can test their Jabber
Jabber clients before a meeting, there still seems to be some who clients before a meeting, there still seems to be some who need help
need help just before a WG meeting. There are sometimes problems just before a WG meeting. There are sometimes problems with people
with people joining Jabber rooms; in these cases, the participant joining Jabber rooms; in these cases, the attendee needs to find
needs to find someone already in the Jabber room to invite them to someone already in the Jabber room to invite them to the discussion.
the discussion.
3.2.3. Slides A.3.3. Slides
Slides are presented in regular IETF meetings with projectors on a
screen at the front of the room from the video output of one or more
local attendees' computers. The same slides are available online for
remote attendees.
Slides are available to local and remote attendees on the IETF
servers before and during regular IETF meetings. This service is
useful to all attendees who want to be prepared for WG meetings. The
slides are not only used by remote attendees listening to the WG
meeting; it is common for local attendees to download the slides and
view them on their laptops during meetings instead of having to read
them from the front of the room.
Slides are available from the meeting materials page. Many, but Slides are available from the meeting materials page. Many, but
certainly not all, local and remote attendees know how to find the certainly not all, local and remote attendees know how to find the
meeting materials page. meeting materials page.
It has become fairly common for presenters to not have their It has become fairly common for presenters to not have their
presentations available for distribution until just before the WG presentations available for distribution until just before the WG
meeting. Because materials are uploaded by the WG chairs, this often meeting. Because materials are uploaded by the WG chairs, this often
causes the beginning of WG meetings to be a dance involving causes the beginning of WG meetings to be a dance involving
presenters giving the chairs their slides, followed by chairs presenters giving the chairs their slides, followed by chairs
uploading the slides to the IETF site, followed by the chairs saying uploading the slides to the IETF site, followed by the chairs saying
"the slides are there now". "the slides are there now".
3.3. Remote Participation at IETF Meetings A.4. Remote Participation at IETF Meetings
3.3.1. Remotely Speaking at the Mic A.4.1. Remotely Speaking at the Mic
Newcomers to regular IETF meetings often expect the floor control in
WG meetings to be fairly straight-forward. By Tuesday, they might be
shaking their heads, wondering why some people cut into the mic
lines, why some people get up to the mics after the chair has closed
the line, why some people ignore presenters' requests to hold
questions to the end, and so on. Mixing remote attendees into this
social structure will be a daunting task, but one that has been dealt
with in many remote participation systems.
In order for a remote attendee to speak at the mic, a local attendee In order for a remote attendee to speak at the mic, a local attendee
must say it for them. In most WG and BoF meetings, this is done by must say it for them. In most WG and BoF meetings, this is done by
the remote attendee typing into the Jabber room for the meeting, and the remote attendee typing into the Jabber room for the meeting, and
some local attendee going to the mic and repeating what was typed some local attendee going to the mic and repeating what was typed
into the Jabber room. Remote attendees often precede what they want into the Jabber room. Remote attendees often precede what they want
said at the mic with the string "mic:" to differentiate that from the said at the mic with the string "mic:" to differentiate that from the
rest of the discussion in the Jabber room. rest of the discussion in the Jabber room.
This method of participation often works adequately, but there are In some WGs, there have been experiments of getting remote attendees
many places where it fails. The following is a compendium of stories voices into the room either by hooking into the room's sound system
from recent IETF meetings and interim face-to-face meetings where or pointing a mic at the speaker of a laptop. This sometimes works,
remotely speaking at the mic didn't work as well as it could have. but sometimes has bad feedback and delay issues that make the remote
The participants are Chris and Carl (WG co-chairs), Sam (volunteer participation worse than having a person reading their comments at
Jabber scribe), Rachel and Robert (remote attendees), Pete the mic.
The "Jabber-to-mic" method of participation often works adequately,
but there are many places where it fails. It has issues similar to
most proxy approaches where a human is in center of the loop. The
following is a compendium of stories from recent IETF meetings and
interim face-to-face meetings where remotely speaking at the mic
didn't work as well as it could have. The list is given here to both
point out what some WGs are willing to put up with currently, and to
show what is needed if the eventual RPS uses Jabber-to-mic as part of
the solution. The attendees are Chris and Carl (WG co-chairs), Sam
(volunteer Jabber scribe), Rachel and Robert (remote attendees), Pete
(presenter), and Len and Lee (local attendees). (presenter), and Len and Lee (local attendees).
o Robert cannot understand what Pete is saying about slide 5, but o Robert cannot understand what Pete is saying about slide 5, but
Sam doesn't get Pete's attention until Pete is already on slide 7 Sam doesn't get Pete's attention until Pete is already on slide 7
and Pete doesn't want to go back. and Pete doesn't want to go back.
o Rachel wants to say something, but Sam's Jabber client has crashed o Rachel wants to say something, but Sam's Jabber client has crashed
and no one else in the Jabber room knows why Sam isn't going to and no one else in the Jabber room knows why Sam isn't going to
the mic. the mic.
skipping to change at page 13, line 5 skipping to change at page 27, line 21
o Sam only volunteered to be scribe because no one else would do it, o Sam only volunteered to be scribe because no one else would do it,
and isn't sitting close to the mic, and gets tired of getting up and isn't sitting close to the mic, and gets tired of getting up
and down all the time, and doesn't really agree with Robert on a and down all the time, and doesn't really agree with Robert on a
particular issue, so Sam doesn't relay a request from Robert. particular issue, so Sam doesn't relay a request from Robert.
o Rachel cannot join the Jabber room due to a client or server o Rachel cannot join the Jabber room due to a client or server
software issue. She finally finds someone else on Jabber who is software issue. She finally finds someone else on Jabber who is
also in the meeting, and gets them to invite her into the room. also in the meeting, and gets them to invite her into the room.
3.3.2. Remotely Presenting A.4.2. Remotely Presenting
Some WGs have experimented with remote presentations at regular IETF Some WGs have experimented with remote presentations at regular IETF
meetings, with quite mixed results. For some, it works fine: the meetings, with quite mixed results. For some, it works fine: the
remote presenter speaks, the chair moves the slides forward, and remote presenter speaks, the chair moves the slides forward, and
questions can be heard easily. For others, it is a mess: the local questions can be heard easily. For others, it is a mess: the local
attendees can't hear the presenter very well, the presenter can't attendees can't hear the presenter very well, the presenter can't
hear questions or there is a long delay, and it was not clear when hear questions or there is a long delay, and it was not clear when
the presenter was waiting for input or there was a lag in the sound. the presenter was waiting for input or there was a lag in the sound.
At a recent meeting that had a remote presenter, a WG had a video At a recent meeting that had a remote presenter, a WG had a video
skipping to change at page 13, line 30 skipping to change at page 27, line 46
head projected on the screen in the room, which led to a lot of jokes head projected on the screen in the room, which led to a lot of jokes
and discussion of whether seeing the remote presenter caused people and discussion of whether seeing the remote presenter caused people
to pay more attention. to pay more attention.
Remote presenters have commented how difficult it is to set up their Remote presenters have commented how difficult it is to set up their
systems, particularly because they are not sure whether their setup systems, particularly because they are not sure whether their setup
is working until the moment they are supposed to be presenting. Even is working until the moment they are supposed to be presenting. Even
then, the first few minutes of the presentation has a feeling of "is then, the first few minutes of the presentation has a feeling of "is
this really working?". this really working?".
[[[ TODO: More discussion about experiences with remote presenters. A.4.3. Floor Control
Include more discussion of where it went well. ]]]
3.3.3. Floor Control
Although Section 3.3.1 may seem like it is a bit harsh on WG chairs, Although Appendix A.4.1 may seem like it is a bit harsh on WG chairs,
the current tools do not give them the kind of control over remote the current tools do not give them the kind of control over remote
attendees that they have over local attendees. The chairs can tell attendees that they have over local attendees. The chairs can tell
what is happening at the mics, but have much less view into what is what is happening at the mics, but have much less view into what is
happening on Jabber, even if they are watching the Jabber room. happening on Jabber, even if they are watching the Jabber room.
Without as much view, they cannot assist the flow of the conversation Without as much view, they cannot assist the flow of the conversation
as well. as well.
o Carl sees that the Jabber room has an active and useful back- o Carl sees that the Jabber room has an active and useful back-
channel discussion during Pete's provocative presentation. Pete channel discussion during Pete's provocative presentation. Pete
finishes and asks for questions. Lee and Len rush to the mic finishes and asks for questions. Lee and Len rush to the mic
line, and it takes Robert a few seconds to get his question into line, and it takes Robert a few seconds to get his question into
the Jabber room and for Sam to go to the mic. Carl tries to the Jabber room and for Sam to go to the mic. Carl tries to
prioritize Sam forward in the line, but Len gets upset when he prioritize Sam forward in the line, but Len gets upset when he
does. does.
skipping to change at page 14, line 16 skipping to change at page 28, line 30
o Pete has run over time, Robert asks what is supposed to be the o Pete has run over time, Robert asks what is supposed to be the
last question, and Pete doesn't understand what Sam said. Carl last question, and Pete doesn't understand what Sam said. Carl
cannot tell whether to wait for Robert to rephrase the question or cannot tell whether to wait for Robert to rephrase the question or
whether Robert even heard Pete's response. whether Robert even heard Pete's response.
o In a virtual interim where remote attendees all participate by o In a virtual interim where remote attendees all participate by
voice, someone can be heard typing / eating / talking loudly to voice, someone can be heard typing / eating / talking loudly to
someone else. Carl and Chris try to get that person's attention someone else. Carl and Chris try to get that person's attention
over the audio and Jabber, but to no avail. The tool being used over the audio and Jabber, but to no avail. The tool being used
does not have the ability to mute individual participants, so the does not have the ability to mute individual attendees, so the
meeting is disrupted until that person finally realizes that he or meeting is disrupted until that person finally realizes that he or
she is not muted. she is not muted.
3.4. Remote Participation at IETF Interim WG Meetings Some of these problems are alleviated by some of the proprietary
solutions that have been experimented with. For example, WebEx and
other systems have a "raise hand" feature where a remote attendee can
indicate in the application or through a web form that they want to
speak.
3.4.1. Face-to-Face Interim Meetings A.5. Remote Participation at IETF Interim WG Meetings
Face-to-face interim meetings have many things in common with regular
IETF meetings, but there are also many significant differences. For
most WGs, fewer people attend interim meetings than IETF meetings,
although those who travel to a face-to-face interim meeting are often
the more active WG participants. There may be a larger demand for
remote participation because people have a harder time justifying
travel for a single WG meeting than for an IETF meeting, but there
may also be less demand because people tend to think of interim WG
meetings as less important than regular IETF meetings..
Typically, the IETF Secretariat does not control the rooms in which
face-to-face interims are held, so they have no control over whether
outgoing audio will be supported, or supported well enough to
guarantee that remote attendees can hear.
A.5.1. Face-to-Face Interim Meetings
Many interim meetings are held face-to-face in conference rooms Many interim meetings are held face-to-face in conference rooms
supplied by companies active in the IETF (and, much less often, in supplied by companies active in the IETF (and, much less often, in
commercial conference facilities such as hotels). Because these commercial conference facilities such as hotels). Because these
facilities are not controlled by the IETF Secretariat, the ability to facilities are not administered by the IETF Secretariat, the ability
include remote attendees varies widely. Some facilities can to include remote attendees varies widely. Some facilities can
distribute the in-room audio over the Internet just fine, while distribute the in-room audio over the Internet just fine, while
others have no or limited abilities to do so. others have no or limited abilities to do so.
For example, a recent face-to-face interim meeting was supposed to be For example, a recent face-to-face interim meeting was supposed to be
open to remote attendees through WebEx, but the sound coming from the open to remote attendees through WebEx, but the sound coming from the
room was too soft to hear reliably. Even if a face-to-face interim room was too soft to hear reliably. Even if a face-to-face interim
meeting has good facilities for audio and slide presenting, it will meeting has good facilities for audio and slide presenting, it will
probably have similar to regular IETF meetings. probably have an experience similar to regular IETF meetings.
3.4.2. Virtual Interim Meetings A.5.2. Virtual Interim Meetings
Because few WGs have virtual interim meetings (those with no face-to- Because few WGs have virtual interim meetings (those with no face-to-
face attendees), there is less experience with the tools that are face attendees), there is less experience with the tools that are
commonly used for them. The IETF has had free use of WebEx for a few commonly used for them. The IETF has had free use of WebEx for a few
years, and some WGs have used different tools for audio years, and some WGs have used different tools for audio
participation. For example, some virtual interims are held using participation. For example, some virtual interims are held using
Skype, others with TeamSpeak, and so on. Skype, others with TeamSpeak, and so on.
So far, the experience with virtual interim meetings has been So far, the experience with virtual interim meetings has been
reasonably good, and some people say that it is better than for reasonably good, and some people say that it is better than for
remote attendees at regular IETF meetings and face-to-face interims remote attendees at regular IETF meetings and face-to-face interims
because everyone has the same problems with getting the group's because everyone has the same problems with getting the group's
attention. Also, there are no problems getting the in-room audio attention. Also, there are no problems getting the in-room audio
into the RPS because all attendees are using their own computers for into the RPS because all attendees are using their own computers for
speaking to the group. speaking to the group.
One of the often-debated aspects of virtual interim meetings is what One of the often-debated aspects of virtual interim meetings is what
time to have them in order to make them available to all time to have them in order to make them available to all attendees.
participants. Such scheduling of virtual interim meetings is out of Such scheduling of virtual interim meetings is out of scope for this
scope for this document. However, it is noted that because many document. However, it is noted that because many attendees will be
participants will be attending at different times of day and night, attending at different times of day and night, no assumption can be
no assumption can be made that participants will be at an "office". made that attendees will be at an "office". This debate also affects
This debate also affects face-to-face interim meetings because the face-to-face interim meetings because the meeting hosts normally will
meeting hosts normally will schedule the meeting during business schedule the meeting during business hours at the host company, but
hours at the host company, but that might be terribly inconvenient that might be terribly inconvenient for some WG members.
for some WG members.
[[[ TODO: More discussion about experiences with virtual interims.
Focus on differences between the all-in-one systems like WebEx and
the cobble-together systems where there is an audio feed with no
floor control plus pre-distributed slideware. ]]]
4. Requirements for Supporting Remote Participation in Regular IETF
Meetings
This section covers the requirements and functional specification for
effective remote participation in meetings where some members are in
regular IETF face-to-face meetings. Some of the requirements in this
section overlap with those in Section 5, but many are unique to
meetings that have a large number of attendees physically present.
There is an assumption in this section that the meeting chairs will
continue to control the flow of the discussion. That is, if a
presenter is speaking and a remote attendee wants to ask a question,
the request to do so goes to the chair, not to the presenter. This
is covered in more detail in Section 4.2.2.1.
**Requirement 03-01**: The specifications SHOULD rely upon IETF and
other open standards for all communications and interactions wherever
possible.
**Requirement 03-02**: All tools in the RPS SHOULD be able to be run
on the widest possible array of computers. The tool may be a stand-
alone application, from any modern web browser, or from the command
line, but needs to be available on all of (at least) MacOS version
10.6 or later, Windows 7 or later, and any common Linux distribution
produced in 2010 or later. This also means that the tools MUST NOT
rely on Adobe Flash to work correctly. [[[ TODO: Do we need to
include IOS and Android platforms in that list? ]]]
**Requirement 03-03**: Audio, video, instant messaging, and slide
streams going to and from remote attendees SHOULD be delivered in as
close to real-time as is practically possible. A common complaint
with the current RPS is that the streaming audio can take more than
10 seconds (and sometimes as much as 30 seconds) to reach the remote
attendee. This causes many of the problems listed in Section 3.3.1.
[[[ TODO: Proposed replacement for this requirement is "Delays MUST
be less than X milliseconds greater than the network delay to the
remote attendee." Two values for X have been proposed: 200 and 500.
]]]
[[[ TODO: A possibly different way to set the requirement is "The
audio MUST achieve a MOS (Mean Opinion Score) of 3.5 or better." And
there should probably be a discussion of a possible equivalent for
video. A proposal was "320x240 @ 15fps". ]]]
**Requirement 03-04**: The outgoing audio, video, and slide streams
MUST have the same delays so the remote participant does not get
confused during slide presentations.
**Requirement 03-05**: All streaming information from the RPS MUST be
usable over slow Internet connections. Many remote attendees will be
in places with limited bandwidth. [[[ TODO: We need to define "slow"
here, or drop the requirement.]]]
**Requirement 03-06**: All proposed tools MUST detail the bandwidth
required for each participant for various levels of participation
(audio-only, audio and video, and so on).
[[[ TODO: Is there a requirement for PSTN for audio-only? ]]]
**Requirement 03-07**: Audible echo in the audio stream MUST be
damped and/or eliminated by the tools. [[[ TOOD: Proposed
replacement: the RPS MUST recognize audible echo and automatically
take measures to reduce it to a level which won't distract listeners.
]]]
**Requirement 03-08**: WG chairs MUST be able to test whether or not
the tools for their session are working at least 30 minutes before
the meeting begins (unless, of course, there is already another
meeting occurring in the room during that time).
**Requirement 03-09**: There MUST be written operational
documentation for each RPS tool that is accessible at all times.
This will help reduce problems where a WG chair is having problems
during a meeting that is affecting the meeting as a whole.
**Requirement 03-10**: There SHOULD be training materials for WG
chairs in how to use the RPS tools.
4.1. Registration for Remote Participation
There has been periodic discussion of whether or not remote attendees
are bound by the "Note Well" text that local attendees are bound to.
The core question is which local and remote attendees are
"contributors" based on the definitions in [BCP78]. By requiring
registration before participating, remote attendees can be better
alerted to, and thus hopefully bound to, the requirements of
contributors.
The cost for remote attendees to register, if any, is not covered in
this document but will instead be determined by the IETF at a later
time. There are many ideas on the subject (tiered costs for
different services, no cost at all for the first year, and others),
but the effects of different cost structures is beyond the scope of
this document.
**Requirement 03-11**: All remote attendees MUST register with the
IETF Secretariat before using any of the RPS tools described here.
Note that this would be a significant change to the current RPS tools
in that an unregistered person would not be able to use the IM
system. [[[ TODO: Should this be split into "unregistered people can
listen and read, but not contribute"? ]]]
**Functional spec 03-01**: The RPS MUST have a system where a remote
attendee can register their name and have that name be used in the
instant messaging and video systems. Registration must only need to
be done once for an entire regular IETF meeting.
**Requirement 03-12**: A remote attendee may register a nickname that
will be shown to other attendees during the meeting. A remote
attendee must register with a "verified" name with the IETF
Secretariat. The nickname will appear in video and instant
messaging. [[[TODO: Is this anonymity appropriate in light of the
"note well" and floor control requirements? ]]]
**Requirement 03-13**: The RPS tools (particularly the registration
tool) MUST gracefully handle multiple attendees who have the same
name.
**Functional spec 03-02**: To support the "blue sheet" functionality
for remote attendees, the registration tool SHOULD allow a registered
user to indicate which sessions he or she attended. This notations
SHOULD be allowed for all WG meetings throughout the meeting period.
The registration system SHOULD remind all registered remote attendees
at the end of the week to update their notations.
4.2. Audio
Audio from face-to-face meetings travels in two directions: from the
room to remote attendees, and from remote attendees to the room.
A few requirements come from the IETF's current use of audio in
meetings. Meeting rooms have many mics: one or two for the chairs,
one for the presenter, and at least one for other local attendees to
ask questions. Plenaries have many more mics, both at the front of
the room and in the audience.
**Requirement 03-14**: Remote attendees MUST be able to hear what is
said by local attendees and chairs at any mic in the meeting.
Comments on early drafts of this document indicated that the latter
may not really be a requirement for all participants if IM-to-mic is
made predictable. The two options are split below to make the
discussion clearer. Note that even if the consensus is towards IM-
to-mic, remote-to-room might still be required to enable remote
presenters; in this case, there would probably be little need for
floor control. The requirements for audio are expected to be
important discussion points in future versions of this document.
[[[ TODO: Should the ability to dial into a meeting stream via POTS
be a requirement? ]]]
4.2.1. IM-to-Mic Relay of Comments from Remote Participants
As described in Section 3.3.1, the current tools support an informal
method for remote attendees to speak at the mic: in the Jabber room,
they enter "mic:" before their comment and hope that the designated
scribe or someone else goes to the mic to relay the comment. This
method works, but has significant flaws described in that section.
**Requirement 03-15**: Relay of messages from IM to the mic MUST
happen as quickly as if the remote attendee was local.
**Requirement 03-16**: The person relaying from IM to the mic must be
available throughout the WG meeting. This could be facilitated by
hiring people to attend meetings for the specific purpose of being
IM-to-mic scribes.
**Requirement 03-17**: If multiple remote attendees want to comment
at the same time, the person relaying from IM to the mic MUST be able
to relay for all of them.
Note: during the development of this document, there have been many
suggestions for how WG chairs can better manage the IM-to-mic
relaying (for example, with planned pauses, better tracking of the IM
room, and so on). Some of those suggestions might turn into
requirements to be included in this document, but so far most of them
seem to be really about improving WG chairs, not the RPS tools.
4.2.2. Audio from Remote Participants to the Room
Note that the requirements here assume a very large change in the way
that remote participation will happen. Instead of a remote attendee
typing something into the Jabber room that someone will repeat at a
mic in the room, remote attendees will use their own mics to speak to
the meeting.
**Requirement 03-18**: Remote attendees MUST be able to speak
directly to a meeting without going through a local attendee, and
have their speaking be heard by local attendees. (Note that the
ability to speak is controlled by the chair; see Section 4.2.2.1.)
**Requirement 03-19**: Local attendees MUST be able to determine
which remote attendee is speaking. If the remote attendee is using a
nickname (see Requirement 03-12), that nickname can be used by the
remote speaker.
**Requirement 03-20**: The floor control portion of the RPS MUST give
a remote attendee who is allowed to speak a clear signal when they
should and should not speak.
**Requirement 03-21**: The audio system used by the RPS MUST be able
to integrate with systems commonly used in the venues used for IETF
meetings. IETF meetings happen in venues such as hotels and
conference centers, most of which have their own audio setups. The
IETF Secretariat contracts with those venues for the use of some or
all of their audio system. Without such integration, audio from
remote attendees might not be reliably heard by local participants.
**Requirement 03-22**: When a remote attendee connects to the audio
stream to the room, their mic SHOULD start off muted. This will
prevent problems such as those common with WebEx where a remote
attendee doesn't realize that they can be heard.
**Requirement 03-23**: Remote participants MUST be able to unmute
themselves; unmuting MUST NOT require interaction from the chair.
4.2.2.1. Floor Control for Chairs for Audio from Remote Attendees
Newcomers to regular IETF meetings often expect the floor control in
WG meetings to be fairly straight-forward. By Tuesday, they might be
shaking their heads, wondering why some people cut into the mic
lines, why some people get up to the mics after the chair has closed
the line, why some people ignore presenters' requests to hold
questions to the end, and so on. Mixing remote attendees into this
social structure will be a daunting task, but one that has been dealt
with in many remote participation systems.
It is not yet clear how the set of remote attendees would be treated
for queueing. Some tools have each remote attendee being considered
separately, while others pool all remote attendees into one group.
This affects the chair knowing and being able to act on the order
that remote attendees ask to speak.
Note that, if the remote video to room requirements from
Section 4.3.2 need to be met, it is very likely that a related
requirement to those below is that "the audio and video floor
controls must be in the same tool".
**Requirement 03-24**: Remote attendees MUST have an easy and
standardized way of requesting the attention of the chair when the
remote attendee wants to speak. The remote attendee MUST also be
able to easily cancel an attention request. (Note that Requirement
03-62 implies that someone is watching the request queue, something
that does not happen consistently with the current tools.)
**Functional spec 03-03**: The RPS MUST allow a remote attendee's
request for attention to include an optional short text string. A
remote attendee might want to indicate that they are asking a
question of the presenter, or answering a question that someone else
asked at the mic, or want to bring up a new topic.
**Functional spec 03-04**: Remote attendee's requests MUST be part of
the floor control tool, not in the instant messaging system.
**Requirement 03-25**: The chair MUST be able to see all requests
from remote attendees to speak at any time during the entire meeting
(not just during presentations) in the floor control system.
**Requirement 03-26**: The floor control system MUST allow a chair to
easily turn off and on an individual's ability to speak over the
audio at any time.
**Requirement 03-27**: The floor control system MUST allow a chair to
easily mute all remote attendees.
**Requirement 03-28**: The floor control system MUST allow a chair to
easily allow all remote attendees to speak without requesting
permission; that is, the chair MUST be able to easily turn on all
remote attendees mics at once.
**Requirement 03-29**: The floor control system for the chair MUST be
able to be run by at least two users at the same time. It is common
for a chair to leave the room, to have a side discussion with an AD,
or to become a presenter. They should be able to do so without
having to do a handoff of the floor control capability.
**Functional spec 03-05**: The RPS MUST authenticate users who can
use the floor control system in a particular meeting using simple
passwords.
**Requirement 03-30**: The IETF Secretariat MUST be able to easily
set up the individuals allowed to use the floor control system for a
particular meeting and to change the settings at any time, including
during the meeting. [[[ TODO: Should those who are given floor
control be allowed to augment that list to meet changing needs
without going back to the Secretariat? ]]]
[[[ TODO: Is it possible to tell if a remote attendee who is speaking
loses network connectivity? If so, maybe this can be shown to the
chair. ]]]
**Requirement 03-31**: The chair SHOULD be able to monitor the sound
levels of the audio being delivered to remote attendees to be sure
that they can hear what is going on in the room.
4.3. Video
The RFP that preceded the current document, [RPS-RFP], discusses
video as a requirement. The IETF has experimented with one-way and
two-way video at some meetings in the past few years. Remote
attendees have said that seeing people in the meetings gave them a
better understanding of the meeting; at a recent meeting, a remote
presenter was able to see the people in line at the mic and was
better able to interact with them. [[[ TODO: determine how much of
this is needed for effective participation. ]]]
4.3.1. Video from the Room to Remote Participants
**Requirement 03-32**: Remote attendees MUST be able to see the
presenter at a meeting.
**Requirement 03-33**: Remote attendees MUST be able to see local
attendees at any mic in the meeting.
[[[ TODO: Is there a requirement that IETF video integrate with the
venue video, if any? ]]]
4.3.2. Video from Remote Participants to the Room
Note that the requirements in this section probably only apply if
there is consensus that audio from remote participants to the room is
required. If so, there will probably also be requirements for video
floor control as well.
**Requirement 03-34**: The RPS MUST have the capability of showing
video of the remote attendee who is speaking over the audio to the
local attendees.
**Requirement 03-35**: A remote attendee who is speaking MUST be able
to choose what is shown to local attendees: video of them speaking, a
still picture of their face, or just their name.
**Requirement 03-36**: The RPS MUST give a remote attendee a clear
indication when their video image is being shown to the local
attendees.
[[[ TODO: The way to fulfill these might be that the IETF provide a
laptop for the chair that has the right tools on it, and that laptop
is the one connected to the projector. ]]]
4.4. Instant Messaging
Instant messaging (IM) is used both as a remote participation tool
and as a communication tool for local attendees at a regular meeting.
As noted earlier, while the current tool's Jabber room is a good way
to get questions to the mic, it also becomes a second communications
channel that only a few people in the room are participating in.
This document does not address how to prevent that problem (or
whether it really is much of a problem). The instant messaging
system is also useful for remote users to ask about the status of the
room ("is anyone there?").
**Requirement 03-37**: The IM system MUST allow anyone to see all
messages in the WG's or BoF's room.
**Requirement 03-38**: The IM system MUST allow any registered user
(even those registered to use anonymous names) to post messages in
the WG's or BoF's room.
**Requirement 03-39**: The date and time that a message appears in an
IM stream MUST be retained. IM clients MUST be able to show an
indication of the date and time for all messages. Someone coming
into a meeting late requires context for which messages in an instant
messaging room are recent and which are old.
[[[ TODO: Should there be multiple rooms for a meeting? There were
many requests for a separate "speak into the mic" room, but that is
not needed if the requirements in Section 4.2.2 are met. Is there a
need for other rooms? ]]]
[[[ TODO: Should non-registered people be allowed to read the IM
traffic in real time, given that anyone can register anonymously?
Should people registered anonymously be allowed to post in IM rooms?
Should non-registered attendees be able to post to the IM rooms? ]]]
4.5. Slide Presentations
Slides are presented in regular IETF meetings with projectors on a
screen at the front of the room from the video output of one or more
local attendees' computers. If slides are to be presented to remote
attendees, the slides being projecte need to also be sent as a stream
to the remote attendees.
In many current remote participation systems, slide presentations and
the video coming from in-meeting cameras are sent as two separate
streams (called the "slide stream" and the "camera stream"). The
slide stream is usually much lower bandwidth than the camera stream,
so remote attendees with limited bandwidth can choose to watch just
the slides but not the local attendees. Further, separating the
streams allows remote attendees to see the slide stream and the
camera streams in separate windows that can be independently sized.
**Functional spec 03-06**: The RPS MUST transmit the slide stream
separately from the camera stream.
**Requirement 03-40**: The slide stream MUST represent the slides as
they are projected in the room, allowing the presenter to go back and
forth, as well as to edit slides in real time.
**Requirement 03-41**: It MUST be made clear to the remote attendees
which set of slides, and which slide number, is being currently
shown.
[[[ TODO: If the slides will be visible to remote attendees as they
are presented, is there a requirement that presenters be able to use
the equivalent of a laser pointer? ]]]
4.6. Slide Distribution
Slides are available to local and remote attendees on the IETF
servers before and during regular IETF meetings. This service is
useful to all attendees who want to be prepared for WG meetings. The
slides are not only used by remote attendees listening to the WG
meeting; it is common for local attendees to download the slides and
view them on their laptops during meetings instead of having to read
them at the front of the room.
**Functional spec 03-07**: The RPS MUST be able to handle both PDF
and PowerPoint formats (".ppt" and ".pptx") for distributed slides.
[[[ TODO: Is there a requirement to support other formats? ]]] [[[
TODO: For the distributed slides, is there a requirement that
animation in PowerPoint be supported, or just static slides? ]]]
**Functional spec 03-08**: The RPS MUST automatically convert
PowerPoint presentations to PDF and make both available for
distribution at the same time.
**Requirement 03-42**: Presenters MUST be able to update their slides
on the IETF site up to just before their presentation, if such update
is allowed by the chairs.
**Requirement 03-43**: Chairs MUST be able to approve or disapprove
of any slide submission or updates, with the default being that all
submissions are allowed.
4.7. Shared Document Editing
In some WG meetings, there is an attempt to edit a document with
input from the local attendees. This is typically done for proposed
charter changes, but sometimes happens on a WG document or the
meeting's agenda. This is usually unsuccessful, given the amount of
text and the size of what can be displayed on the screen. In recent
meetings, shared document editing has been used for editing charters
and for taking minutes of meetings.
An RPS tool for shared document editing would be equally useful for
local and remote attendees watching the edits happen in real-time.
There is a good chance that this tool would be watched by local
attendees on their laptops instead of being projected on the screen
because of the small size of the the text. This, in turn, means that
local attendees who aren't using their laptops at the moment would
not be able to participate by watching.
**Requirement 03-44**: It MUST be easy to start a new shared document
and to import existing text into a shared document.
**Requirement 03-45**: Shared real-time editing of text-only
documents MUST be supported. This system must allow at least three
people to have write access and hundreds of people to have read
access to any particular document.
**Requirement 03-46**: Remote attendees MUST be able to be either the
writers or the readers of shared documents.
**Requirement 03-47**: Those with read access MUST be able to see the
edits made by those with write access within less that five seconds
after each edit.
**Requirement 03-48**: It MUST be easy to change the permissions for
who gets write access to a document during an editing session.
[[[ TODO: Is this also needed for non-text documents? If so, in what
formats? For example, is drawing on a whiteboard needed? ]]]
4.8. Archiving
Archived recordings of the events of the meetings are valuable for
remote attendees who are not able to hear everything in real time.
**Requirement 03-49**: The RPS MUST support storage and distribution
of recordings of the audio, video, and slide presentations for all WG
meetings.
**Requirement 03-50**: Transcripts of the instant messaging for all
meetings MUST be kept for distribution after IETF meetings.
**Requirement 03-51**: The recordings and transcripts SHOULD be made
available during the meetings, within a day of them being made.
**Requirement 03-52**: Users MUST be able to easily find the archives
of the recordings and instant messaging transcripts of a particular
WG or BoF session at a particular meeting.
**Requirement 03-53**: The RPS SHOULD support indexing of archived
audio and video for particular events in meetings such as when
speakers change.
**Requirement 03-54**: The RPS MUST support recording and storage of
recordings of the audio, video, and slide presentations of interim
meetings as well as regular IETF meetings.
**Requirement 03-55**: Given that interim meetings are run without
the help of the IETF Secretariat, making these recordings MUST be
easy for WG chairs.
4.9. Transcription
**Requirement 03-56**: Transmitting real-time transcription to remote
attendees MUST be supported. The lag in transmission MUST be less
than five seconds.
4.10. Polling
The common IETF method of assessing support is a straw poll,
sometimes managed by audible humming, sometimes by raising hands.
**Requirement 03-57**: A system for polling meeting participants,
including remote attendees at the same time, MUST be provided. It
MUST be easy to set up a simple poll, and it must be easy for all
participants to find the poll and participate. Note that this would
add a requirement that everyone in a meeting be using their computer
to participate in the poll. [[[ TODO: Should the RPS also provide a
tool that allows yes / no / abstain indications, which comes a lot
closer to "voting" than currently is common? ]]]
4.11. Plenaries
At recent IETF meetings, there has been very little input from remote
attendees even when there is a lot in the room, but that may be due
to the current setup, not lack of interest.
**Requirement 03-58**: Remote attendees SHOULD be able to make
comments at the mic approximately as well as if they were local
attendees. This means that either remote audio to the plenary room
speakers be available, or that IM-to-room relay be available.
[[[ TODO: Are there other requirements that are special to plenaries
that are not covered above? Are there requirements not listed above
that mostly come from plenaries that would also apply to very large
WGs? ]]]
4.12. Use by IETF Leadership
The requirements for bodies like the IESG and IAB to use the RPS
during regular IETF meetings are similar to those of most WGs. The
main difference is that they need a way to limit who can participate
remotely.
**Requirement 03-59**: The IETF Secretariat MUST be able to easily
limit remote access to meetings on a room-by-room basis.
**Requirement 03-60**: The IETF Secretariat must be able to limit
participants in restricted meetings using a simple authentication
mechanism.
Note that the IETF leadership will also heavily use the remote
participation tools between IETF meetings in a manner that is very
similar to virtual interim meetings.
4.13. Additional Requirements for Remote Participation
**Requirement 03-61**: Remote attendees MUST be able to easily find
all the material they need to effectively participate, including
links to audio, video, instant messaging, slides, and so on. This
material MUST be available well before the time of the meeting. The
page with the meeting material SHOULD allow the remote attendee to
easily perform a time conversion to and from the local time at the
IETF meeting.
**Requirement 03-62**: A remote attendee who comes to a meeting late
MUST be able to tell what is happening in the meeting. In specific,
there MUST be an indication if the meeting has not started, if the
meeting is happening (even if there is silence on the mics), and if
the meeting is over.
**Requirement 03-63**: There MUST be a constantly-running testing
service that covers all interactive tools (audio, video, slide
display, and so on) for at least a week before the meeting begins.
Remote attendees need to be able to test the remote participation
setup before a regular meeting, and even during the meeting.
**Requirement 03-64**: The testing service MUST run throughout the
meeting so that last-minute joiners can test their systems.
**Requirement 03-65**: The testing service SHOULD allow remote
attendees to also test whether their outgoing audio, video, and slide
control works.
**Requirement 03-66**: Remote attendees SHOULD be able to easily
contact the IETF Secretariat if they find problems with any of the
RPS tools, and to get fairly rapid response.
**Requirement 03-67**: Similarly, local attendees SHOULD be able to
easily contact the IETF Secretariat if there are RPS problems in the
meeting rooms.
**Requirement 03-68**: The RPS tools MUST be available for AD-
sponsored lunch meetings scheduled by the IETF Secretariat. Regular
IETF meetings are more than just a group of WG meetings. Remote
attendees may want to participate in the other parts of a regular
meeting as well.
**Requirement 03-69**: Any tools that are used by remote attendees
MUST also be available to local attendees as well. At many IETF
meetings, some local attendees act as remote attendees in WG meetings
that they are not sitting in, so they can attend two WGs at once.
5. Requirements for Supporting Remote Participation in Interim Meetings
One of the goals of this document is to increase the effectiveness of
interim meetings. Interim meetings are now uncommon, but might
become more common (and more effective) if the remote participation
becomes more useful.
**Functional spec 03-09**: The RPS SHOULD have a central location
where the specifics about how remote participation is supported for
every WG interim meeting. This will reduce the problems often seen
where messages about how to participate in an interim meeting get
buried in the WG mailing list.
**Requirement 03-70**: There SHOULD be documentation and training for
the RPS tools specifically targeted at WG chairs who will lead
interim meetings.
[[[ TODO: Determine how much or how little the IETF Secretariat
should participate in setting up the RPS for interim meetings. The
IETF Secretariat currently offers some help to some WGs, but this
might become more formalized in the future. ]]]
5.1. Requirements for Supporting Remote Participation in Face-to-Face
Interim Meetings
Face-to-face interim meetings have many things in common with regular
IETF meetings, but there are also many significant differences. For
most WGs, fewer people attend interim meetings than IETF meetings,
although those who travel to a face-to-face interim meeting are often
the more active WG participants. There may be a larger demand for
remote participation because people have a harder time justifying
travel for a single WG meeting than for an IETF meeting, but there
may also be less demand because people tend to think of interim WG
meetings as less important than regular IETF meetings..
Typically, the IETF Secretariat does not control the rooms in which
face-to-face interims are held, so they have no control over whether
outgoing audio will be supported, or supported well enough to
guarantee that remote attendees can hear. [[[ TODO: Should the IETF
Secretariat be tasked with helping set up face-to-face interims? ]]]
**Requirement 03-71**: The RPS tools MUST be at least partially
usable at face-to-face meetings other than regular IETF meetings.
The number of the tools that might be available will be different for
different venues for the virtual interims, but at a minimum, the
following MUST be supported for remote attendees:
o Room audio
o Instant messaging
o Slide distribution
o Slide presentation
o Shared document editing
[[[ TODO: What are the requirements for registering? Interim
meetings are generally considered to have a very different feeling
than regular IETF meetings; does this affect the idea of
registration? What if registration is cheap but not free? ]]]
5.2. Requirements for Supporting All-Remote Interim Meetings
The requirements for meetings that are all remote (that is, with no
local attendees) are mostly a subset of the requirements for remote
participation in a regular IETF meetings and face-to-face interim
meeting. This section highlights the differences from Section 4 and
Section 5.1.
Video for all-remote meetings may be more important than for face-to-
face meetings in order to help the chair with floor control. [[[
TODO: Determine if this is true and, if so, the additional
requirements for all the remote attendees. ]]]
Attendance at virtual interim meetings is supposed to be taken, but
this is sometimes ignored. A system that is probably at least
somewhat different than that in Section 4.13 may be needed for
collecting attendance at virtual interim meetings. [[[ TODO: What are
the requirements for registering? Virtual interim meetings are
generally considered to have a very different feeling than regular
IETF meetings; does this affect the idea of registration? ]]]
[[[ TODO: Are there different floor control issues for all-remote
meetings? ]]]
6. IANA Considerations
None. [[ ...and thus this section can be removed before publication
as an RFC... ]]
7. Security Considerations
People who participate remotely in face-to-face IETF meetings might
expect the same level of privacy as they have when they participate
directly in those meetings. Some of the proposed tools might cause
it to be easier to know which WGs a remote attendee was following.
When RPS tools are deployed, the IETF should describe the privacy
implications of using such a tool to the users so they can decide
whether or not to use the tools.
The eventual RPS tools will have some user authentication that will
associate people with actions. For example, a remote user might need
to authenticate to the system in order to give a presentation or
speak during a session. The credentials needed for this
authentication will need to be managed in a secure fashion, both by
the system and by the people who are being identified.
8. Acknowledgements
Many of the ideas in this document were contributed by members of the
IETF community based on their experiences during recent IETF
meetings. There are also many contributions from people on the
vmeet@ietf.org mailing list as well as WG chairs.
Some of the text in this document originated in the request for
proposals that was issued by the IAOC that led to this document.
9. Informative References
[BCP78] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 6121, March 2011.
[RPS-RFP] IAOC, "Request for Proposals for Requirements Development
for Remote Participation Services", 2011, <http://
iaoc.ietf.org/documents/
RPS-Specifications-RFP-2011-10-19.pdf>.
Author's Address Author's Address
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
 End of changes. 50 change blocks. 
980 lines changed or deleted 929 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/