draft-ietf-genarea-rps-reqs-05.txt   draft-ietf-genarea-rps-reqs-06.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational May 2012 Intended status: Informational August 16, 2012
Expires: November 2, 2012 Expires: February 17, 2013
Requirements for Remote Participation Services for the IETF Requirements for Remote Participation Services for the IETF
draft-ietf-genarea-rps-reqs-05 draft-ietf-genarea-rps-reqs-06
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, improving the experience for the remote attendee at the possible, improving the experience for the remote attendee at the
IETF regular meetings and interim meetings without degrading the IETF regular meetings and interim meetings without degrading the
experience for the people that are physically present. Before experience for the people that are physically present. Before
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 November 2, 2012. This Internet-Draft will expire on February 17, 2013.
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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals for an Improved RPS . . . . . . . . . . . . . . . . 4 1.1. Goals for an Improved RPS . . . . . . . . . . . . . . . . 4
1.2. About This Document . . . . . . . . . . . . . . . . . . . 5 1.2. About This Document . . . . . . . . . . . . . . . . . . . 5
2. Requirements for Supporting Remote Participation in 2. Requirements for Supporting Remote Participation in
Regular IETF Meetings . . . . . . . . . . . . . . . . . . . . 7 Regular IETF Meetings . . . . . . . . . . . . . . . . . . . . 7
2.1. Registration for Remote Participation . . . . . . . . . . 8 2.1. Registration for Remote Participation . . . . . . . . . . 8
2.2. Instant Messaging . . . . . . . . . . . . . . . . . . . . 9 2.2. Instant Messaging . . . . . . . . . . . . . . . . . . . . 9
2.3. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Audio to Remote Attendees . . . . . . . . . . . . . . 9 2.3.1. Audio to Remote Attendees . . . . . . . . . . . . . . 10
2.3.2. IM-to-Mic Relay of Comments from 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 . . . . 10 2.3.3. Audio for Presentations from Remote Attendees . . . . 11
2.3.4. Audio from Remote Attendees to the Room for 2.3.4. Audio from Remote Attendees to the Room for
Comments . . . . . . . . . . . . . . . . . . . . . . . 11 Comments . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1. Video from the Room to Remote Attendees . . . . . . . 13 2.4.1. Video from the Room to Remote Attendees . . . . . . . 13
2.4.2. Video from Remote Attendees to the Room . . . . . . . 13 2.4.2. Video from Remote Attendees to the Room . . . . . . . 14
2.5. Slide Presentations and Distribution . . . . . . . . . . . 14 2.5. Slide Presentations and Distribution . . . . . . . . . . . 14
2.6. Shared Text Document Editing . . . . . . . . . . . . . . . 15 2.6. Shared Text Document Editing . . . . . . . . . . . . . . . 15
2.7. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 15 2.7. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.8. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.9. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 16 2.9. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 17
2.10. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 17 2.10. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 17
2.11. Preparation . . . . . . . . . . . . . . . . . . . . . . . 17 2.11. Preparation . . . . . . . . . . . . . . . . . . . . . . . 17
2.11.1. Preparation for WG Chairs . . . . . . . . . . . . . . 17 2.11.1. Preparation for WG Chairs . . . . . . . . . . . . . . 17
2.11.2. Preparation for Remote Attendees . . . . . . . . . . . 18 2.11.2. Preparation for Remote Attendees . . . . . . . . . . . 18
3. Requirements for Supporting Remote Participation in 3. Requirements for Supporting Remote Participation in
Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 18 Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 19
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. Informative References . . . . . . . . . . . . . . . . . . . . 20 7. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Background on IETF Remote Participation . . . . . . . 20 Appendix A. Background on IETF Remote Participation . . . . . . . 21
A.1. How the IETF Meets . . . . . . . . . . . . . . . . . . . . 21 A.1. How the IETF Meets . . . . . . . . . . . . . . . . . . . . 22
A.2. Technologies Currently Used at Regular IETF Meetings . . . 22 A.2. Technologies Currently Used at Regular IETF Meetings . . . 23
A.3. Locating the Meeting Information . . . . . . . . . . . . . 23 A.3. Locating the Meeting Information . . . . . . . . . . . . . 24
A.3.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 24 A.3.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 24
A.3.2. Instant Messaging . . . . . . . . . . . . . . . . . . 24 A.3.2. Instant Messaging . . . . . . . . . . . . . . . . . . 25
A.3.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 24 A.3.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 25
A.4. Remote Participation at IETF Meetings . . . . . . . . . . 25 A.4. Remote Participation at IETF Meetings . . . . . . . . . . 25
A.4.1. Remotely Speaking at the Mic . . . . . . . . . . . . . 25 A.4.1. Remotely Speaking at the Mic . . . . . . . . . . . . . 25
A.4.2. Remotely Presenting . . . . . . . . . . . . . . . . . 28 A.4.2. Remotely Presenting . . . . . . . . . . . . . . . . . 28
A.4.3. Floor Control . . . . . . . . . . . . . . . . . . . . 28 A.4.3. Floor Control . . . . . . . . . . . . . . . . . . . . 29
A.5. Remote Participation at IETF Interim WG Meetings . . . . . 29 A.5. Remote Participation at IETF Interim WG Meetings . . . . . 29
A.5.1. Face-to-Face Interim Meetings . . . . . . . . . . . . 29 A.5.1. Face-to-Face Interim Meetings . . . . . . . . . . . . 30
A.5.2. Virtual Interim Meetings . . . . . . . . . . . . . . . 30 A.5.2. Virtual Interim Meetings . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
There are two types of participants at the three-times-a-year IETF There are two types of participants at the three-times-a-year IETF
meetings: the people who are physically at the meeting ("local meetings: the people who are physically at the meeting ("local
attendees") and people that are not physically at the meeting but are attendees") and people that are not physically at the meeting but are
following the meeting online ("remote attendees"). For more than a following the meeting online ("remote attendees"). For more than a
decade, the IETF has tried to make it easier for remote attendees to decade, the IETF has tried to make it easier for remote attendees to
participate in its face-to-face meetings in a meaningful fashion by participate in its face-to-face meetings in a meaningful fashion by
employing various tools. employing various tools.
skipping to change at page 6, line 36 skipping to change at page 6, line 36
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. It is expected that the IAOC will consider tools described here. It is expected that the IAOC will consider
changes and additions to the RPS periodically after the RPS described changes and additions to the RPS periodically after the RPS described
here is deployed. here is deployed.
Requirements in this document are numbered, such as "**Requirement Requirements in this document are numbered, such as "**Requirement
05-00**". 06-00**".
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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 7, line 15 skipping to change at page 7, line 15
2. Requirements for Supporting Remote Participation in Regular IETF 2. Requirements for Supporting Remote Participation in Regular IETF
Meetings Meetings
This section covers the requirements for effective remote This section covers the requirements for effective remote
participation in meetings where most members are in regular IETF participation in meetings where most members are in regular IETF
face-to-face meetings. Some of the requirements in this section face-to-face meetings. Some of the requirements in this section
overlap with those in Section 3, but many are unique to meetings that overlap with those in Section 3, but many are unique to meetings that
have a large number of attendees physically present. have a large number of attendees physically present.
**Requirement 05-01**: The specifications in the RPS SHOULD rely upon **Requirement 06-01**: The specifications in the RPS SHOULD rely upon
IETF and other open standards for all communications and interactions IETF and other open standards for all communications and interactions
wherever possible. The RPS might not rely on IETF or other open 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 if there is an identified gap that cannot be met by those
standards. standards.
**Requirement 05-02**: All tools in the RPS MUST be able to use both **Requirement 06-02**: All tools in the RPS MUST be able to use both
IPv4 and IPv6 addresses natively. IPv4 and IPv6 addresses natively.
**Requirement 05-03**: All tools in the RPS SHOULD be able to be run **Requirement 06-03**: All tools in the RPS SHOULD be able to be run
on the widest possible array of computers. The tools may be stand- 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 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 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 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 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 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 Android platforms. The tools MUST NOT rely on Adobe Flash to work
correctly. correctly.
**Requirement 05-04**: Audio, video, instant messaging, and slide **Requirement 06-04**: Audio, video, instant messaging, and slide
streams going to and from remote attendees SHOULD be delivered in as streams going to and from remote attendees SHOULD be delivered in as
close to real-time as is practically possible. When possible, the close to real-time as is practically possible. The system MUST
delivery SHOULD have delays of less than 200 milliseconds to remote minimize internal latency, should avoid unnecessary architectural
attendees who are on fast Internet connections. A common complaint latency, and be designed with a goal of having less than 200
with the current RPS is that the streaming audio can take more than milliseconds of delay to registered remote attendees who are on fast
10 seconds (and sometimes as much as 30 seconds) to reach the remote Internet connections. A common complaint with the current RPS is
attendee. This causes many of the problems listed in Appendix A.4.1. 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 05-05**: The outgoing audio, video, and slide streams **Requirement 06-05**: The outgoing audio, video, and slide streams
MUST by synchronized so the remote attendee does not get confused MUST by synchronized so the remote attendee does not get confused
during slide presentations. during slide presentations.
**Requirement 05-06**: All streaming information from the RPS SHOULD **Requirement 06-06**: Many attendees will be in places with limited
be usable over Internet connections running at 56Kbps. Many remote bandwidth. Remote attendees on 56Kbps Internet connections SHOULD be
attendees will be in places with limited bandwidth. 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 05-07**: Both local and remote attendees SHOULD be able **Requirement 06-07**: Both local and remote attendees SHOULD be able
to easily contact a single entity who is available throughout the 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 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 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 tool problems in the meeting rooms, or be able to quickly contact
someone who can address those problems. someone who can address those problems.
**Requirement 05-08**: Any tools that are used by remote attendees **Requirement 06-08**: Any tools that are used by remote attendees
MUST also be available to local attendees as well. At many IETF MUST also be available to local attendees as well. At many IETF
meetings, some local attendees act as remote attendees in WG meetings 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. that they are not sitting in, so they can attend two WGs at once.
**Requirement 05-09**: The deployment of the tools here MUST take **Requirement 06-09**: The deployment of the tools here MUST take
into account making the tools accessible to as many IETF attendees as into account making the tools accessible to as many IETF attendees as
possible. Such deployment is likely to include technical possible. Such deployment is likely to include technical
accomodations for those with visual and hearing disabilities. accommodations for those with visual and hearing disabilities.
2.1. Registration for Remote Participation 2.1. Registration for Remote Participation
Remote attendees who make contributions to the IETF (as defined in Remote attendees who make contributions to the IETF (as defined in
[BCP78]) are bound by the "Note Well" text. By allowing registration [BCP78]) are bound by the "Note Well" text. By allowing registration
before participating remotely, remote attendees can be better alerted before participating remotely, remote attendees can be better alerted
to, and thus bound to, the requirements of contributors. This is to, and thus bound to, the requirements of contributors. This is
particularly important because it is easy in the IETF process to particularly important because it is easy in the IETF process to
change from being an observer to being a contributor. For example, 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 many people who say things in a WG's IM room do not realize that they
are bound by the "Note Well" text. are bound by the "Note Well" text.
**Requirement 05-10**: All remote attendees at regular IETF meetings **Requirement 06-10**: All remote attendees at regular IETF meetings
and interim meetings who make contributions MUST register with the and interim meetings who make contributions MUST register with the
IETF Secretariat before contributing using any of the RPS tools. IETF Secretariat before contributing using any of the RPS tools.
**Requirement 05-11**: Remote attendees who will only be listening **Requirement 06-11**: Remote attendees who will only be listening
and/or watching, but not making contributions, MUST NOT be required and/or watching, but not making contributions, MUST NOT be required
to register. to register.
**Requirement 05-12**: Registration for remote attendees SHOULD be no **Requirement 06-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 06-13**: Registration for remote attendees SHOULD be no
more onerous than joining a WG mail list. Basically, the registrant more onerous than joining a WG mail list. Basically, the registrant
should acknowledge the Note Well, prove that they are at the given should acknowledge the Note Well, prove that they are at the given
email address, and receive confirmation that they are registered. email address, and receive confirmation that they are registered.
The confirmation will also include any passwords needed for the RPS The confirmation will also include any passwords needed for the RPS
tools. tools.
**Requirement 05-13**: The RPS tools (particularly the registration **Requirement 06-14**: The RPS tools (particularly the registration
tool) MUST gracefully handle multiple attendees who have the same tool) MUST gracefully handle multiple attendees who have the same
name. 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.
The cost for remote attendees to register, if any, is not covered in 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 this document but will instead be determined by the IETF at a later
time. There are many ideas on the subject (tiered costs for time. There are many ideas on the subject (tiered costs for
different services, no cost at all for the first year, and others), different services, no cost at all for the first year, and others),
but the effects of different cost structures is beyond the scope of but the effects of different cost structures is beyond the scope of
this document. this document.
2.2. Instant Messaging 2.2. Instant Messaging
Instant messaging (IM) is used both as a remote participation tool Instant messaging (IM) is used both as a remote participation tool
and as a communication tool for local attendees at a regular meeting. 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 Although the current tool's Jabber room is a good way to get
questions to the mic, it also becomes a second communications channel questions to the mic, it also becomes a second communications channel
that only a few people in the room are participating in. The instant 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 messaging system is also useful for remote users to ask about the
status of the room ("is anyone there?"). status of the room ("is anyone there?").
**Requirement 05-14**: The IM system MUST allow anyone to see all **Requirement 06-15**: The IM system MUST allow anyone to see all
messages in the WG's or BoF's room. messages in the WG's or BoF's room.
**Requirement 05-15**: The IM system MUST allow any registered user **Requirement 06-16**: The IM system MUST allow any registered user
to post messages in the WG's or BoF's room. to post messages in the WG's or BoF's room.
**Requirement 05-16**: The date and time that a message appears in an **Requirement 06-17**: The date and time that a message appears in an
IM stream MUST be retained. IM clients MUST be able to show 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 indication of the date and time for all messages. Someone coming
into a meeting late requires context for which messages in an instant into a meeting late requires context for which messages in an instant
messaging room are recent and which are old. messaging room are recent and which are old.
2.3. Audio 2.3. Audio
Audio from face-to-face meetings travels in two directions: from the Audio from face-to-face meetings travels in two directions: from the
room to remote attendees, and (potentially) from remote attendees to room to remote attendees, and (potentially) from remote attendees to
the room. Comments on early drafts of this document indicated that the room. Comments on early drafts of this document indicated that
the latter may not really be a requirement for all attendees if IM- 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 to-mic is made predictable. Given this, reliable IM-to-mic relay for
comments to speakers is highest priority, audio from remote attendees comments to speakers is highest priority, audio from remote attendees
giving presentations is a second priority, and audio from remote giving presentations is a second priority, and audio from remote
attendees giving comments to the room is a third priority. attendees giving comments to the room is a third priority.
2.3.1. Audio to Remote Attendees 2.3.1. Audio to Remote Attendees
**Requirement 05-17**: Remote attendees MUST be able to hear what is **Requirement 06-18**: Remote attendees MUST be able to hear what 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 05-18**: Remote attendees SHOULD be able to hear the **Requirement 06-19**: Remote attendees SHOULD be able to hear the
audio stream over the PSTN. audio stream over the PSTN.
2.3.2. IM-to-Mic Relay of Comments from Remote Attendees 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 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, 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 they enter the string "mic:" before their comment and hope that the
designated scribe or someone else goes to the mic to relay the designated scribe or someone else goes to the mic to relay the
comment. This method works, but the current implementation has comment. This method works, but the current implementation has
significant flaws described in that section. significant flaws described in that section.
**Requirement 05-19**: Relay of messages from IM to the mic MUST be **Requirement 06-20**: The RPS MUST enable relay of messages from IM
able to happen as quickly as if the remote attendee was local. to the mic to be able to happen as quickly as if the remote attendee
was local.
**Requirement 05-20**: The person relaying from IM to the mic must be **Requirement 06-21**: The person relaying from IM to the mic must be
available throughout the WG meeting. To date, this has been done by 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 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 way, or maybe could be facilitated by hiring people to attend
meetings for the specific purpose of being IM-to-mic scribes, or 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 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. IM to a speech synthesizer that reads it to the room.
**Requirement 05-21**: If multiple remote attendees want to comment **Requirement 06-22**: If multiple remote attendees want to comment
at the same time, the person relaying from IM to the mic MUST be able at the same time, the person relaying from IM to the mic MUST be able
to relay for all of them. to relay for all of them.
Note: during the development of this document, there have been many Note: during the development of this document, there have been many
suggestions for how WG chairs can better manage the IM-to-mic suggestions for how WG chairs can better manage the IM-to-mic
relaying (for example, with planned pauses, better tracking of the IM relaying (for example, with planned pauses, better tracking of the IM
room, and so on). Because these are actually about improving WG room, and so on). Because these are actually about improving WG
chairs, not the RPS tools, they are out of scope for this document. chairs, not the RPS tools, they are out of scope for this document.
2.3.3. Audio for Presentations from Remote Attendees 2.3.3. Audio for Presentations from Remote Attendees
In order for a remote attendee to be a presenter, their voice needs In order for a remote attendee to be a presenter, their voice needs
to be heard in the meeting room. This functionality is different to be heard in the meeting room. This functionality is different
than allowing remote attendees from giving comments (covered in than allowing remote attendees from giving comments (covered in
Section 2.3.4) in that the the WG chair needs much less floor control Section 2.3.4) in that the the WG chair needs much less floor control
for one speaker than for many. for one speaker than for many.
**Requirement 05-22**: A remote attendee giving a presentation MUST **Requirement 06-23**: A remote attendee giving a presentation MUST
be able to have their speaking be heard by all local and remote be able to have their speaking be heard by all local and remote
attendees. attendees.
**Requirement 05-23**: A WG chair MUST be able to control the sound **Requirement 06-24**: A WG chair MUST be able to control the sound
coming from a remote attendee. This control MUST allow reduction in coming from any particular remote attendee. This control MUST allow
volume, all the way to complete muting, of the remote speaker. reduction in volume, all the way to complete muting, of the remote
speaker.
**Requirement 05-24**: Audible echo in the audio stream MUST be **Requirement 06-25**: Audible echo in the audio stream MUST be
damped and/or eliminated by the tools. The RPS MUST recognize damped and/or eliminated by the tools. The RPS MUST recognize
audible echo and automatically take measures to reduce it to a level audible echo and automatically take measures to reduce it to a level
which won't distract listeners. which won't distract listeners.
**Requirement 05-25**: The audio system used by the RPS MUST be able **Requirement 06-26**: The audio system used by the RPS MUST be able
to integrate with systems commonly used in the venues used for IETF to integrate with systems commonly used in the venues used for IETF
meetings. 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 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 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. Some of the requirements from Section 2.3.3 will apply the meeting. Some of the requirements from Section 2.3.3 will apply
here as well. here as well.
Further note that, as per above, audio from remote attendees is a Further note that, as per above, audio from remote attendees is a
secondary priority. That means that the "MUST" requirements in this secondary priority. That means that the "MUST" requirements in this
section are for when the priority is being met, not for when the RPS section are for when the priority is being met, not for when the RPS
is initially rolled out. is initially rolled out.
**Requirement 05-26**: Remote attendees MUST be able to speak **Requirement 06-27**: 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 2.3.4.1.) ability to speak is controlled by the chair; see Section 2.3.4.1.)
**Requirement 06-28**: Local attendees MUST be able to determine
**Requirement 05-27**: Local attendees MUST be able to determine
which remote attendee is speaking. which remote attendee is speaking.
**Requirement 05-28**: When a remote attendee connects to the audio **Requirement 06-29**: When a remote attendee connects to the audio
stream to the room, their mic SHOULD start off muted. This will stream to the room, their mic SHOULD start off muted. This will
prevent problems such as those common with WebEx where a remote prevent problems such as those common with WebEx where a remote
attendee doesn't realize that they can be heard. attendee doesn't realize that they can be heard.
**Requirement 05-29**: A lower-priority requirement is for remote **Requirement 06-30**: A lower-priority requirement is for remote
attendees to be able to speak to the room by originating from the attendees to be able to speak to the room by originating from the
PSTN. PSTN.
2.3.4.1. Floor Control for Chairs for Audio from Remote Attendees 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 It is not yet clear how the set of remote attendees would be treated
for queueing. Some tools have each remote attendee being considered for queueing. Some tools have each remote attendee being considered
separately, while others pool all remote attendees into one group. separately, while others pool all remote attendees into one group.
This affects the chair knowing and being able to act on the order This affects the chair knowing and being able to act on the order
that remote attendees ask to speak. that remote attendees ask to speak.
Note that, if the remote video to room requirements from 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 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 requirement to those below is that "the audio and video floor
controls must be in the same tool". controls must be in the same tool".
**Requirement 05-30**: Remote attendees MUST have an easy and **Requirement 06-31**: 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. able to easily cancel an attention request.
**Requirement 05-31**: The RPS MUST allow a remote attendee's request **Requirement 06-32**: The RPS MUST allow a remote attendee's request
for attention to include an optional short text string. A remote for attention to include an optional short (20 characters or less)
attendee might want to indicate that they are asking a question of arbitrary text string. A remote attendee might want to indicate that
the presenter, or answering a question that someone else asked at the they are asking a question of the presenter, or answering a question
mic, or want to bring up a new topic. 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
**Requirement 05-32**: Remote attendee's requests MUST be part of the messages to allow remote participants to make the request for
floor control tool, not in the instant messaging system. attention.
**Requirement 05-33**: The floor control portion of the RPS MUST give **Requirement 06-33**: The floor control portion of the RPS MUST give
a remote attendee who is allowed to speak a clear signal when they a remote attendee who is allowed to speak a clear signal when they
should and should not speak. should and should not speak.
**Requirement 05-34**: The chair MUST be able to see all requests **Requirement 06-34**: 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 05-35**: The floor control system MUST allow a chair to **Requirement 06-35**: The floor control system MUST allow a chair to
easily turn off and on an individual's ability to speak over the
audio at any time.
**Requirement 05-36**: The floor control system MUST allow a chair to
easily mute all remote attendees. easily mute all remote attendees.
**Requirement 05-37**: The floor control system MUST allow a chair to **Requirement 06-36**: 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 SHOULD be able to easily turn on all permission; that is, the chair SHOULD be able to easily turn on all
remote attendees mics at once. remote attendees mics at once.
**Requirement 05-38**: The floor control system for the chair MUST be **Requirement 06-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 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, 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 or to become a presenter. They should be able to do so without
having to do a handoff of the floor control capability. having to do a handoff of the floor control capability.
**Requirement 05-39**: The RPS MUST authenticate users who can use **Requirement 06-38**: The RPS MUST authenticate users who can use
the floor control system in a particular meeting using simple the floor control system in a particular meeting using simple
passwords; other forms of authentication may be used as well. passwords; other forms of authentication may be used as well.
**Requirement 05-40**: The IETF Secretariat MUST be able to easily **Requirement 06-39**: 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.
**Requirement 05-41**: The chair SHOULD be able to monitor the sound **Requirement 06-40**: The chair SHOULD be able to monitor the sound
levels of the audio being delivered to remote attendees to be sure levels of the audio being delivered to remote attendees to be sure
that they can hear what is going on in the room. that they can hear what is going on in the room.
2.4. Video 2.4. Video
The IETF has experimented with one-way and two-way video at some The IETF has experimented with one-way and two-way video at some
meetings in the past few years. Remote attendees have said that meetings in the past few years. Remote attendees have said that
seeing people in the meetings gave them a better understanding of the 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 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. people in line at the mic and was better able to interact with them.
The requirements for video from remote attendees to meeting rooms The requirements for video from remote attendees to meeting rooms
parallel the requirements for audio from remote attendees to meeting parallel the requirements for audio from remote attendees to meeting
rooms. The IETF video may need to integrate with the video systems rooms. The IETF video may need to integrate with the video systems
at some meeting venues. at some meeting venues.
2.4.1. Video from the Room to Remote Attendees 2.4.1. Video from the Room to Remote Attendees
**Requirement 05-42**: Remote attendees MUST be able to see the **Requirement 06-41**: Remote attendees MUST be able to see the
presenter at a meeting. A lower-priority requirement is that remote presenter at a meeting. A lower-priority requirement is that remote
attendees SHOULD be able to see who is speaking at the mics in the attendees SHOULD be able to see who is speaking at the mics in the
room. room.
**Requirement 05-43**: Remote attendees MUST be able to see local **Requirement 06-42**: Remote attendees MUST be able to see local
attendees at any mic in the meeting. attendees at any mic in the meeting.
2.4.2. Video from Remote Attendees to the Room 2.4.2. Video from Remote Attendees to the Room
Note that the requirements in this section have the same priorities Note that the requirements in this section have the same priorities
as for audio for remote presentations (Section 2.3.3) and audio from as for audio for remote presentations (Section 2.3.3) and audio from
remote attendees to the room for comments (Section 2.3.4). remote attendees to the room for comments (Section 2.3.4).
**Requirement 05-44**: When video is allowed for remote attendees to **Requirement 06-43**: When video is allowed for remote attendees to
give presentations (as described in Section 2.3.3), the audience in give presentations (as described in Section 2.3.3), the audience in
the room SHOULD be able to see the presenter speaking. the room SHOULD be able to see the presenter speaking.
**Requirement 05-45**: When video is allowed for remote attendees for **Requirement 06-44**: When video is allowed for remote attendees for
comments, the floor management tool for audio (as described in comments, the floor management tool for audio (as described in
Section 2.3.4.1) MUST also control video as well. Section 2.3.4.1) MUST also control video as well.
**Requirement 05-46**: The RPS MUST have the capability of showing **Requirement 06-45**: The RPS MUST have the capability of showing
video of the remote attendee who is speaking over the audio to the video of the remote attendee who is speaking over the audio to the
local attendees. local attendees.
**Requirement 05-47**: A remote attendee who is speaking MUST be able **Requirement 06-46**: A remote attendee who is speaking MUST be able
to choose what is shown to local attendees: video of them speaking, a to choose what is shown to local attendees: video of them speaking, a
still picture of their face or avatar, or just their name. still picture of their face or avatar, or just their name.
**Requirement 05-48**: The RPS MUST give a remote attendee a clear **Requirement 06-47**: The RPS MUST give a remote attendee a clear
indication when their video image or selected image is being shown to indication when their video image or selected image is being shown to
the local attendees. the local attendees.
2.5. Slide Presentations and Distribution 2.5. Slide Presentations and Distribution
This section discusses slide presentations, which are the primary This section discusses slide presentations, which are the primary
form of presentations made in WG meetings. It should be noted that form of presentations made in WG meetings. It should be noted that
are occasionally other types of presentations, such as videos; these are occasionally other types of presentations, such as videos; these
are not dealt with in the tools proposed below. are not dealt with in the tools proposed below.
**Requirement 05-49**: The RPS MUST be able to handle both PDF and **Requirement 06-48**: The RPS MUST be able to handle both PDF and
PowerPoint formats (".ppt" and ".pptx") for distributed slides. PowerPoint formats (".ppt" and ".pptx") for distributed slides.
**Requirement 05-50**: The RPS MUST automatically convert PowerPoint **Requirement 06-49**: The RPS MUST automatically convert PowerPoint
presentations to PDF and make both available for distribution at the presentations to PDF and make both available for distribution at the
same time. same time.
**Requirement 05-51**: Presenters MUST be able to update their slides **Requirement 06-50**: Presenters MUST be able to update their slides
on the IETF site up to just before their presentation, if such update on the IETF site up to just before their presentation, if such update
is allowed by the WG chairs. is allowed by the WG chairs.
**Requirement 05-52**: Chairs MUST be able to approve or disapprove **Requirement 06-51**: Chairs MUST be able to approve or disapprove
of any slide submission or updates, with the default being that all of any slide submission or updates, with the default being that all
submissions are allowed. submissions are allowed.
In many current remote participation systems, slide presentations and In many current remote participation systems, slide presentations and
the video coming from in-meeting cameras are sent as two separate the video coming from in-meeting cameras are sent as two separate
streams (called the "slide stream" and the "camera stream"). The streams (called the "slide stream" and the "camera stream"). The
slide stream is usually much lower bandwidth than the camera stream, slide stream is usually much lower bandwidth than the camera stream,
so remote attendees with limited bandwidth can choose to watch just so remote attendees with limited bandwidth can choose to watch just
the slide stream. Separating the streams allows remote attendees to the slide stream. Separating the streams allows remote attendees to
see the slide stream and the camera streams in separate windows that see the slide stream and the camera streams in separate windows that
can be independently sized. can be independently sized.
**Requirement 05-53**: The RPS MUST transmit the slide stream **Requirement 06-52**: The RPS MUST transmit the slide stream
separately from the camera stream. separately from the camera stream.
**Requirement 05-54**: The slide stream MUST represent the slides as **Requirement 06-53**: The slide stream MUST represent the slides as
they are projected in the room, allowing the presenter to go back and 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 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, to the remote attendees which set of slides, and which slide number,
is being currently shown. is being currently shown.
**Requirement 05-55**: When remote presentations are supported (see **Requirement 06-54**: When remote presentations are supported (see
Section 2.3.3), the remote presenter SHOULD be able to control the Section 2.3.3), the remote presenter SHOULD be able to control the
slides. This is a lower-priority requirement because this could be slides. This is a lower-priority requirement because this could be
easily done by a local attendee listening to the remote presenter. easily done by a local attendee listening to the remote presenter.
2.6. Shared Text Document Editing 2.6. Shared Text Document Editing
In some WG meetings, there is an attempt to edit a text document with 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 input from the local attendees. This is typically done for proposed
charter changes, but sometimes happens on a WG document or the charter changes, but sometimes happens on a WG document or the
meeting's agenda. This is usually unsuccessful, given the amount of meeting's agenda. This is usually unsuccessful, given the amount of
skipping to change at page 15, line 28 skipping to change at page 15, line 46
charters and for taking minutes of meetings. charters and for taking minutes of meetings.
An RPS tool for shared text document editing would be equally useful An RPS tool for shared text document editing would be equally useful
for local and remote attendees watching the edits happen in real- for local and remote attendees watching the edits happen in real-
time. There is a good chance that this tool would be watched by time. There is a good chance that this tool would be watched by
local attendees on their laptops instead of being projected on the local attendees on their laptops instead of being projected on the
screen because of the small size of the the text. This, in turn, 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 means that local attendees who aren't using their laptops at the
moment would not be able to participate by watching. moment would not be able to participate by watching.
**Requirement 05-56**: Shared real-time editing of text documents **Requirement 06-55**: Shared real-time editing of text documents
MUST be supported. This system must allow at least three people to 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 have write access and hundreds of people to have read access to any
particular document. particular document.
**Requirement 05-57**: It MUST be easy to start a new text shared **Requirement 06-56**: It MUST be easy to start a new text shared
document and to import existing text into a shared document. document and to import existing text into a shared document.
**Requirement 05-58**: Remote attendees MUST be able to be either the **Requirement 06-57**: Remote attendees MUST be able to be either the
writers or the readers of shared documents. writers or the readers of shared documents.
**Requirement 05-59**: Those with read access MUST be able to see the **Requirement 06-58**: Those with read access MUST be able to see the
edits made by those with write access within less that five seconds edits made by those with write access within less that five seconds
after each edit. after each edit.
**Requirement 05-60**: It MUST be easy to change the permissions for **Requirement 06-59**: 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.
**Requirement 05-61**: A much-lower priority requirement is the **Requirement 06-60**: A much-lower priority requirement is the
ability for group-editing of graphics. ability for group-editing of graphics.
2.7. Archiving 2.7. Archiving
Archived recordings of the events of the meetings are valuable for Archived recordings of the events of the meetings are valuable for
remote attendees who are not able to hear everything in real time. remote attendees who are not able to hear everything in real time.
**Requirement 05-62**: The RPS MUST support storage and distribution **Requirement 06-61**: The RPS MUST support storage and distribution
of recordings of the audio, video, and slide presentations for all WG of recordings of the audio, video, and slide presentations for all WG
meetings. meetings.
**Requirement 05-63**: Transcripts of the instant messaging for all **Requirement 06-62**: Transcripts of the instant messaging for all
meetings MUST be kept for distribution after IETF meetings. meetings MUST be kept for distribution after IETF meetings.
**Requirement 05-64**: The recordings and transcripts SHOULD be made **Requirement 06-63**: The recordings and transcripts SHOULD be made
available during the meetings, within a day of them being made. available during the meetings, within a day of them being made.
**Requirement 05-65**: Users MUST be able to easily find the archives **Requirement 06-64**: Users MUST be able to easily find the archives
of the recordings and instant messaging transcripts of a particular of the recordings and instant messaging transcripts of a particular
WG or BoF session at a particular meeting. WG or BoF session at a particular meeting.
**Requirement 05-66**: The RPS SHOULD support indexing of archived **Requirement 06-65**: The RPS SHOULD support indexing of archived
audio and video for particular events in meetings such as when audio and video for particular events in meetings such as when
speakers change. speakers change.
**Requirement 05-67**: The RPS MUST support recording and storage of **Requirement 06-66**: The RPS MUST support recording and storage of
recordings of the audio, video, and slide presentations of interim recordings of the audio, video, and slide presentations of interim
meetings as well as regular IETF meetings. meetings as well as regular IETF meetings.
**Requirement 05-68**: Given that interim meetings are often run **Requirement 06-67**: Given that interim meetings are often run
without the help of the IETF Secretariat, making these recordings without the help of the IETF Secretariat, making these recordings
MUST be easy for WG chairs. MUST be easy for WG chairs.
2.8. Polling 2.8. Polling
The common IETF method of assessing support is a straw poll, The common IETF method of assessing support is a straw poll,
sometimes managed by audible humming, sometimes by raising hands. sometimes managed by audible humming, sometimes by raising hands.
**Requirement 05-69**: A system for yes/no/abstain polling meeting **Requirement 06-68**: A system for yes/no/abstain polling meeting
attendees, including remote attendees at the same time, MUST be 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 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 easy for all local and remote attendees to find the poll and
participate. Note that this would add a requirement that everyone in participate. Note that this would add a requirement that everyone in
a meeting be using their computer to participate in the poll. a meeting be using their computer to participate in the poll.
2.9. Plenaries 2.9. Plenaries
**Requirement 05-70**: Remote attendees SHOULD be able to make **Requirement 06-69**: Remote attendees SHOULD be able to make
comments at the mic approximately as well as if they were local comments at the mic approximately as well as if they were local
attendees. This means that either remote audio to the plenary room attendees. This means that either remote audio to the plenary room
speakers be available, or that IM-to-room relay be available. speakers be available, or that IM-to-room relay be available.
**Requirement 05-71**: Transmitting real-time transcription of **Requirement 06-70**: Transmitting real-time transcription of
plenary speakers to remote attendees MUST be supported. The lag in plenary speakers to remote attendees MUST be supported. The lag in
transmission MUST be less than five seconds. transmission MUST be less than five seconds.
2.10. Use by IETF Leadership 2.10. 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. remotely.
**Requirement 05-72**: The chair or meeting facilitator MUST be able **Requirement 06-71**: The chair or meeting facilitator MUST be able
to easily limit remote access of all tools (both for listening/ to easily limit remote access of all tools (both for listening/
observing and contributing) to meetings on a room-by-room basis. observing and contributing) to meetings on a room-by-room basis.
**Requirement 05-73**: The IETF Secretariat must be able to limit **Requirement 06-72**: The IETF Secretariat must be able to limit
attendees in restricted meetings using a simple authentication attendees in restricted meetings using a simple authentication
mechanism. mechanism.
Note that the IETF leadership will also heavily use the remote Note that the IETF leadership will also heavily use the remote
participation tools between IETF meetings in a manner that is very participation tools between IETF meetings in a manner that is very
similar to virtual interim meetings. similar to virtual interim meetings.
2.11. Preparation 2.11. Preparation
Both WG chairs and attendees need to be able to prepare for an IETF 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 meeting and individual WG meetings. The more tools that might be
used in a meeting, the more important it is that the chairs and used in a meeting, the more important it is that the chairs and
attendees be able to prepare easily. attendees be able to prepare easily.
2.11.1. Preparation for WG Chairs 2.11.1. Preparation for WG Chairs
**Requirement 05-74**: WG chairs MUST be able to test whether or not **Requirement 06-73**: 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 06-74**: 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 06-75**: WG chairs MUST be able to test whether or not
the tools for their session are working at least 30 minutes before the tools for their session are working at least 30 minutes before
the meeting begins (unless, of course, there is already another the meeting begins (unless, of course, there is already another
meeting occurring in the room during that time). meeting occurring in the room during that time). Session testing is
done before session is associated with a physical room.
**Requirement 05-75**: There MUST be written operational **Requirement 06-76**: There MUST be written operational
documentation for each RPS tool that is accessible at all times. documentation for each RPS tool that is accessible at all times.
This will help reduce problems where a WG chair is having problems This will help reduce problems where a WG chair is having problems
during a meeting that is affecting the meeting as a whole. during a meeting that is affecting the meeting as a whole.
**Requirement 05-76**: There SHOULD be training materials for WG **Requirement 06-77**: There SHOULD be training materials for WG
chairs in how to use the RPS tools. chairs in how to use the RPS tools.
**Requirement 05-77**: There SHOULD be a tool that allows a WG chair **Requirement 06-78**: There SHOULD be a tool that allows a WG chair
to prepare each tool that will be used in their WG meeting. Such a to prepare each tool that will be used in their WG meeting. Such a
tool would let the WG chair specify which RPS tools they will use. tool would let the WG chair specify which RPS tools they will use.
**Requirement 05-78**: There SHOULD be a custom checklist for each WG **Requirement 06-79**: There SHOULD be a custom checklist for each WG
that helps the chair prepare for their meeting. The checklist would that helps the chair prepare for their meeting. The checklist would
enumerate the steps needed before the meeting begins, to start the enumerate the steps needed before the meeting begins, to start the
meeting, during the meeting, to close the meeting, and after a meeting, during the meeting, to close the meeting, and after a
meeting. meeting.
2.11.2. Preparation for Remote Attendees 2.11.2. Preparation for Remote Attendees
**Requirement 05-79**: Remote attendees MUST be able to easily find **Requirement 06-80**: 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. The material MUST be available well before the time of the meeting. The
page with the meeting material SHOULD allow the remote attendee to page with the meeting material SHOULD allow the remote attendee to
easily perform a time conversion to and from the local time at the easily perform a time conversion to and from the local time at the
IETF meeting. IETF meeting.
**Requirement 05-80**: There MUST be a constantly-running testing **Requirement 06-81**: There MUST be a constantly-running testing
service that covers all interactive tools (audio, video, slide service that covers all interactive tools (audio, video, slide
display, and so on) for at least a week before the meeting begins. display, and so on) for at least a week before the meeting begins.
Remote attendees need to be able to test the remote participation Remote attendees need to be able to test the remote participation
setup before a regular meeting, and even during the meeting. setup before a regular meeting, and even during the meeting.
**Requirement 05-81**: The testing service MUST run throughout the **Requirement 06-82**: The testing service MUST run throughout the
meeting so that last-minute joiners can test their systems. meeting so that last-minute joiners can test their systems.
**Requirement 05-82**: The testing service SHOULD allow remote **Requirement 06-83**: The testing service SHOULD allow remote
attendees to also test whether their outgoing audio, video, and slide attendees to also test whether their outgoing audio, video, and slide
control works. control works.
**Requirement 05-83**: A remote attendee who starts using one or more **Requirement 06-84**: A remote attendee who starts using one or more
tools after a meeting has begun MUST be able to tell what is tools after a meeting has begun MUST be able to tell what is
happening in the meeting. In specific, there MUST be an indication happening in the meeting. In specific, there MUST be an indication
if the meeting has not started, if the meeting is happening (even if 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. there is silence on the mics), and if the meeting is over.
3. Requirements for Supporting Remote Participation in Interim Meetings 3. Requirements for Supporting Remote Participation in Interim Meetings
One of the goals of this document is to increase the effectiveness of One of the goals of this document is to increase the effectiveness of
interim meetings. Interim meetings are now uncommon, but might interim meetings. Interim meetings are now uncommon, but might
become more common (and more effective) if the remote participation become more common (and more effective) if the remote participation
becomes more useful. becomes more useful.
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 regular IETF meetings and face-to-face interim participation in a regular IETF meetings and face-to-face interim
meeting. meeting.
**Requirement 05-84**: The RPS SHOULD have a central location where **Requirement 06-85**: The RPS SHOULD have a central location where
the specifics about how remote participation is supported for every the specifics about how remote participation is supported for every
WG interim meeting. This will reduce the problems often seen where WG interim meeting. This will reduce the problems often seen where
messages about how to participate in an interim meeting get buried in messages about how to participate in an interim meeting get buried in
the WG mailing list. the WG mailing list.
**Requirement 05-85**: There SHOULD be documentation and training for **Requirement 06-86**: There SHOULD be documentation and training for
the RPS tools specifically targeted at WG chairs who will lead the RPS tools specifically targeted at WG chairs who will lead
interim meetings. interim meetings.
**Requirement 05-86**: The RPS tools MUST be at least partially **Requirement 06-87**: The RPS tools MUST be at least partially
usable at face-to-face meetings other than regular IETF meetings. usable at face-to-face meetings other than regular IETF meetings.
The number of the tools that might be available will be different for The number of the tools that might be available will be different for
different venues for the virtual interims, but at a minimum, the different venues for the virtual interims, but at a minimum, the
following MUST be supported for remote attendees: following MUST be supported for remote attendees:
o Registration o Registration
o Room audio o Room audio
o Instant messaging o Instant messaging
 End of changes. 104 change blocks. 
132 lines changed or deleted 158 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/