Internet DRAFT - draft-ietf-genarea-rps-reqs
draft-ietf-genarea-rps-reqs
Network Working Group P. Hoffman
Internet-Draft VPN Consortium
Intended status: Informational October 15, 2012
Expires: April 18, 2013
Requirements for Remote Participation Services for the IETF
draft-ietf-genarea-rps-reqs-08
Abstract
The IETF has provided some tools for remote participation in its
activities for many years, and some IETF participants have also used
their own tools when they felt the need arise. The IETF now wishes
to support enhanced remote participation that is as seamless as
possible, improving the experience for the remote attendee at the
IETF regular meetings and interim meetings without degrading the
experience for the people that are physically present. Before
deploying the new tools and services needed for this enhanced remote
participation, the requirements for such tools and services, 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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Hoffman Expires April 18, 2013 [Page 1]
Internet-Draft Remote Participation Reqs October 2012
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hoffman Expires April 18, 2013 [Page 2]
Internet-Draft Remote Participation Reqs October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals for an Improved RPS . . . . . . . . . . . . . . . . 4
1.2. About This Document . . . . . . . . . . . . . . . . . . . 5
2. Requirements for Supporting Remote Participation in
Regular IETF Meetings . . . . . . . . . . . . . . . . . . . . 7
2.1. Registration for Remote Participation . . . . . . . . . . 8
2.2. Instant Messaging . . . . . . . . . . . . . . . . . . . . 9
2.3. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Audio to Remote Attendees . . . . . . . . . . . . . . 10
2.3.2. IM-to-Mic Relay of Comments from Remote Attendees . . 10
2.3.3. Audio for Presentations from Remote Attendees . . . . 11
2.3.4. Audio from Remote Attendees to the Room for
Comments . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1. Video from the Room to Remote Attendees . . . . . . . 13
2.4.2. Video from Remote Attendees to the Room . . . . . . . 13
2.5. Slide Presentations and Distribution . . . . . . . . . . . 14
2.6. Shared Text Document Editing . . . . . . . . . . . . . . . 15
2.7. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 17
2.10. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 17
2.11. Preparation . . . . . . . . . . . . . . . . . . . . . . . 17
2.11.1. Preparation for WG Chairs . . . . . . . . . . . . . . 18
2.11.2. Preparation for Remote Attendees . . . . . . . . . . . 18
3. Requirements for Supporting Remote Participation in
Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 19
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Background on IETF Remote Participation . . . . . . . 21
A.1. How the IETF Meets . . . . . . . . . . . . . . . . . . . . 22
A.2. Technologies Currently Used at Regular IETF Meetings . . . 23
A.3. Locating the Meeting Information . . . . . . . . . . . . . 24
A.3.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 24
A.3.2. Instant Messaging . . . . . . . . . . . . . . . . . . 25
A.3.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 25
A.4. Remote Participation at IETF Meetings . . . . . . . . . . 25
A.4.1. Remotely Speaking at the Mic . . . . . . . . . . . . . 25
A.4.2. Remotely Presenting . . . . . . . . . . . . . . . . . 28
A.4.3. Floor Control . . . . . . . . . . . . . . . . . . . . 29
A.5. Remote Participation at IETF Interim WG Meetings . . . . . 30
A.5.1. Face-to-Face Interim Meetings . . . . . . . . . . . . 30
A.5.2. Virtual Interim Meetings . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
Hoffman Expires April 18, 2013 [Page 3]
Internet-Draft Remote Participation Reqs October 2012
1. Introduction
There are two types of participants at the three-times-a-year IETF
meetings: the people who are physically at the meeting ("local
attendees") and people that are not physically at the meeting but are
following the meeting online ("remote attendees"). For more than a
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
employing various tools.
At the same time, many IETF Working Groups (WGs) have started to have
interim meetings that are scheduled between the regular IETF
meetings; these are briefly described in [RFC2418]. Some of these
interim meetings are face-to-face meetings with remote attendees,
while other interim meetings only take place over the Internet or on
the phone; the latter type of meeting is often called a "virtual
interim". There are also interim meetings that do not support remote
participation.
The IETF's current remote participation system ("RPS") for the
official three-times-a-year meetings ("regular IETF meetings")
consists of a real-time audio stream carried to remote attendees over
HTTP, textual instant messaging (IM) carried over Jabber, and slides
distributed on the IETF web site. Two tools that are experimentally
supported, WebEx and Meetecho, are used to sync the audio and slides
during the meeting, and also replay them in the proceedings. Some
WGs also employ ad-hoc tools such as Skype. For interim WG 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
reasons.
o A better RPS would allow current remote IETF attendees to
participate in regular IETF meetings more effectively, and would
also allow more people to become remote IETF attendees. This in
turn would hopefully lead to better WG outcomes. There are many
people who are active in many WGs who rarely or never come to IETF
meetings; good RPS tools could allow some of these people to
contribute better during meetings.
Hoffman Expires April 18, 2013 [Page 4]
Internet-Draft Remote Participation Reqs October 2012
o The improved RPS tools would also be used outside IETF meetings.
They would be available to WGs for interim meetings, both to allow
remote participation in face-to-face interims as well as to
facilitate virtual interims where none of the attendees are in the
same location.
o The plenary sessions of IETF meetings currently only allow remote
attendees to hear the speakers and read a real-time transcript.
Improved RPS tools would allow remote attendees to see the
speakers, to see the slides synchronized with the audio, and be
able to comment at the mics like people in the room.
o The IETF leadership (the IAB, IESG, IAOC, and probably others)
could use the new tools to help make their own meetings more
effective.
o There is a desire to better capture the contributions to the IETF
(as defined in [BCP78]) of remote attendees in the official record
of regular IETF and interim meetings.
The are many IETF-related activities that can be aided by remote
participation tools. The scenarios in which the RPS described in
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.
1.2. About This Document
The purpose of this document is to develop the requirements 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 to
improve as much as possible of the experience of remote attendees in
meetings while not having a significant negative effect on the
experiences of local attendees and WG chairs.
This document specifies a set of requirements based on the community
desires at the time that this document is written. It is expected
that the desires of the community will shift after the RPS described
here is deployed and as remote participation tools evolve. The
requirements here are for the RPS to be deployed in the near term;
later, as the requirements change, additions and changes will
certainly be made to the RPS. This document is definitely not meant
to limit experimentation with participation ideas after deployment of
the RPS described here.
This document differentiates between requirements that have higher
Hoffman Expires April 18, 2013 [Page 5]
Internet-Draft Remote Participation Reqs October 2012
and lower priorities. Higher-priority requirements are intended to
be delivered as soon as possible, but lower-priority requirements
might be delivered later. For example, a high-priority requirement
might be "remote attendees must be able to know which slide is being
discussed" and a related, lower-priority requirement might be "remote
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
functionality may not be desired by all WG chairs. Different WG
chairs prefer to use different tools, and that will be true when the
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
request for proposals that led to this document can be found at
[RPS-RFP]. This document does not specify specific technologies or
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
tools described here. It is expected that the IAOC will consider
changes and additions to the RPS periodically after the RPS described
here is deployed.
Requirements in this document are numbered, such as "**Requirement
08-00**".
The requirements covered in this document apply almost exclusively to
tools and services that are used for remote participation in real-
time meetings. The document does not cover the many other tools used
by WGs for non-real-time communication such as mailing lists, issue
trackers, document flow control systems, and so on. Many of the non-
real-time tools are also being improved over time, but they are not
the subject of this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document is being discussed on the vmeet@ietf.org mailing list.
See <https://www.ietf.org/mailman/listinfo/vmeet> for more
Hoffman Expires April 18, 2013 [Page 6]
Internet-Draft Remote Participation Reqs October 2012
information.
2. Requirements for Supporting Remote Participation in Regular IETF
Meetings
This section covers the requirements for effective remote
participation in meetings where most members are in regular IETF
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 08-01**: The specifications in the RPS SHOULD rely upon
IETF and other open standards for all communications and interactions
wherever possible. The RPS might not rely on IETF or other open
standards if there is an identified gap that cannot be met by those
standards.
**Requirement 08-02**: All tools in the RPS MUST be able to use both
IPv4 and IPv6 addresses natively.
**Requirement 08-03**: 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 08-04**: 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. The system MUST
minimize internal latency, should avoid unnecessary architectural
latency, and be designed with a goal of having less than 200
milliseconds of delay to registered 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 08-05**: The outgoing audio, video, and slide streams
MUST by synchronized so the remote attendee does not get confused
during slide presentations.
**Requirement 08-06**: Many attendees will be in places with limited
bandwidth. Remote attendees on 56Kbps Internet connections SHOULD be
Hoffman Expires April 18, 2013 [Page 7]
Internet-Draft Remote Participation Reqs October 2012
able to receive useable versions of streaming information. The
system SHOULD take advantage of higher bandwidth audio and video
encodings for participants on higher bandwidth connections. The
system MUST NOT architecturally prevent other users from selecting
higher bandwidth encodings.
**Requirement 08-07**: 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 08-08**: 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.
**Requirement 08-09**: The deployment of the tools here MUST take
into account making the tools accessible to as many IETF attendees as
possible. Such deployment is likely to include technical
accommodations for those with visual and hearing disabilities.
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 08-10**: 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 08-11**: Remote attendees who will only be listening
and/or watching, but not making contributions, MUST NOT be required
to register.
**Requirement 08-12**: The RPS MUST be able to tell which
participants are registered and which are not. This is to allow
different levels of service to registered users.
**Requirement 08-13**: Registration for remote attendees SHOULD be no
more onerous than joining a WG mailing list. Basically, the
Hoffman Expires April 18, 2013 [Page 8]
Internet-Draft Remote Participation Reqs October 2012
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 08-14**: The RPS tools (particularly the registration
tool) MUST gracefully handle multiple attendees who have the same
name.
Note that some unregistered remote attendees might expect to be able
to participate but be prevented from doing so by the RPS. The IETF
page for each meeting (particularly the agenda pages) can make this
clearer to help remote attendees plan better for participation.
Registration might happen in the IETF's Datatracker. This would
allow the RPS to reuse the Datatracker's identifiers, passwords,
identifications (such as who is and is not a WG chair), and so on.
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 08-15**: The IM system MUST allow anyone to see all
messages in the WG's or BoF's room.
**Requirement 08-16**: The IM system MUST allow any registered user
to post messages in the WG's or BoF's room.
**Requirement 08-17**: 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.
Hoffman Expires April 18, 2013 [Page 9]
Internet-Draft Remote Participation Reqs October 2012
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 08-18**: Remote attendees MUST be able to hear what is
said by local attendees and chairs at any mic in the meeting.
**Requirement 08-19**: 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 08-20**: The RPS MUST enable relay of messages from IM
to the mic to be able to happen as quickly as if the remote attendee
was local.
**Requirement 08-21**: 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 08-22**: 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
Hoffman Expires April 18, 2013 [Page 10]
Internet-Draft Remote Participation Reqs October 2012
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 08-23**: A remote attendee giving a presentation MUST
be able to have their speaking be heard by all local and remote
attendees.
**Requirement 08-24**: A WG chair MUST be able to control the sound
coming from any particular remote attendee. This control MUST allow
reduction in volume, all the way to complete muting, of the remote
speaker.
**Requirement 08-25**: 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 08-26**: The audio system used by the RPS MUST be able
to integrate with systems commonly used in the venues used for IETF
meetings. These venue systems typically include line-level audio
outputs from mixers that combine all the mic inputs into a single
stream. Some venue systems also allow for headphone level inputs
from PCs to be mixed into the audio stream.
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.
Further note that, as per above, audio from remote attendees is a
secondary priority. That means that the "MUST" requirements in this
section are for when the priority is being met, not for when the RPS
is initially rolled out.
**Requirement 08-27**: 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
Hoffman Expires April 18, 2013 [Page 11]
Internet-Draft Remote Participation Reqs October 2012
ability to speak is controlled by the chair; see Section 2.3.4.1.)
**Requirement 08-28**: Local attendees MUST be able to determine
which remote attendee is speaking.
**Requirement 08-29**: 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 08-30**: 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 08-31**: 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 08-32**: The RPS MUST allow a remote attendee's request
for attention to include an optional short (20 characters or less)
arbitrary 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.
It is not acceptable to simply rely on humans reading instant
messages to allow remote participants to make the request for
attention.
**Requirement 08-33**: 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 08-34**: 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.
Hoffman Expires April 18, 2013 [Page 12]
Internet-Draft Remote Participation Reqs October 2012
**Requirement 08-35**: The floor control system MUST allow a chair to
easily mute all remote attendees.
**Requirement 08-36**: The floor control system MUST allow a chair to
easily allow all remote attendees to speak without requesting
permission; that is, the chair SHOULD be able to easily turn on all
remote attendees mics at once.
**Requirement 08-37**: 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 08-38**: The RPS MUST authenticate users who can use
the floor control system in a particular meeting using simple
passwords; other forms of authentication may be used as well.
**Requirement 08-39**: 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.
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 08-40**: Remote attendees MUST be able to see the
presenter at a meeting.
**Requirement 08-41**: A lower-priority requirement than Requirement
08-40 is that remote attendees SHOULD be able to see who is speaking
at the mics in the room.
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
Hoffman Expires April 18, 2013 [Page 13]
Internet-Draft Remote Participation Reqs October 2012
remote attendees to the room for comments (Section 2.3.4).
**Requirement 08-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 08-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 08-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 08-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 08-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
This section discusses slide presentations, which are the primary
form of presentations made in WG meetings. It should be noted that
are occasionally other types of presentations, such as videos; these
are not dealt with in the tools proposed below.
In this section, "distribute" means slides that are downloaded from
the IETF site, while "transmit" means the slide stream seen in near-
real-time as the presenter is speaking.
**Requirement 08-47**: The RPS MUST be able to handle both PDF and
PowerPoint formats (".ppt" and ".pptx") for distributed slides.
**Requirement 08-48**: The RPS MUST automatically convert PowerPoint
presentations to PDF and make both available for distribution at the
same time.
**Requirement 08-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 08-50**: Chairs MUST be able to approve or disapprove
of any slide submission or updates, with the default being that all
submissions are allowed.
Hoffman Expires April 18, 2013 [Page 14]
Internet-Draft Remote Participation Reqs October 2012
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 08-51**: The RPS MUST transmit the slide stream
separately from the camera stream.
**Requirement 08-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 08-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 08-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 08-55**: It MUST be easy to start a new text shared
document and to import existing text into a shared document.
Hoffman Expires April 18, 2013 [Page 15]
Internet-Draft Remote Participation Reqs October 2012
**Requirement 08-56**: Remote attendees MUST be able to be either the
writers or the readers of shared documents.
**Requirement 08-57**: The edits MUST be reasonably synchronized with
the sound and video so that those with read access can see the edits
made by those with write access as they are listing to the meeting.
**Requirement 08-58**: It MUST be easy to change the permissions for
who gets write access to a document during an editing session.
**Requirement 08-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 08-60**: The RPS MUST support storage and distribution
of recordings of the audio, video, and slide presentations for all WG
meetings.
**Requirement 08-61**: Transcripts of the instant messaging for all
meetings MUST be kept for distribution after IETF meetings.
**Requirement 08-62**: The recordings and transcripts SHOULD be made
available during the meetings, within a day of them being made.
**Requirement 08-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 08-64**: The RPS SHOULD support indexing of archived
audio and video for particular events in meetings such as when
speakers change. This is a frequently-requested feature, although
there is not yet widespread agreement on standards to do so.
**Requirement 08-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 08-66**: Given that interim meetings are often run
without the help of the IETF Secretariat, making these recordings
MUST be easy for WG chairs.
Hoffman Expires April 18, 2013 [Page 16]
Internet-Draft Remote Participation Reqs October 2012
2.8. Polling
The common IETF method of assessing support is a straw poll,
sometimes managed by audible humming, sometimes by raising hands.
**Requirement 08-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 08-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 08-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 08-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 08-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.
Hoffman Expires April 18, 2013 [Page 17]
Internet-Draft Remote Participation Reqs October 2012
2.11.1. Preparation for WG Chairs
**Requirement 08-72**: Sessions MUST NOT be associated with physical
rooms until just before session starts. This allows a previous
session to run over its time into the break period without
inconveniencing remote users or the archives.
**Requirement 08-73**: The RPS MUST allow a session to be moved from
one room to another during the session This is needed because the
Secretariat sometimes need to swap the rooms for WGs when it becomes
clear that one is too full and another room has excess space.
**Requirement 08-74**: 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). Session testing is
done before session is associated with a physical room.
**Requirement 08-75**: 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 08-76**: There SHOULD be training materials for WG
chairs in how to use the RPS tools.
**Requirement 08-77**: 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 08-78**: 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 08-79**: 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.
This would be similar to the "call here to ensure your voice and
video are set up correctly" test available for other services.
Remote attendees need to be able to test the remote participation
Hoffman Expires April 18, 2013 [Page 18]
Internet-Draft Remote Participation Reqs October 2012
setup before a regular meeting, and even during the meeting.
**Requirement 08-80**: The testing service MUST run throughout the
meeting so that last-minute joiners can test their systems.
**Requirement 08-81**: The testing service SHOULD allow remote
attendees to also test whether their outgoing audio, video, and slide
control works.
**Requirement 08-82**: 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 08-83**: 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 08-84**: There SHOULD be documentation and training for
the RPS tools specifically targeted at WG chairs who will lead
interim meetings.
**Requirement 08-85**: 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
Hoffman Expires April 18, 2013 [Page 19]
Internet-Draft Remote Participation Reqs October 2012
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
Hoffman Expires April 18, 2013 [Page 20]
Internet-Draft Remote Participation Reqs October 2012
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
Hoffman Expires April 18, 2013 [Page 21]
Internet-Draft Remote Participation Reqs October 2012
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
meeting has about 150 sessions lasting one to two and one half
hours each, with up to 8 of those sessions happening at the same
time. A session might have between 20 and 200 local attendees in
the room, and might have only a few or many dozens of remote
attendees. WG sessions typically have one to three co-chairs at
the front of the room and a series of individuals who come to the
front to present; some presentations are made by small panels.
o Plenaries at regular IETF meetings -- There are usually two
plenaries at a regular IETF meeting, with on-site attendance of
about 700 local attendees and dozens of remote attendees. There
are from 1 to 20 presenters; presentations may be made by multiple
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,
some WGs hold interim meetings where attendees get together at a
site (often a company's meeting room, but sometimes a meeting room
rented at a hotel). At such meetings, there are between a handful
and a few dozen local attendees and a similar number of remote
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
WGs hold virtual interim meetings where there are no local
attendees because there is no central meeting location. There are
between a handful and a few dozen attendees. Presentations are
common. There are typically fewer than 25 face-to-fact interim
meetings a year.
Hoffman Expires April 18, 2013 [Page 22]
Internet-Draft Remote Participation Reqs October 2012
o IETF leadership meetings -- The IETF leadership (the IESG, IAOC,
IAB, and probably others) have periodic virtual meetings, usually
with presentations. These groups also meet at the regular IETF
meetings, and sometimes have remote attendees at those meetings
(such as members who cannot attend the IETF meeting or presenters
who are not part of the leadership group).
The form of "presentations" changes from meeting to meeting, but
almost always includes prepared static slides and audio of the
speaker. Presentations sometimes also includes non-static slides
(usually animations within a slide) and sometimes video.
A.2. Technologies Currently Used at Regular IETF Meetings
There are three tools that are used by remote attendees for WG
participation at regular IETF meetings: real-time audio, instant
messaging, and slides.
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
origination in the IETF meeting venue and the users' computer. At
recent meetings, delays of around 30 seconds have been recorded, with
minimum delays typically being five seconds. This delay is caused by
buffering at the hop-by-hop ISPs and in the remote attendee's
computer. At recent IETF meetings, remote attendance is almost
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
U.S.) Each stream is represented by an MP3 playlist (sometimes called
an "m3u file").
The IETF long ago standardized on Jabber / XMPP ([RFC6120],
[RFC6121], and others) for instant messaging used within the IETF.
Jabber rooms (formally called "multi-user conferences" or "MUCs")
exist for every WG, and those rooms are live all the time, not just
during regular IETF meetings. BoFs have jabber rooms that are
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.
Presentation slides normally are stored either as PDFs or in one of
Microsoft's formats for PowerPoint. They are projected on a local
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
and Meetecho, which are supported experimentally by the IETF. Each
tool was used by a handful of WGs with mixed success. The tools
require remote attendees to use specific clients, and installation of
Hoffman Expires April 18, 2013 [Page 23]
Internet-Draft Remote Participation Reqs October 2012
those clients caused problems for some people. On the other hand,
the tools have much more robust meeting control features, and
attendees appreciated the real-time showing of slides during
presentations.
A.3. Locating the Meeting Information
Finding information for the real-time audio, instant messaging, and
slides for an upcoming or current regular meeting is complicated by
that information being in many different locations on the IETF web
site, and the fact that the relevant URLs can change before and even
during the meeting. Further, a WG chair might copy the latest
information and send it to the WG mailing list, but there can be
later changes. Experienced remote attendees have gotten used to
checking just before the meeting itself, but even that does not
always guarantee the correct information.
Currently, the meeting information appears in two different agendas:
o The official agenda on the IETF Datatracker includes links to
venue maps, WG charters, agendas, and Internet-Drafts. For
example, see
<https://datatracker.ietf.org/meeting/82/agenda.html>.
o The unofficial "tools-style agenda" includes the same links as the
official agenda plus links to the presentations, audio, minutes,
Jabber room, and Jabber logs 9represnted as small icons). For
example, see <http://tools.ietf.org/agenda/82/>.
A.3.1. Audio
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
general IETF mailing list (ietf@ietf.org) before each meeting.
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
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
announced, there is no easy way for a remote attendee to find out
which audio stream they should be listening to. Sometimes, room
changes happen just as a WG meeting is starting, making it nearly
impossible for a remote attendee to know about the change in streams.
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
Hoffman Expires April 18, 2013 [Page 24]
Internet-Draft Remote Participation Reqs October 2012
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
meetings, so finding the right Jabber room is relatively easy. Some
Jabber clients have odd interfaces for joining Jabber rooms, and this
can cause some problems; even though attendees can test their Jabber
clients before a meeting, there still seems to be some who need help
just before a WG meeting. There are sometimes problems with people
joining Jabber rooms; in these cases, the attendee needs to find
someone already in the Jabber room to invite them to the discussion.
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
certainly not all, local and remote attendees know how to find the
meeting materials page.
It has become fairly common for presenters to not have their
presentations available for distribution until just before the WG
meeting. Because materials are uploaded by the WG chairs, this often
causes the beginning of WG meetings to be a dance involving
presenters giving the chairs their slides, followed by chairs
uploading the slides to the IETF site, followed by the chairs saying
"the slides are there now".
A.4. Remote Participation at IETF Meetings
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
Hoffman Expires April 18, 2013 [Page 25]
Internet-Draft Remote Participation Reqs October 2012
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
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
some local attendee going to the mic and repeating what was typed
into the Jabber room. Remote attendees often precede what they want
said at the mic with the string "mic:" to differentiate that from the
rest of the discussion in the Jabber room.
In some WGs, there have been experiments of getting remote attendees
voices into the room either by hooking into the room's sound system
or pointing a mic at the speaker of a laptop. This sometimes works,
but sometimes has bad feedback and delay issues that make the remote
participation worse than having a person reading their comments at
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).
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
and Pete doesn't want to go back.
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
the mic.
o Robert wants to say something, but Sam is already at the mic
speaking for Rachel so Sam doesn't see Robert's message until he
has gotten out of the mic line.
o Sam is speaking for Robert, and Rachel wants to comment on what
Robert said. Unless Sam reads the message as he is walking back
to his seat, Rachel doesn't get to speak.
Hoffman Expires April 18, 2013 [Page 26]
Internet-Draft Remote Participation Reqs October 2012
o Robert wants to say something at the mic, but Sam is having an
important side discussion with the AD.
o Sam is also the minutes taker, and is too busy at the moment
catching up with the lively debate at the mic to relay a question
from Rachel.
o Chris thought Carl was watching the Jabber room, but Carl was
reading the draft that is being discussed.
o Chris and Carl start the meeting by asking for volunteers to take
minutes and be Jabber scribe. They couldn't find a Jabber scribe,
and it took a lot of begging to get someone to take minutes, so
they figured that was the best they could do.
o Sam is also a presenter, and Robert has a question about Sam's
presentation, but Sam is obviously not looking at the Jabber room
at the time.
o Rachel asks a question through Sam, and Pete replies. Len, who is
next in line at the mic, starts talking before Sam has a chance to
see whether or not Rachel has a follow-up question.
o Robert makes a point about one of Pete's slides, and Pete responds
"I don't think you're looking at the right slide" and continues
with his presentation. Robert cannot reply in a timely fashion
due to the lag in the audio channel.
o Pete starts his presentation by asking for questions to be held
until the end. Robert has a question about slide 5, and is
waiting until the end of the presentation to post the question in
the Jabber room. After slide 7, Len jumps to the mic and
vehemently disagrees with something that Pete said. Then Lee gets
up to respond to Len, and the three of them go at it for a while,
with Lee getting up again after slide 10. The presentation ends
and is over time, so Carl says "we need to move on", so Robert
never gets to ask his question.
o Chris asks "are there any more questions" while Rachel is typing
furiously, but she doesn't finish before Chris says "I don't see
anyone, thanks Pete, the next speaker is...".
o Rachel comments on Pete's presentation though Sam. Sam doesn't
understand what Rachel is asking, and Len goes to the mic to
explain. However, Len gets his explanation of what Rachel said
wrong and by the time Pete answers Len's interpretation, Rachel
gives up.
Hoffman Expires April 18, 2013 [Page 27]
Internet-Draft Remote Participation Reqs October 2012
o This is the first time Pete is presenting at an IETF meeting, and
Robert has the first question, which is relayed through Sam. Pete
stays silent, not responding the question. Robert can't see
Pete's face to know if Pete is just not understanding what he
asked, is too afraid to answer, is just angry, or something else.
o Pete says something incorrect in his presentation, and Len asks
the folks in the Jabber room about it. Rachel figures out what
Pete should have said, and others in the Jabber room agree. No
one goes to the mic because Pete has left the topic, but only the
people watching Jabber know that the presentation was wrong.
o Pete says something that the AD sitting at the front of the room
(not near a mic) doesn't like, and the AD says a few sentences but
doesn't go to the mic. The chairs try to repeat what the AD says,
get it only approximately right, but the remote attendees do not
hear what really was said and therefore cannot comment
effectively.
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 down all the time, and doesn't really agree with Robert on a
particular issue, so Sam doesn't relay a request from Robert.
o Rachel cannot join the Jabber room due to a client or server
software issue. She finally finds someone else on Jabber who is
also in the meeting, and gets them to invite her into the room.
A.4.2. Remotely Presenting
Some WGs have experimented with remote presentations at regular IETF
meetings, with quite mixed results. For some, it works fine: the
remote presenter speaks, the chair moves the slides forward, and
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
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.
At a recent meeting that had a remote presenter, a WG had a video
camera set up at the chairs' desk pointed towards the audience so
that the presenter could see who was at the mic; this was considered
to be a great help and a lot friendlier because the presenter could
address the people at the mic by name. They also had the presenter's
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
to pay more attention.
Remote presenters have commented how difficult it is to set up their
Hoffman Expires April 18, 2013 [Page 28]
Internet-Draft Remote Participation Reqs October 2012
systems, particularly because they are not sure whether their setup
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
this really working?".
A.4.3. Floor Control
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
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
happening on Jabber, even if they are watching the Jabber room.
Without as much view, they cannot assist the flow of the conversation
as well.
o Carl sees that the Jabber room has an active and useful back-
channel discussion during Pete's provocative presentation. Pete
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
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
does.
o Rachel asks a question, but Sam is not going to the mic to relay
it. In fact, Sam has pretty much stopped paying attention. Chris
cannot do something about the situation without making Sam look
bad.
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
cannot tell whether to wait for Robert to rephrase the question or
whether Robert even heard Pete's response.
o In a virtual interim where remote attendees all participate by
voice, someone can be heard typing / eating / talking loudly to
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
does not have the ability to mute individual attendees, so the
meeting is disrupted until that person finally realizes that he or
she is not muted.
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.
Hoffman Expires April 18, 2013 [Page 29]
Internet-Draft Remote Participation Reqs October 2012
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
supplied by companies active in the IETF (and, much less often, in
commercial conference facilities such as hotels). Because these
facilities are not administered by the IETF Secretariat, the ability
to include remote attendees varies widely. Some facilities can
distribute the in-room audio over the Internet just fine, while
others have no or limited abilities to do so.
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
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
probably have an experience similar to regular IETF meetings.
A.5.2. Virtual Interim Meetings
Because few WGs have virtual interim meetings (those with no face-to-
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
years, and some WGs have used different tools for audio
participation. For example, some virtual interims are held using
Skype, others with TeamSpeak, and so on.
So far, the experience with virtual interim meetings has been
reasonably good, and some people say that it is better than for
remote attendees at regular IETF meetings and face-to-face interims
because everyone has the same problems with getting the group's
attention. Also, there are no problems getting the in-room audio
into the RPS because all attendees are using their own computers for
Hoffman Expires April 18, 2013 [Page 30]
Internet-Draft Remote Participation Reqs October 2012
speaking to the group.
One of the often-debated aspects of virtual interim meetings is what
time to have them in order to make them available to all attendees.
Such scheduling of virtual interim meetings is out of scope for this
document. However, it is noted that because many attendees will be
attending at different times of day and night, no assumption can be
made that attendees will be at an "office". This debate also affects
face-to-face interim meetings because the meeting hosts normally will
schedule the meeting during business hours at the host company, but
that might be terribly inconvenient for some WG members.
Author's Address
Paul Hoffman
VPN Consortium
Email: paul.hoffman@vpnc.org
Hoffman Expires April 18, 2013 [Page 31]
