draft-ietf-genarea-rps-reqs-00.txt   draft-ietf-genarea-rps-reqs-01.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational January 5, 2012 Intended status: Informational January 18, 2012
Expires: July 8, 2012 Expires: July 21, 2012
Requirements for Remote Participation Services for the IETF Requirements for Remote Participation Services for the IETF
draft-ietf-genarea-rps-reqs-00 draft-ietf-genarea-rps-reqs-01
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, approaching the quality of direct physical attendance for
the various roles, including chair, presenter and simple attendee. the various roles, including chair, presenter and simple attendee.
Before deploying the new tools and services needed for this enhanced Before deploying the new tools and services needed for this enhanced
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 July 8, 2012. This Internet-Draft will expire on July 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. About This Document . . . . . . . . . . . . . . . . . . . 4 1.1. About This Document . . . . . . . . . . . . . . . . . . . 4
2. Scenarios Required to be Supported . . . . . . . . . . . . . . 5 2. Scenarios Required to be Supported . . . . . . . . . . . . . . 6
3. Interactions with Current RPS Tools Used by the IETF . . . . . 6 3. Interactions with Current RPS Tools Used by the IETF . . . . . 7
3.1. Technologies Currently Used at Regular IETF Meetings . . . 6 3.1. Technologies Currently Used at Regular IETF Meetings . . . 7
3.2. Locating the Meeting Information . . . . . . . . . . . . . 7 3.2. Locating the Meeting Information . . . . . . . . . . . . . 8
3.2.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Instant Messaging . . . . . . . . . . . . . . . . . . 8 3.2.2. Instant Messaging . . . . . . . . . . . . . . . . . . 9
3.2.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Remotely Speaking at the Mic . . . . . . . . . . . . . . . 8 3.3. Remotely Speaking at the Mic . . . . . . . . . . . . . . . 9
3.4. Chairs and Floor Control for Remote Attendees . . . . . . 10 3.4. Chairs and Floor Control for Remote Attendees . . . . . . 11
3.5. Remotely Presenting at Regular IETF Meetings . . . . . . . 11 3.5. Remotely Presenting at Regular IETF Meetings . . . . . . . 12
3.6. Experiences with Remote Participation in Virtual 3.6. Experiences with Remote Participation in Virtual
Interim Meetings . . . . . . . . . . . . . . . . . . . . . 12 Interim Meetings . . . . . . . . . . . . . . . . . . . . . 13
4. Requirements for Supporting Remote Participation in 4. Requirements for Supporting Remote Participation in
Face-to-Face Meetings . . . . . . . . . . . . . . . . . . . . 12 Face-to-Face Meetings . . . . . . . . . . . . . . . . . . . . 13
4.1. Technologies . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Registration for Remote Participation . . . . . . . . . . 14
4.1.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Technologies . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. Video . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. Instant Messaging . . . . . . . . . . . . . . . . . . 14 4.2.2. Video . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.4. Slide Presentations . . . . . . . . . . . . . . . . . 15 4.2.3. Instant Messaging . . . . . . . . . . . . . . . . . . 16
4.1.5. Shared Document Editing . . . . . . . . . . . . . . . 16 4.2.4. Slide Presentations . . . . . . . . . . . . . . . . . 17
4.2. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.5. Slide Distribution . . . . . . . . . . . . . . . . . . 18
4.2.1. Requirements for Remote Participation . . . . . . . . 16 4.2.6. Shared Document Editing . . . . . . . . . . . . . . . 18
4.2.2. Floor Control for Chairs . . . . . . . . . . . . . . . 17 4.3. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.3. Transcription . . . . . . . . . . . . . . . . . . . . 19 4.3.1. Requirements for Remote Participation . . . . . . . . 19
4.2.4. Polling . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.2. Floor Control for Chairs . . . . . . . . . . . . . . . 20
4.3. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 19 4.3.3. Archiving . . . . . . . . . . . . . . . . . . . . . . 21
4.4. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.4. Transcription . . . . . . . . . . . . . . . . . . . . 22
5. Requirements for Supporting All-Remote Meetings . . . . . . . 19 4.3.5. Polling . . . . . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 4.4. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 4.5. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 5. Requirements for Supporting All-Remote Meetings . . . . . . . 23
9. Informative References . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
9. Informative References . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
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: those who are at the meeting in person ("local attendees") meetings: the people who are physically at the meeting ("local
and those who are not at the meeting in person but participate by attendees") and people that are not physically at the meeting but are
following the meeting online ("remote attendees"). In the past 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 a meaningful fashion by participate in its face-to-face meetings in a meaningful fashion by
providing supported and experimental online services. providing supported and experimental online services.
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 described (briefly) 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". interim".
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 over HTTP, textual
instant messaging (IM) carried over Jabber, and ad-hoc tools that instant messaging (IM) carried over Jabber, as well as experimental
some WGs employ. For interim WG meetings, the IETF also provides support for two integrated tools, WebEx and Meetecho. Some WGs
access to Cisco's WebEx RPS. The IETF's leadership regularly uses employ ad-hoc tools such as Skype. For interim WG meetings, the IETF
telephone and Jabber and WebEx for the many meetings that happen provides access to WebEx. The IETF's leadership regularly uses
telephone, Jabber, and WebEx for the many meetings that happen
between the IETF meetings. between the IETF meetings.
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 more people to participate in regular
IETF meetings more effectively, hopefully leading to better WG IETF meetings more effectively, hopefully leading to better WG
outcomes such as faster progression of WG documents, more outcomes such as faster progression of WG documents, more
reviewers of WG documents, and more discussion of changes needed reviewers of WG documents, and more discussion of changes needed
to those documents during the WG process. There are many people to those documents during the WG process. There are many people
skipping to change at page 4, line 20 skipping to change at page 4, line 22
1.1. About This Document 1.1. About This Document
The purpose of this document is to develop the requirements and The purpose of this document is to develop the requirements and
functional specifications for the IETF's RPS that enables enhanced functional specifications for the IETF's RPS that enables enhanced
remote participation in meeting sessions. The RPS described in this remote participation in meeting sessions. The RPS described in this
document might augment and/or replace the current set of IETF RPS document might augment and/or replace the current set of IETF RPS
tools. The intention is for the experience of remote attendees to tools. The intention is for the experience of remote attendees to
rival those of local attendees. rival those of local attendees.
After the tools that meet the requirements in this document are
deployed, there will probably be a change in the participation in
regular IETF meetings.
o Some people who would make an effort to come to a particular IETF
meeting might be more likely to attend remotely. Such a change
will reduce the number of local participants, 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
meetings are more likely to participate in the meetings remotely.
Such a change might cause more effective meetings for WGs that
currently have little energy because more people will participate.
WG meetings that already have lots of participants will probably
become busier. Presentations on documents where none of the
authors come to regular IETF meetings will be much more likely to
be given by the authors instead of by their proxies.
o If the tools make regular IETF meetings and interim meetings much
more effective, the IETF might be able to reduce the number of
regular meetings each year from three to two. This would
significantly reduce the impact of travel on regular IETF
participants and make meeting planning much easier, but would
significantly reduce the amount of income for the IETF and also
reduce the amount of side-meeting value per year for participants.
Note that some of the requirements in this document for particular
functionality may not be desired by all WG chairs. The tools
proposed will not force a particular WG to use all the features
proposed.
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
00-00**". In the IETF, there is an active (and never-ending) debate 01-00**". In the IETF, there is an active (and never-ending) debate
about what is a "requirement". In the context of this document, a about what is a "requirement". In the context of this document, a
requirement is something that must appear in one of the iterations of requirement is something that must appear in one of the iterations of
the eventual RPS in order to support the mission of enabling useful the eventual RPS in order to support the mission of enabling useful
remote participation in meeting sessions. remote participation in meeting sessions.
Later versions of this document will differentiate between 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 the first version of the RPS and
requirements that must be met by future versions of the RPS. For requirements that must be met by future versions of the RPS. For
example, a requirement for the first version of the RPS might be example, a requirement for the first version of the RPS might be
"chairs must be able to specify which remote attendee can speak "chairs must be able to specify which remote attendee can speak
next", whereas a requirement for a later version of the RPS might be 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 "chairs must be able to perform many or all chair duties at a regular
IETF meeting while participating remotely". [[[ TODO: come up with a IETF meeting while participating remotely". [[[ TODO: come up with a
way to differentiate these two and start marking them as such. ]]] way to differentiate these two and start marking them as such. ]]]
A functional specification is an approach to meeting one or more A functional specification is an approach to meeting one or more
requirement. For example, a requirement might be "chairs must be requirement. For example, a requirement might be "chairs must be
able to specify which remote attendee can speak next" and a functions able to specify which remote attendee can speak next" and a
specification associated with that requirement might be "floor function's specification associated with that requirement might be
control can be done through a stand-alone application or web form". "floor control can be done through a stand-alone application or web
Functional specifications are not (currently) called out in this form". Functional specifications are not (currently) called out in
document. this document.
The requirements covered in this document apply almost exclusively to The requirements covered in this document apply almost exclusively to
tools and services that are used for remote participation in real- tools and services that are used for remote participation in real-
time meetings. The document does not cover the many other tools used time meetings. The document does not cover the many other tools used
by WGs for non-real-time communication such as mailing lists, issue by WGs for non-real-time communication such as mailing lists, issue
trackers, document flow control systems, and so on. Many of the non- 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 real-time tools are also being improved over time, but they are not
the subject of this document. 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. 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. Scenarios Required to be Supported
The are many IETF-related activities that can be aided by remote The are many IETF-related activities that can be aided by remote
participation tools. The scenarios in which the RPS described in participation tools. The scenarios in which the RPS described in
this document is expected to be used are: this document is expected to be used are:
skipping to change at page 6, line 15 skipping to change at page 7, line 5
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 [[[ TODO: Count the number of f2f and virtual interims from the past
few years. ]]] few years. ]]]
[[[ TODO: Bar BoFs at regular IETF meetings are not listed above
because they mostly happen in places where remote participation can't
be scheduled. However, some of them do in fact happen in regular
meeting rooms that might be able to use the RPS tools. Should they
be included in this document? ]]]
3. Interactions with Current RPS Tools Used by the IETF 3. Interactions with Current RPS Tools Used by the IETF
Users' experience with the current IETF tools vary widely. Some Users' experience with the current IETF tools vary widely. Some
participants think the tools are fine and are grateful that they participants think the tools are fine and are grateful that they
exist. Other participants find them barely acceptable because they exist. Other participants find them barely acceptable because they
have used better tools in other environments. Often, local attendees have used better tools in other environments. Often, local attendees
mostly forget that the remote attendees are participating until one mostly forget that the remote attendees are participating until one
gets something said at the mic. Local attendees don't have a feeling 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 for how many remote attendees are just listening like most of the
local attendees. local attendees.
skipping to change at page 7, line 25 skipping to change at page 8, line 9
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. There are also stable Jabber rooms for
the plenaries and certain other activities. BoFs are usually 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.
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
those clients caused problems for some people. On the other hand,
the tools have much more robust meeting control features, and
participants appreciated the real-time showing of slides during
presentations.
3.2. Locating the Meeting Information 3.2. 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
alway. 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/>.
3.2.1. Audio 3.2.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 URLs are listed on "tools-style room that the meeting is in. The audio streams are announced on the
agenda" provided by the IETF Tools Team; for example, see the general IETF mailing list (ietf@ietf.org) before each meeting.
speaker-like icons at <http://tools.ietf.org/agenda/82/>. The audio
streams are also 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 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.
skipping to change at page 8, line 33 skipping to change at page 9, line 34
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. Remotely Speaking at the Mic 3.3. Remotely Speaking at the Mic
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 done by the must say it for them. In most WG and BoF meetings, this is done by
remote attendee typing into the Jabber room for the meeting, and some the remote attendee typing into the Jabber room for the meeting, and
local attendee going to the mic and repeating what was typed into the some local attendee going to the mic and repeating what was typed
Jabber room. into the Jabber room.
This method of participation often works adequately, but there are This method of participation often works adequately, but there are
many places where it fails. The following is a compendium of stories many places where it fails. The following is a compendium of stories
from recent IETF meetings where remotely speaking at the mic didn't from recent IETF meetings where remotely speaking at the mic didn't
work as well as it could have. The participants are Chris and Carl work as well as it could have. The participants are Chris and Carl
(WG co-chairs), Sam (volunteer Jabber scribe), Rachel and Robert (WG co-chairs), Sam (volunteer Jabber scribe), Rachel and Robert
(remote attendees), Pete (presenter), and Len and Lee (local (remote attendees), Pete (presenter), and Len and Lee (local
attendees). 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
skipping to change at page 11, line 8 skipping to change at page 12, line 10
Although the previous section may seem like it is a bit harsh on WG Although the previous section may seem like it is a bit harsh on WG
chairs, the current tools do not give them the kind of control over chairs, the current tools do not give them the kind of control over
remote attendees that they have over local attendees. The chairs can 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 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. is 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 and Lou and Lars finishes and asks for questions. Lee and Len rush to the mic
rush to the mic line, and it takes Robert a few seconds to get his line, and it takes Robert a few seconds to get his question into
question into the Jabber room and for Sam to go to the mic. Carl the Jabber room and for Sam to go to the mic. Carl tries to
tries to prioritize Sam forward in the line, but Len gets upset prioritize Sam forward in the line, but Len gets upset when he
when he does. does.
o Rachel asks a question, but Sam is not going to the mic to relay 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 it. In fact, Sam has pretty much stopped paying attention. Chris
cannot do something about the situation without making Sam look cannot do something about the situation without making Sam look
bad. bad.
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
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 participants, so the
meeting is disrupted until that person finally realizes that he or
she is not muted.
o [[[ TODO: More here, of course. ]]] o [[[ TODO: More here, of course. ]]]
3.5. Remotely Presenting at Regular IETF Meetings 3.5. Remotely Presenting at Regular IETF Meetings
Some WGs have experimented with remote presented in recent years with Some WGs have experimented with remote presentations in recent years
quite mixed results. For some, it works fine: the remote presenter with quite mixed results. For some, it works fine: the remote
speaks, the chair moves the slides forward, and questions can be presenter speaks, the chair moves the slides forward, and questions
heard easily. For others, it is a mess: the local attendees can't can be heard easily. For others, it is a mess: the local attendees
hear the presenter very well, the presenter can't hear questions or can't hear the presenter very well, the presenter can't hear
there is a long delay, and it was not clear when the presenter was questions or there is a long delay, and it was not clear when the
waiting for input or there was a lag in the sound. 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
camera set up at the chairs' desk pointed towards the audience so camera set up at the chairs' desk pointed towards the audience so
that the presenter could see who was a the mic; this was considered 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 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 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 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
skipping to change at page 12, line 35 skipping to change at page 13, line 44
[[[ TODO: More discussion about experiences with virtual interims. [[[ TODO: More discussion about experiences with virtual interims.
Focus on differences between the all-in-one systems like WebEx and Focus on differences between the all-in-one systems like WebEx and
the cobble-together systems where there is an audio feed with no the cobble-together systems where there is an audio feed with no
floor control plus pre-distributed slideware. ]]] floor control plus pre-distributed slideware. ]]]
4. Requirements for Supporting Remote Participation in Face-to-Face 4. Requirements for Supporting Remote Participation in Face-to-Face
Meetings Meetings
This section covers the functional specification for effective remote This section covers the functional specification for effective remote
participation in meetings where some members are in a face-to-face participation in meetings where some members are in a face-to-face
meeting, such as the regular IETF meetings an interim WG meetings meeting, such as the regular IETF meetings and interim WG meetings
that are held in a meeting room. Some of the requirements in this that are held in a meeting room. Some of the requirements in this
section overlap with those in Section 5, but many are unique to section overlap with those in Section 5, but many are unique to
meetings that have a significant physical presence. meetings that have a significant physical presence.
There is an assumption in this section that the meeting chairs will There is an assumption in this section that the meeting chairs will
continue to control the flow of the discussion. That is, if a continue to control the flow of the discussion. That is, if a
presenter is speaking and a remote attendee wants to ask a question, 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. the request to do so goes to the chair, not to the presenter.
Recordings of the events of the meetings are valuable for remote **Requirement 01-01**: The specifications SHOULD rely upon IETF and
attendees who are not able to hear everything in real time. This is other open standards for all communications and interactions wherever
reflected in many requirements below. possible.
**Requirement 00-01**: The specifications shall rely solely upon IETF **Requirement 01-02**: All tools in the RPS SHOULD be able to be run
and other open standards for all communications and interactions. on the widest possible array of computers. This means that they need
(This requirement comes from [RPS-RFP].) to be able to be run as an application, from any modern web browser,
**Requirement 00-02**: All tools in the RPS must be able to be run on or from the command line of all of (at least) MacOS version 10.6 or
the widest possible array of computers. This means that they must be
able to be run as an application, from any modern web browser, or
from the command line of all of (at least) MacOS version 10.6 or
later, Windows 7 or later, and any common Linux distribution produced later, Windows 7 or later, and any common Linux distribution produced
in 2010 or later. in 2010 or later. [[[ TODO: Do we need to include IOS and Android
platforms in that list? ]]]
[[[ TODO: Do we need to include IOS and Android platforms in that A common complaint with the current RPS is that the streaming audio
list? ]]] 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. **Requirement 01-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.
4.1. Technologies [[[ 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.
]]]
4.1.1. Audio [[[ 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 01-04**: 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.
]]]
4.1. Registration for Remote Participation
There has been periodic discussion of whether remote attendees are or
are not bound by the "note well" text that local attendees are bound
to. By requiring registration before participating, remote attendees
can be better bound to that text.
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 01-05**: All remote attendees MUST register with the
IETF Secretariat before using any of the RPS tools described here.
**Requirement 01-06**: 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 01-07**: A remote attendee who doesn't want to
identified MUST be able to use an anonymized name when appearing in
video and instant messaging. [[[TODO: Is the anonymity appropriate
in light of the "note well" and floor control requirements? ]]]
**Requirement 01-08**: The RPS MUST gracefully handle multiple
attendees who have the same name.
4.2. Technologies
4.2.1. Audio
A few requirements come from the IETF's current use of audio in 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, 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 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 ask questions. Plenaries have many more mics, both at the front of
the room and in the audience. the room and in the audience.
Note that the requirements here assume a very large change in the way Note that the requirements here assume a very large change in the way
that remote participation will happen. Instead of a remote attendee that remote participation will happen. Instead of a remote attendee
typing something into the Jabber room that someone will repeat at a 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 mic in the room, remote attendees will use their own mics to speak to
the meeting. the meeting.
**Requirement 00-03**: Remote attendees need to be able to hear what **Requirement 01-09**: Remote attendees MUST be able to hear what is
is said by local attendees and chairs at any mic in the meeting. said by local attendees and chairs at any mic in the meeting.
**Requirement 00-04**: Remote attendees must be able to speak **Requirement 01-10**: Remote attendees MUST be able to speak
directly to a meeting without going through a local attendee, and directly to a meeting without going through a local attendee, and
have their speaking be heard by local attendees. (Note that the have their speaking be heard by local attendees. (Note that the
ability to speak is controlled by the chair; see Section 4.2.2.) [[[ ability to speak is controlled by the chair; see Section 4.3.2.)
TODO: is there a requirement that remote attendees who speak be
registered as in Requirement 00-30 and Requirement 00-31? ]]]
A common complaint with the current RPS is that the streaming audio **Requirement 01-11**: Local attendees MUST be able to determine
can take more than 10 seconds (and sometimes as much as 30 seconds) which remote attendee is speaking, unless the remote attendee is
to reach the remote attendee. This causes many of the problems using an anonymized display name (see Requirement 01-07).
listed in Section 3.3. **Requirement 00-05**: Audio going to and from
remote attendees must be delivered in as close to real-time as is **Requirement 01-12**: The RPS MUST give a remote attendee who is
practically possible. **Requirement 00-06**: Audible echo must be allowed to speak a clear signal when they should and should not
damped or eliminated by the tools. speak.
IETF meetings happen in venues such as hotels and conference centers, IETF meetings happen in venues such as hotels and conference centers,
most of which have their own audio setups. The IETF Secretariat 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 contracts with those venues for the use of some or all of their audio
system. **Requirement 00-07**: The audio system used by the RPS must system. **Requirement 01-13**: The audio system used by the RPS MUST
be able to integrate with systems commonly used in the venues used be able to integrate with systems commonly used in the venues used
for IETF meetings. for IETF meetings.
**Requirement 00-08**: Recordings of the audio for all meetings must 4.2.2. Video
be kept for distribution after IETF meetings. **Requirement 00-09**:
Users must be able to easily find the audio recording of a particular
WG or BoF session at a particular meeting.
4.1.2. Video
The RFP that preceded the current document, [RPS-RFP], discusses The RFP that preceded the current document, [RPS-RFP], discusses
video as a requirement. The IETF has experimented with one-way and video as a requirement. The IETF has experimented with one-way and
two-way video at some meetings in the past few years. Remote two-way video at some meetings in the past few years. Remote
attendees have said that seeing people in the meetings gave them attendees have said that seeing people in the meetings gave them a
better understanding of the meeting; at a recent meeting, a remote 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 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 better able to interact with them. [[[ TODO: determine how much of
this is needed for effective participation. ]]] this is needed for effective participation. ]]]
**Requirement 00-10**: Remote attendees need to be able to see the **Requirement 01-14**: Remote attendees MUST be able to see the
presenter at a meeting. **Requirement 00-11**: Remote attendees need presenter at a meeting. **Requirement 01-15**: Remote attendees MUST
to be able to see local attendees at any mic in the meeting. [[[ be able to see local attendees at any mic in the meeting.
TODO: Is there a requirement that the remote attendees see the slides
over video? ]]]
**Requirement 00-12**: Remote attendees who are speaking over the
audio must be visible to the local attendees.
**Requirement 00-13**: Video going to and from remote attendees must **Requirement 01-16**: The RPS MUST have the capability of showing
be delivered in as close to real-time as is practically possible. video of the remote attendee who is speaking over the audio to the
local attendees. **Requirement 01-17**: 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 01-18**: The RPS MUST give a remote attendee a
clear indication when their video image is being shown to the local
attendees.
[[[ TODO: Is there a requirement that IETF video integrate with the [[[ TODO: Is there a requirement that IETF video integrate with the
venue video, if any? ]]] venue video, if any? ]]]
[[[ TODO: If video is provided, is there a requirement that it be 4.2.3. Instant Messaging
archived and accessible? ]]]
4.1.3. Instant Messaging
As noted earlier, while the current tool's Jabber room is a good way 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 to get questions to the mic, it also becomes a second communications
channel that only a few people in the room are participating in. channel that only a few people in the room are participating in.
This document does not address how to prevent that problem (or This document does not address how to prevent that problem (or
whether it really is much of a problem). 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
**Requirement 00-14**: The instant messaging system must allow anyone room ("is anyone there?").
to see all messages in the WG's or BoF's room. **Requirement 00-15**:
The instant messaging system must allow any registered user (even
those registered anonymously) to post messages in the WG's or BoF's
room.
**Requirement 00-16**: Transcripts of the instant messaging for all **Requirement 01-19**: The instant messaging system MUST allow anyone
meetings must be kept for distribution after IETF meetings. to see all messages in the WG's or BoF's room. **Requirement 01-20**:
**Requirement 00-17**: Users must be able to easily find the instant The instant messaging system MUST allow any registered user (even
messaging transcripts of a particular WG or BoF session at a those registered to use anonymous names) to post messages in the WG's
particular meeting. or BoF's room.
**Requirement 00-18**: The instant messaging channel needs to be Someone coming into a meeting late requires context for which
useful for humming, which is the common IETF method of assessing messages in an instant messaging room are recent and which are old.
support. **Requirement 01-21**: The date and time that a message appears in a
room MUST be retained. Instant messaging clients MUST be able to
show an indication of the date and time for all messages.
[[[ TODO: Should there be multiple rooms for a meeting? There were [[[ TODO: Should there be multiple rooms for a meeting? There were
many requests for a separate "speak into the mic" room, but that is many requests for a separate "speak into the mic" room, but that is
not needed if the requirements in Section 4.1.1 are met. Is there a not needed if the requirements in Section 4.2.1 are met. Is there a
need for other rooms? ]]] need for other rooms? ]]]
[[[ TODO: Should non-registered people be allowed to read the IM [[[ TODO: Should non-registered people be allowed to read the IM
traffic in real time, given that anyone can register anonymously? traffic in real time, given that anyone can register anonymously?
Should people registered anonymously be allowed to post in IM rooms? Should people registered anonymously be allowed to post in IM rooms?
]]] ]]]
4.1.4. Slide Presentations 4.2.4. Slide Presentations
**Requirement 00-19**: The input format for slide presentations must
be either PDF or PowerPoint. [[[ TODO: Is there a requirement to
support other formats? ]]]
**Requirement 00-20**: Presenters must be able to update their slides In many current remote participation systems, slide presentations and
up to just before their presentation, if such update is allowed by the video coming from in-meeting cameras are sent as two separate
the chairs. **Requirement 00-21**: Chairs must be able to approve or streams (called the "slide stream" and the "camera stream"). The
disapprove of any slide submission or updates, with the default being slide stream is usually much lower bandwidth than the camera stream,
that all submissions are allowed. 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.
**Requirement 00-22**: It needs to be clear to the remote attendees **Requirement 01-22**: The RPS MUST transmit the slide stream
which set of slides is being currently shown. separately from the camera stream. **Requirement 01-23**: 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.
[[[ TODO: Is there are requirement that remote attendees see the **Requirement 01-24**: It MUST be made clear to the remote attendees
slides as the people in the room? Or, is it sufficient to keep it as which set of slides, and which slide number, is being currently
it is now where remote attendees must download them and speakers must shown.
say which slide they are on? If the slides will be visible to remote
attendees as they are presented, there will be a requirement that the
presenter can go back and forth in the slide deck. ]]]
[[[ TODO: If the slides will be visible to remote attendees as they [[[ TODO: If the slides will be visible to remote attendees as they
are presented, is there a requirement that presenters be able to use are presented, is there a requirement that presenters be able to use
the equivalent of a laser pointer? ]]] the equivalent of a laser pointer? ]]]
[[[ TODO: Is there a requirement that animation in PowerPoint be 4.2.5. Slide Distribution
supported, or just static slides? ]]]
4.1.5. Shared Document Editing 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.
**Requirement 01-25**: The RPS MUST be able to handle both PDF and
PowerPoint 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? ]]]
**Requirement 01-26**: The RPS MUST automatically convert PowerPoint
presentations to PDF and make both available for distribution at the
same time.
**Requirement 01-27**: 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 01-28**: Chairs MUST be able to approve or disapprove
of any slide submission or updates, with the default being that all
submissions are allowed.
4.2.6. Shared Document Editing
In some WG meetings, there is an attempt to edit a document with In some WG meetings, there is an attempt to edit a document with
input from the local attendees. This is typically done for proposed input from the local attendees. This is typically done for proposed
charter changes, but can also be for a WG document as well. This is charter changes, but sometimes happens on a WG document or the
usually unsuccessful, given the amount of text and the size of what meeting's agenda. This is usually unsuccessful, given the amount of
can be displayed on the screen. In recent meetings, shared document text and the size of what can be displayed on the screen. In recent
editing has been used for editing charters and for taking minutes of meetings, shared document editing has been used for editing charters
meetings. and for taking minutes of meetings.
**Requirement 00-23**: It must be easy to start a new shared document **Requirement 01-29**: It MUST be easy to start a new shared document
and to import existing text into a shared document. and to import existing text into a shared document.
**Requirement 00-24**: Shared real-time editing of text-only **Requirement 01-30**: Shared real-time editing of text-only
documents must be supported. This system must allow at least three documents MUST be supported. This system must allow at least three
people to have write access and hundreds of people to have read people to have write access and hundreds of people to have read
access to any particular document. access to any particular document.
**Requirement 00-25**: Remote attendees can be either the writers or **Requirement 01-31**: Remote attendees MUST be able to be either the
the readers. writers or the readers of shared documents.
**Requirement 00-26**: Those with read access need to see the edits **Requirement 01-32**: Those with read access MUST be able to see the
made by those with write access within less that five seconds after edits made by those with write access within less that five seconds
each edit. after each edit.
**Requirement 00-27**: It must be easy to change the permissions for **Requirement 01-33**: It MUST be easy to change the permissions for
who gets write access to a document during an editing session. who gets write access to a document during an editing session.
[[[ TODO: Is this also needed for non-text documents? If so, in what [[[ TODO: Is this also needed for non-text documents? If so, in what
formats? ]]] formats? For example, is drawing on a whiteboard needed? ]]]
4.2. Tools 4.3. Tools
4.2.1. Requirements for Remote Participation 4.3.1. Requirements for Remote Participation
**Requirement 00-28**: Remote attendees must be able to easily find **Requirement 01-34**: Remote attendees MUST be able to easily find
all the material they need to effectively participate, including all the material they need to effectively participate, including
links to audio, video, instant messaging, slides, and so on. This links to audio, video, instant messaging, slides, and so on. This
material must be available well before the time of the meeting. material MUST be available well before the time of the meeting. The
page with the meeting material SHOULD allow the remote attendee to
**Requirement 00-29**: A remote attendee who comes to a meeting late easily perform a time conversion to and from the local time at the
needs to be able to tell what is happening in the meeting. In IETF meeting.
specific, there needs to be an indication that the meeting has not
started, when the meeting is happening (even if there is silence on
the mics), and when the meeting is over.
With the current tools, it is common in the current IETF RPS for
people reading from the Jabber room to not know who is requesting
that something be said at the mic. There is no such confusion in the
room of local attendees because everyone has a name badge. The
current tools also do not let remote attendees do the equivalent of
"signing the blue sheets".
**Requirement 00-30**: The RPS must have a system where a remote **Requirement 01-35**: A remote attendee who comes to a meeting late
attendee can register their name and have that name be used in the MUST be able to tell what is happening in the meeting. In specific,
instant messaging system. This must be able to be done once for an there MUST be an indication if the meeting has not started, if the
entire regular IETF meeting, but the attendee needs to be able to meeting is happening (even if there is silence on the mics), and if
indicate which WG sessions they are participating in. **Requirement the meeting is over.
00-31**: A remote attendee who doesn't want to identified should be
able to register with an anonymized name.
**Requirement 00-32**: Remote attendees must be able to test the Remote attendees need to be able to test the remote participation
remote participation setup before a regular meeting. There must be a setup before a regular meeting, and even during the meeting.
constantly-running audio (and possibly video) stream for at least a **Requirement 01-36**: There MUST be a constantly-running testing
week before the meeting begins that users can connect to. This test service that covers all interactive tools (audio, video, slide
setup must also run throughout the meeting so that last-minute display, and so on) for at least a week before the meeting begins.
joiners can test their systems. **Requirement 01-37**: The testing service MUST run throughout the
meeting so that last-minute joiners can test their systems.
**Requirement 01-38**: The testing service SHOULD allow remote
attendees to also test whether their outgoing audio, video, and slide
control works.
**Requirement 00-33**: Remote attendees must be able to easily **Requirement 01-39**: Remote attendees SHOULD be able to easily
contact the IETF Secretariat if they find problems with any of the contact the IETF Secretariat if they find problems with any of the
RPS tools, and to get fairly rapid response. **Requirement 00-34**: RPS tools, and to get fairly rapid response. **Requirement 01-40**:
Similarly, local attendees must be able to easily contact the IETF Similarly, local attendees SHOULD be able to easily contact the IETF
Secretariat if there are RPS problems in the meeting rooms. Secretariat if there are RPS problems in the meeting rooms.
Regular IETF meetings are more than just a group of WG meetings. Regular IETF meetings are more than just a group of WG meetings.
Remote attendees may want to participate in the other parts of a Remote attendees may want to participate in the other parts of a
regular meeting as well. **Requirement 00-35**: The RPS tools must be regular meeting as well. **Requirement 01-41**: The RPS tools MUST be
available for lunch meetings scheduled by the IETF Secretariat, such available for AD-sponsored lunch meetings scheduled by the IETF
as for the Security Directorate and Working Group Chairs lunches. Secretariat.
**Requirement 00-36**: The IETF Secretariat should attempt to make
the RPS tools available outside of the regular meeting rooms during a
meeting. For example, if a "bar BoF" is "scheduled" to be in the
same venue as the IETF meeting, the IETF Secretariat should attempt
to have some or all of the RPS tools available for that meeting.
4.2.2. Floor Control for Chairs 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 01-42**: Any tools that are used by remote
attendees MUST also be available to local attendees as well.
Many remote attendees will be in places with limited bandwidth.
**Requirement 01-43**: All streaming information from the RPS MUST be
usable over slow Internet connections. [[[ TODO: We need to define
"slow" here, or drop the requirement.]]]
4.3.2. Floor Control for Chairs
Newcomers to regular IETF meetings often expect the floor control in Newcomers to regular IETF meetings often expect the floor control in
WG meetings to be fairly straight-forward. By Tuesday, they might be WG meetings to be fairly straight-forward. By Tuesday, they might be
shaking their heads, wondering why some people cut into the mic 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 lines, why some people get up to the mics after the chair has closed
the line, why some people ignore presenters' requests to hold the line, why some people ignore presenters' requests to hold
questions to the end, and so on. Mixing remote attendees into this 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 social structure will be a daunting task, but one that has been dealt
with in many remote participation systems. with in many remote participation systems.
It is not yet clear how the set of remote attendees would be treated. It is not yet clear how the set of remote attendees would be treated
Some tools have each remote attendee being considered separately, for queueing. Some tools have each remote attendee being considered
while others pool all remote attendees into one group. This affects separately, while others pool all remote attendees into one group.
the chair knowing and being able to act on the order that remote This affects the chair knowing and being able to act on the order
attendees ask to speak. that remote attendees ask to speak.
**Requirement 00-37**: Remote attendees must have an easy and **Requirement 01-44**: Remote attendees MUST have an easy and
standardized way of requesting the attention of the chair when the standardized way of requesting the attention of the chair when the
remote attendee wants to speak. The remote attendee must also be remote attendee wants to speak. The remote attendee MUST also be
able to easily cancel an attention request. (Note that Requirement able to easily cancel an attention request. (Note that Requirement
00-29 implies that someone is watching the request queue, something 01-35 implies that someone is watching the request queue, something
that does not happen consistently with the current tools.) that does not happen consistently with the current tools.)
**Requirement 00-38**: A remote attendee's request for attention must A remote attendee might want to indicate that they are asking a
be able to include an optional short text string. This allows, for question of the presenter, or answering a question that someone else
example, a remote attendee to indicate that they are asking a asked at the mic, or want to bring up a new topic. **Requirement
question of the presenter or answering a question that someone else 01-45**: The RPS MUST allow a remote attendee's request for attention
asked at the mic. to include an optional short text string.
**Requirement 00-39**: Remote attendee's requests must be part of the **Requirement 01-46**: Remote attendee's requests MUST be part of the
floor control tool, not in the instant messaging system. floor control tool, not in the instant messaging system.
**Requirement 00-40**: The chair must be able to see all requests **Requirement 01-47**: The chair MUST be able to see all requests
from remote attendees to speak at any time during the entire meeting from remote attendees to speak at any time during the entire meeting
(not just during presentations) in the floor control system. (not just during presentations) in the floor control system.
**Requirement 00-41**: The floor control system must allow a chair to **Requirement 01-48**: The floor control system MUST allow a chair to
easily turn off and on an individual's ability to speak over the easily turn off and on an individual's ability to speak over the
audio at any time. audio at any time.
**Requirement 00-42**: The floor control system must allow a chair to **Requirement 01-49**: The floor control system MUST allow a chair to
easily mute all remote attendees. easily mute all remote attendees.
**Requirement 00-43**: The floor control system must allow a chair to **Requirement 01-50**: The floor control system MUST allow a chair to
easily allow all remote attendees to speak without requesting easily allow all remote attendees to speak without requesting
permission; that is, the chair must be easily able to turn on all permission; that is, the chair MUST be able to easily turn on all
remote attendees mics at once. remote attendees mics at once.
**Requirement 00-44**: The floor control system for the chair must be It is common for a chair to leave the room, to have a side discussion
able to be run by at least two users at the same time. This allows, with an AD, or to become a presenter. They should be able to do so
for example, a chair to leave the room or to become a presenter
without having to do a handoff of the floor control capability. without having to do a handoff of the floor control capability.
**Requirement 01-51**: The floor control system for the chair MUST be
able to be run by at least two users at the same time.
**Requirement 00-45**: The users who can use the floor control system **Requirement 01-52**: The RPS MUST authenticate users who can use
in a particular meeting must be authenticated using simple passwords. the floor control system in a particular meeting using simple
passwords.
**Requirement 00-46**: The IETF Secretariat must be easily able to **Requirement 01-53**: The IETF Secretariat MUST be able to easily
set up the individuals allowed to use the floor control system for a set up the individuals allowed to use the floor control system for a
particular meeting and to change the settings at any time, including particular meeting and to change the settings at any time, including
during the meeting. 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? ]]]
4.2.3. Transcription [[[ 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 00-47**: Transmitting real-time transcription to remote **Requirement 01-54**: The chair SHOULD be able to monitor the sound
attendees must be supported. The lag in transmission must be less 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.3. 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 01-55**: The RPS MUST support storage and distribution
of recordings of the audio, video, and slide presentations for all
sessions after IETF meetings. **Requirement 01-56**: Transcripts of
the instant messaging for all meetings MUST be kept for distribution
after IETF meetings. **Requirement 01-57**: The recordings and
transcripts SHOULD be made available during the meetings, within a
day of them being made.
**Requirement 01-58**: 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 01-59**: The RPS SHOULD support indexing of archived
audio and video for particular events in meetings such as when
speakers change.
4.3.4. Transcription
**Requirement 01-60**: Transmitting real-time transcription to remote
attendees MUST be supported. The lag in transmission MUST be less
than five seconds. than five seconds.
4.2.4. Polling 4.3.5. Polling
**Requirement 00-48**: A system for polling meeting participants, The common IETF method of assessing support is a straw poll,
including remote attendees at the same time, must be provided. It sometimes managed by audible humming, sometimes by raising hands.
must be easy to set up a simple poll, and it must be easy for all
participants to find the poll and participate.
4.3. Use by IETF Leadership **Requirement 01-61**: 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. [[[ 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.4. Use by IETF Leadership
The requirements for bodies like the IESG and IAB to use the RPS 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 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 main difference is that they need a way to limit who can participate
remotely. **Requirement 00-49**: Remote access to meetings must be remotely. **Requirement 01-62**: The IETF Secretariat MUST be able to
able to be set on a room-by-room basis. **Requirement 00-50**: The easily limit remote access to meetings on a room-by-room basis.
IETF Secretariat must be able to limit participants in restricted **Requirement 01-63**: The IETF Secretariat must be able to limit
meetings using a simple authentication mechanism. participants in restricted meetings using a simple authentication
mechanism.
4.4. Plenaries 4.5. Plenaries
At recent IETF meetings, there has been very little input from remote 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 attendees even when there is a lot in the room, but that may be due
to the current setup, not lack of interest. to the current setup, not lack of interest.
[[[ TODO: Are there any requirements that are special to plenaries [[[ TODO: Are there any requirements that are special to plenaries
that are not covered above? Are there requirements not listed above that are not covered above? Are there requirements not listed above
that mostly come from plenaries that would also apply to very large that mostly come from plenaries that would also apply to very large
WGs? ]]] WGs? ]]]
5. Requirements for Supporting All-Remote Meetings 5. Requirements for Supporting All-Remote Meetings
The requirements for meetings that are all remote (that is, with no The requirements for meetings that are all remote (that is, with no
local attendees) are mostly a subset of the requirements for remote local attendees) are mostly a subset of the requirements for remote
participation in a face-to-face meeting. This section highlights the participation in a face-to-face meeting. This section highlights the
differences from Section 4. differences from Section 4.
All-remote meetings will not use the IETF's current streaming audio; Video for all-remote meetings may be more important than for face-to-
instead, they use systems such as WebEx, gtalk, TeamSpeak, and so on.
They will most likely use the same audio system that is used to
transmit and receive remote attendees' voice in face-to-face
meetings.
Video for all-remote meetings may be more important that for face-to-
face meetings. [[[ TODO: Determine if this is true and, if so, the face meetings. [[[ TODO: Determine if this is true and, if so, the
additional requirements for all the remote attendees. ]]] additional requirements for all the remote attendees. ]]]
Nearly all current remote participation systems have some way for Nearly all current remote participation systems have some way for
changing slides to be presented to all remote attendees. [[[ TODO: Is changing slides to be presented to all remote attendees. [[[ TODO: Is
this a requirement for the IETF RPS? ]]] this a requirement for the IETF RPS? ]]]
Attendance at virtual interim meetings is supposed to be taken, but Attendance at virtual interim meetings is supposed to be taken, but
this is sometimes ignored. A system that is probably at least this is sometimes ignored. A system that is probably at least
somewhat different than that in Section 4.2.1 may be needed for somewhat different than that in Section 4.3.1 may be needed for
collecting attendance at virtual interim meetings. collecting attendance at virtual interim meetings.
[[[ TODO: What are the requirements for registering? Virtual interim [[[ TODO: What are the requirements for registering? Virtual interim
meetings are generally considered to have a very different feeling meetings are generally considered to have a very different feeling
than regular IETF meetings; does this affect the idea of than regular IETF meetings; does this affect the idea of
registration? ]]] registration? ]]]
[[[ TODO: Are there different floor control issues for all-remote [[[ TODO: Are there different floor control issues for all-remote
meetings? ]]] meetings? ]]]
skipping to change at page 21, line 10 skipping to change at page 24, line 17
associate people with actions. For example, a remote user might need associate people with actions. For example, a remote user might need
to authenticate to the system in order to give a presentation or to authenticate to the system in order to give a presentation or
speak during a session. The credentials needed for this speak during a session. The credentials needed for this
authentication will need to be managed in a secure fashion, both by authentication will need to be managed in a secure fashion, both by
the system and by the people who are being identified. the system and by the people who are being identified.
8. Acknowledgements 8. Acknowledgements
Many of the ideas in this document were contributed by members of the Many of the ideas in this document were contributed by members of the
IETF community based on their experiences during recent IETF IETF community based on their experiences during recent IETF
meetings. 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 Some of the text in this document originated in the request for
proposals that was issued by the IAOC that led to this document. proposals that was issued by the IAOC that led to this document.
9. Informative References 9. Informative References
[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 [RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998. Procedures", BCP 25, RFC 2418, September 1998.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", Protocol (XMPP): Instant Messaging and Presence",
RFC 3921, October 2004. RFC 3921, October 2004.
 End of changes. 93 change blocks. 
272 lines changed or deleted 429 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/