draft-ietf-genarea-rps-reqs-02.txt   draft-ietf-genarea-rps-reqs-03.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational February 20, 2012 Intended status: Informational March 9, 2012
Expires: August 23, 2012 Expires: September 10, 2012
Requirements for Remote Participation Services for the IETF Requirements for Remote Participation Services for the IETF
draft-ietf-genarea-rps-reqs-02 draft-ietf-genarea-rps-reqs-03
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 August 23, 2012. This Internet-Draft will expire on September 10, 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
skipping to change at page 3, line 35 skipping to change at page 3, line 35
4.1. Registration for Remote Participation . . . . . . . . . . 17 4.1. Registration for Remote Participation . . . . . . . . . . 17
4.2. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. IM-to-Mic Relay of Comments from Remote 4.2.1. IM-to-Mic Relay of Comments from Remote
Participants . . . . . . . . . . . . . . . . . . . . . 18 Participants . . . . . . . . . . . . . . . . . . . . . 18
4.2.2. Audio from Remote Participants to the Room . . . . . . 19 4.2.2. Audio from Remote Participants to the Room . . . . . . 19
4.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1. Video from the Room to Remote Participants . . . . . . 21 4.3.1. Video from the Room to Remote Participants . . . . . . 21
4.3.2. Video from Remote Participants to the Room . . . . . . 22 4.3.2. Video from Remote Participants to the Room . . . . . . 22
4.4. Instant Messaging . . . . . . . . . . . . . . . . . . . . 22 4.4. Instant Messaging . . . . . . . . . . . . . . . . . . . . 22
4.5. Slide Presentations . . . . . . . . . . . . . . . . . . . 23 4.5. Slide Presentations . . . . . . . . . . . . . . . . . . . 23
4.6. Slide Distribution . . . . . . . . . . . . . . . . . . . . 23 4.6. Slide Distribution . . . . . . . . . . . . . . . . . . . . 24
4.7. Shared Document Editing . . . . . . . . . . . . . . . . . 24 4.7. Shared Document Editing . . . . . . . . . . . . . . . . . 24
4.8. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 25 4.8. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 25
4.9. Transcription . . . . . . . . . . . . . . . . . . . . . . 25 4.9. Transcription . . . . . . . . . . . . . . . . . . . . . . 26
4.10. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.10. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.11. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 26 4.11. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 26
4.12. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 26 4.12. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 26
4.13. Additional Requirements for Remote Participation . . . . . 26 4.13. Additional Requirements for Remote Participation . . . . . 27
5. Requirements for Supporting Remote Participation in 5. Requirements for Supporting Remote Participation in
Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 27 Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Requirements for Supporting Remote Participation in 5.1. Requirements for Supporting Remote Participation in
Face-to-Face Interim Meetings . . . . . . . . . . . . . . 28 Face-to-Face Interim Meetings . . . . . . . . . . . . . . 28
5.2. Requirements for Supporting All-Remote Interim Meetings . 29 5.2. Requirements for Supporting All-Remote Interim Meetings . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
9. Informative References . . . . . . . . . . . . . . . . . . . . 30 9. Informative References . . . . . . . . . . . . . . . . . . . . 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
providing supported and experimental online services. providing supported and experimental online services.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
proposed. 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
02-00**". In the IETF, there is an active (and never-ending) debate 03-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 able to specify which remote attendee can speak next" and a
function's specification associated with that requirement might be function's specification associated with that requirement might be
"floor control can be done through a stand-alone application or web "floor control can be done through a stand-alone application or web
form". Functional specifications are not (currently) called out in form". Functional specifications are called out in this document as
this document. "**Functional spec 03-00**".
The requirements covered in this document apply almost exclusively to The requirements and functional specifications covered in this
tools and services that are used for remote participation in real- document apply almost exclusively to tools and services that are used
time meetings. The document does not cover the many other tools used for remote participation in real-time meetings. The document does
by WGs for non-real-time communication such as mailing lists, issue not cover the many other tools used by WGs for non-real-time
trackers, document flow control systems, and so on. Many of the non- communication such as mailing lists, issue trackers, document flow
real-time tools are also being improved over time, but they are not control systems, and so on. Many of the non-real-time tools are also
the subject of this document. being improved over time, but they are not 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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document is being discussed on the vmeet@ietf.org mailing list. This document is being discussed on the vmeet@ietf.org mailing list.
See <https://www.ietf.org/mailman/listinfo/vmeet> for more See <https://www.ietf.org/mailman/listinfo/vmeet> for more
information. information.
2. Scenarios Required to be Supported 2. Scenarios Required to be Supported
skipping to change at page 15, line 26 skipping to change at page 15, line 26
for some WG members. for some WG members.
[[[ 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 Regular IETF 4. Requirements for Supporting Remote Participation in Regular IETF
Meetings Meetings
This section covers the functional specification for effective remote This section covers the requirements and functional specification for
participation in meetings where some members are in regular IETF effective remote participation in meetings where some members are in
face-to-face meetings. Some of the requirements in this section regular IETF face-to-face meetings. Some of the requirements in this
overlap with those in Section 5, but many are unique to meetings that section overlap with those in Section 5, but many are unique to
have a large number of attendees physically present. meetings that have a large number of attendees physically present.
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. This the request to do so goes to the chair, not to the presenter. This
is covered in more detail in Section 4.2.2.1. is covered in more detail in Section 4.2.2.1.
**Requirement 02-01**: The specifications SHOULD rely upon IETF and **Requirement 03-01**: The specifications SHOULD rely upon IETF and
other open standards for all communications and interactions wherever other open standards for all communications and interactions wherever
possible. possible.
**Requirement 02-02**: All tools in the RPS SHOULD be able to be run **Requirement 03-02**: All tools in the RPS SHOULD be able to be run
on the widest possible array of computers. The tool may be a stand- on the widest possible array of computers. The tool may be a stand-
alone application, from any modern web browser, or from the command alone application, from any modern web browser, or from the command
line, but needs to be available on all of (at least) MacOS version line, but needs to be available on all of (at least) MacOS version
10.6 or later, Windows 7 or later, and any common Linux distribution 10.6 or later, Windows 7 or later, and any common Linux distribution
produced in 2010 or later. This also means that the tools MUST NOT produced in 2010 or later. This also means that the tools MUST NOT
rely on Adobe Flash to work correctly. [[[ TODO: Do we need to rely on Adobe Flash to work correctly. [[[ TODO: Do we need to
include IOS and Android platforms in that list? ]]] include IOS and Android platforms in that list? ]]]
**Requirement 02-03**: Audio, video, instant messaging, and slide **Requirement 03-03**: 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. A common complaint close to real-time as is practically possible. A common complaint
with the current RPS is that the streaming audio can take more than with the current RPS is that the streaming audio can take more than
10 seconds (and sometimes as much as 30 seconds) to reach the remote 10 seconds (and sometimes as much as 30 seconds) to reach the remote
attendee. This causes many of the problems listed in Section 3.3.1. attendee. This causes many of the problems listed in Section 3.3.1.
[[[ TODO: Proposed replacement for this requirement is "Delays MUST [[[ TODO: Proposed replacement for this requirement is "Delays MUST
be less than X milliseconds greater than the network delay to the be less than X milliseconds greater than the network delay to the
remote attendee." Two values for X have been proposed: 200 and 500. remote attendee." Two values for X have been proposed: 200 and 500.
]]] ]]]
[[[ TODO: A possibly different way to set the requirement is "The [[[ 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 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 there should probably be a discussion of a possible equivalent for
video. A proposal was "320x240 @ 15fps". ]]] video. A proposal was "320x240 @ 15fps". ]]]
**Requirement 02-04**: The outgoing audio, video, and slide streams **Requirement 03-04**: The outgoing audio, video, and slide streams
MUST have the same delays so the remote participant does not get MUST have the same delays so the remote participant does not get
confused during slide presentations. confused during slide presentations.
**Requirement 02-05**: All streaming information from the RPS MUST be **Requirement 03-05**: All streaming information from the RPS MUST be
usable over slow Internet connections. Many remote attendees will be usable over slow Internet connections. Many remote attendees will be
in places with limited bandwidth. [[[ TODO: We need to define "slow" in places with limited bandwidth. [[[ TODO: We need to define "slow"
here, or drop the requirement.]]] here, or drop the requirement.]]]
**Requirement 02-06**: All proposed tools MUST detail the bandwidth **Requirement 03-06**: All proposed tools MUST detail the bandwidth
required for each participant for various levels of participation required for each participant for various levels of participation
(audio-only, audio and video, and so on). (audio-only, audio and video, and so on).
[[[ TODO: Is there a requirement for PSTN for audio-only? ]]] [[[ TODO: Is there a requirement for PSTN for audio-only? ]]]
**Requirement 02-07**: Audible echo in the audio stream MUST be **Requirement 03-07**: Audible echo in the audio stream MUST be
damped and/or eliminated by the tools. [[[ TOOD: Proposed damped and/or eliminated by the tools. [[[ TOOD: Proposed
replacement: the RPS MUST recognize audible echo and automatically replacement: the RPS MUST recognize audible echo and automatically
take measures to reduce it to a level which won't distract listeners. take measures to reduce it to a level which won't distract listeners.
]]] ]]]
**Requirement 02-08**: WG chairs MUST be able to test whether or not **Requirement 03-08**: WG chairs MUST be able to test whether or not
the tools for their session are working at least 30 minutes before the 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).
**Requirement 02-09**: There MUST be written operational **Requirement 03-09**: 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 02-10**: There SHOULD be training materials for WG **Requirement 03-10**: There SHOULD be training materials for WG
chairs in how to use the RPS tools. chairs in how to use the RPS tools.
4.1. Registration for Remote Participation 4.1. Registration for Remote Participation
There has been periodic discussion of whether or not remote attendees There has been periodic discussion of whether or not remote attendees
are bound by the "Note Well" text that local attendees are bound to. are bound by the "Note Well" text that local attendees are bound to.
The core question is which local and remote attendees are The core question is which local and remote attendees are
"contributors" based on the definitions in [BCP78]. By requiring "contributors" based on the definitions in [BCP78]. By requiring
registration before participating, remote attendees can be better registration before participating, remote attendees can be better
alerted to, and thus hopefully bound to, the requirements of alerted to, and thus hopefully bound to, the requirements of
contributors. contributors.
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.
**Requirement 02-11**: All remote attendees MUST register with the **Requirement 03-11**: All remote attendees MUST register with the
IETF Secretariat before using any of the RPS tools described here. IETF Secretariat before using any of the RPS tools described here.
Note that this would be a significant change to the current RPS tools Note that this would be a significant change to the current RPS tools
in that an unregistered person would not be able to use the IM in that an unregistered person would not be able to use the IM
system. [[[ TODO: Should this be split into "unregistered people can system. [[[ TODO: Should this be split into "unregistered people can
listen and read, but not contribute"? ]]] listen and read, but not contribute"? ]]]
**Requirement 02-12**: The RPS MUST have a system where a remote **Functional spec 03-01**: The RPS MUST have a system where a remote
attendee can register their name and have that name be used in the attendee can register their name and have that name be used in the
instant messaging and video systems. Registration must only need to instant messaging and video systems. Registration must only need to
be done once for an entire regular IETF meeting. be done once for an entire regular IETF meeting.
**Requirement 02-13**: A remote attendee may register a nickname that **Requirement 03-12**: A remote attendee may register a nickname that
will be shown to other attendees during the meeting. A remote will be shown to other attendees during the meeting. A remote
attendee must register with a "verified" name with the IETF attendee must register with a "verified" name with the IETF
Secretariat. The nickname will appear in video and instant Secretariat. The nickname will appear in video and instant
messaging. [[[TODO: Is this anonymity appropriate in light of the messaging. [[[TODO: Is this anonymity appropriate in light of the
"note well" and floor control requirements? ]]] "note well" and floor control requirements? ]]]
**Requirement 02-14**: The RPS tools (particularly the registration **Requirement 03-13**: 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.
**Requirement 02-15**: To support the "blue sheet" functionality for **Functional spec 03-02**: To support the "blue sheet" functionality
remote attendees, the registration tool SHOULD allow a registered for remote attendees, the registration tool SHOULD allow a registered
user to indicate which sessions he or she attended. This notations user to indicate which sessions he or she attended. This notations
SHOULD be allowed for all WG meetings throughout the meeting period. SHOULD be allowed for all WG meetings throughout the meeting period.
The registration system SHOULD remind all registered remote attendees The registration system SHOULD remind all registered remote attendees
at the end of the week to update their notations. at the end of the week to update their notations.
4.2. Audio 4.2. 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 from remote attendees to the room. room to remote attendees, and from remote attendees to the room.
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.
**Requirement 02-16**: Remote attendees MUST be able to hear what is **Requirement 03-14**: 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.
Comments on early drafts of this document indicated that the latter Comments on early drafts of this document indicated that the latter
may not really be a requirement for all participants if IM-to-mic is may not really be a requirement for all participants if IM-to-mic is
made predictable. The two options are split below to make the made predictable. The two options are split below to make the
discussion clearer. Note that even if the consensus is towards IM- discussion clearer. Note that even if the consensus is towards IM-
to-mic, remote-to-room might still be required to enable remote to-mic, remote-to-room might still be required to enable remote
presenters; in this case, there would probably be little need for presenters; in this case, there would probably be little need for
floor control. The requirements for audio are expected to be floor control. The requirements for audio are expected to be
important discussion points in future versions of this document. important discussion points in future versions of this document.
skipping to change at page 18, line 40 skipping to change at page 18, line 40
be a requirement? ]]] be a requirement? ]]]
4.2.1. IM-to-Mic Relay of Comments from Remote Participants 4.2.1. IM-to-Mic Relay of Comments from Remote Participants
As described in Section 3.3.1, the current tools support an informal As described in Section 3.3.1, the current tools support an informal
method for remote attendees to speak at the mic: in the Jabber room, method for remote attendees to speak at the mic: in the Jabber room,
they enter "mic:" before their comment and hope that the designated they enter "mic:" before their comment and hope that the designated
scribe or someone else goes to the mic to relay the comment. This scribe or someone else goes to the mic to relay the comment. This
method works, but has significant flaws described in that section. method works, but has significant flaws described in that section.
**Requirement 02-17**: Relay of messages from IM to the mic MUST **Requirement 03-15**: Relay of messages from IM to the mic MUST
happen as quickly as if the remote attendee was local. happen as quickly as if the remote attendee was local.
**Requirement 02-18**: The person relaying from IM to the mic must be **Requirement 03-16**: The person relaying from IM to the mic must be
available throughout the WG meeting. This could be facilitated by available throughout the WG meeting. This could be facilitated by
hiring people to attend meetings for the specific purpose of being hiring people to attend meetings for the specific purpose of being
IM-to-mic scribes. IM-to-mic scribes.
**Requirement 02-19**: If multiple remote attendees want to comment **Requirement 03-17**: If multiple remote attendees want to comment
at the same time, the person relaying from IM to the mic MUST be able 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). Some of those suggestions might turn into room, and so on). Some of those suggestions might turn into
requirements to be included in this document, but so far most of them requirements to be included in this document, but so far most of them
seem to be really about improving WG chairs, not the RPS tools. seem to be really about improving WG chairs, not the RPS tools.
4.2.2. Audio from Remote Participants to the Room 4.2.2. Audio from Remote Participants to the Room
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 02-20**: Remote attendees MUST be able to speak **Requirement 03-18**: 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.1.) ability to speak is controlled by the chair; see Section 4.2.2.1.)
**Requirement 02-21**: Local attendees MUST be able to determine **Requirement 03-19**: Local attendees MUST be able to determine
which remote attendee is speaking. If the remote attendee is using a which remote attendee is speaking. If the remote attendee is using a
nickname (see Requirement 02-13), that nickname can be used by the nickname (see Requirement 03-12), that nickname can be used by the
remote speaker. remote speaker.
**Requirement 02-22**: The floor control portion of the RPS MUST give **Requirement 03-20**: The floor control portion of the RPS MUST give
a remote attendee who is allowed to speak a clear signal when they a remote attendee who is allowed to speak a clear signal when they
should and should not speak. should and should not speak.
**Requirement 02-23**: The audio system used by the RPS MUST be able **Requirement 03-21**: The audio system used by the RPS MUST be able
to integrate with systems commonly used in the venues used for IETF to integrate with systems commonly used in the venues used for IETF
meetings. IETF meetings happen in venues such as hotels and meetings. IETF meetings happen in venues such as hotels and
conference centers, most of which have their own audio setups. The conference centers, most of which have their own audio setups. The
IETF Secretariat contracts with those venues for the use of some or IETF Secretariat contracts with those venues for the use of some or
all of their audio system. Without such integration, audio from all of their audio system. Without such integration, audio from
remote attendees might not be reliably heard by local participants. remote attendees might not be reliably heard by local participants.
**Requirement 02-24**: When a remote attendee connects to the audio **Requirement 03-22**: 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 02-25**: Remote participants MUST be able to unmute **Requirement 03-23**: Remote participants MUST be able to unmute
themselves; unmuting MUST NOT require interaction from the chair. themselves; unmuting MUST NOT require interaction from the chair.
4.2.2.1. Floor Control for Chairs for Audio from Remote Attendees 4.2.2.1. Floor Control for Chairs for Audio from Remote Attendees
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
skipping to change at page 20, line 27 skipping to change at page 20, line 27
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 4.3.2 need to be met, it is very likely that a related Section 4.3.2 need to be met, it is very likely that a related
requirement to those below is that "the audio and video floor 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 02-26**: Remote attendees MUST have an easy and **Requirement 03-24**: 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
02-69 implies that someone is watching the request queue, something 03-62 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.)
A remote attendee might want to indicate that they are asking a **Functional spec 03-03**: The RPS MUST allow a remote attendee's
request for attention to include an optional short text string. A
remote attendee might want to indicate that they are asking a
question of the presenter, or answering a question that someone else question of the presenter, or answering a question that someone else
asked at the mic, or want to bring up a new topic. **Requirement asked at the mic, or want to bring up a new topic.
02-27**: The RPS MUST allow a remote attendee's request for attention
to include an optional short text string.
**Requirement 02-28**: Remote attendee's requests MUST be part of the **Functional spec 03-04**: Remote attendee's requests MUST be part of
floor control tool, not in the instant messaging system. the floor control tool, not in the instant messaging system.
**Requirement 02-29**: The chair MUST be able to see all requests **Requirement 03-25**: 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 02-30**: The floor control system MUST allow a chair to **Requirement 03-26**: The floor control system MUST allow a chair to
easily turn off and on an individual's ability to speak over the easily turn off and on an individual's ability to speak over the
audio at any time. audio at any time.
**Requirement 02-31**: The floor control system MUST allow a chair to **Requirement 03-27**: The floor control system MUST allow a chair to
easily mute all remote attendees. easily mute all remote attendees.
**Requirement 02-32**: The floor control system MUST allow a chair to **Requirement 03-28**: 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 able to easily 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.
It is common for a chair to leave the room, to have a side discussion **Requirement 03-29**: The floor control system for the chair MUST be
with an AD, or to become a presenter. They should be able to do so able to be run by at least two users at the same time. It is common
without having to do a handoff of the floor control capability. for a chair to leave the room, to have a side discussion with an AD,
**Requirement 02-33**: The floor control system for the chair MUST be or to become a presenter. They should be able to do so without
able to be run by at least two users at the same time. having to do a handoff of the floor control capability.
**Requirement 02-34**: The RPS MUST authenticate users who can use **Functional spec 03-05**: The RPS MUST authenticate users who can
the floor control system in a particular meeting using simple use the floor control system in a particular meeting using simple
passwords. passwords.
**Requirement 02-35**: The IETF Secretariat MUST be able to easily **Requirement 03-30**: 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. [[[ TODO: Should those who are given floor during the meeting. [[[ TODO: Should those who are given floor
control be allowed to augment that list to meet changing needs control be allowed to augment that list to meet changing needs
without going back to the Secretariat? ]]] without going back to the Secretariat? ]]]
[[[ TODO: Is it possible to tell if a remote attendee who is speaking [[[ 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 loses network connectivity? If so, maybe this can be shown to the
chair. ]]] chair. ]]]
**Requirement 02-36**: The chair SHOULD be able to monitor the sound **Requirement 03-31**: 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.
4.3. Video 4.3. 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 a 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. ]]]
4.3.1. Video from the Room to Remote Participants 4.3.1. Video from the Room to Remote Participants
**Requirement 02-37**: Remote attendees MUST be able to see the **Requirement 03-32**: Remote attendees MUST be able to see the
presenter at a meeting. presenter at a meeting.
**Requirement 02-38**: Remote attendees MUST be able to see local **Requirement 03-33**: Remote attendees MUST be able to see local
attendees at any mic in the meeting. attendees at any mic in the meeting.
[[[ 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? ]]]
4.3.2. Video from Remote Participants to the Room 4.3.2. Video from Remote Participants to the Room
Note that the requirements in this section probably only apply if Note that the requirements in this section probably only apply if
there is consensus that audio from remote participants to the room is there is consensus that audio from remote participants to the room is
required. If so, there will probably also be requirements for video required. If so, there will probably also be requirements for video
floor control as well. floor control as well.
**Requirement 02-39**: The RPS MUST have the capability of showing **Requirement 03-34**: 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 02-40**: A remote attendee who is speaking MUST be able **Requirement 03-35**: A remote attendee who is speaking MUST be able
to choose what is shown to local attendees: video of them speaking, a to choose what is shown to local attendees: video of them speaking, a
still picture of their face, or just their name. still picture of their face, or just their name.
**Requirement 02-41**: The RPS MUST give a remote attendee a clear **Requirement 03-36**: The RPS MUST give a remote attendee a clear
indication when their video image is being shown to the local indication when their video image is being shown to the local
attendees. attendees.
[[[ TODO: The way to fulfill these might be that the IETF provide a [[[ TODO: The way to fulfill these might be that the IETF provide a
laptop for the chair that has the right tools on it, and that laptop laptop for the chair that has the right tools on it, and that laptop
is the one connected to the projector. ]]] is the one connected to the projector. ]]]
4.4. Instant Messaging 4.4. 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.
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). The instant messaging 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 system is also useful for remote users to ask about the status of the
room ("is anyone there?"). room ("is anyone there?").
**Requirement 02-42**: The IM system MUST allow anyone to see all **Requirement 03-37**: The IM system MUST allow anyone to see all
messages in the WG's or BoF's room. **Requirement 02-43**: The IM messages in the WG's or BoF's room.
system MUST allow any registered user (even those registered to use
anonymous names) to post messages in the WG's or BoF's room.
Someone coming into a meeting late requires context for which **Requirement 03-38**: The IM system MUST allow any registered user
messages in an instant messaging room are recent and which are old. (even those registered to use anonymous names) to post messages in
**Requirement 02-44**: The date and time that a message appears in an the WG's or BoF's room.
**Requirement 03-39**: The date and time that a message appears in an
IM stream MUST be retained. IM clients MUST be able to show an IM stream MUST be retained. IM clients MUST be able to show an
indication of the date and time for all messages. indication of the date and time for all messages. Someone coming
into a meeting late requires context for which messages in an instant
messaging room are recent and which are old.
[[[ TODO: Should there be multiple rooms for a meeting? There were [[[ 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.2.2 are met. Is there a not needed if the requirements in Section 4.2.2 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?
Should non-registered attendees be able to post to the IM rooms? ]]] Should non-registered attendees be able to post to the IM rooms? ]]]
skipping to change at page 23, line 32 skipping to change at page 23, line 34
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 slides but not the local attendees. Further, separating the the slides but not the local attendees. Further, separating the
streams allows remote attendees to see the slide stream and the streams allows remote attendees to see the slide stream and the
camera streams in separate windows that can be independently sized. camera streams in separate windows that can be independently sized.
**Requirement 02-45**: The RPS MUST transmit the slide stream **Functional spec 03-06**: The RPS MUST transmit the slide stream
separately from the camera stream. **Requirement 02-46**: The slide separately from the camera stream.
stream MUST represent the slides as they are projected in the room,
allowing the presenter to go back and forth, as well as to edit
slides in real time.
**Requirement 02-47**: It MUST be made clear to the remote attendees **Requirement 03-40**: The slide stream MUST represent the slides as
they are projected in the room, allowing the presenter to go back and
forth, as well as to edit slides in real time.
**Requirement 03-41**: It MUST be made clear to the remote attendees
which set of slides, and which slide number, is being currently which set of slides, and which slide number, is being currently
shown. shown.
[[[ 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? ]]]
4.6. Slide Distribution 4.6. Slide Distribution
Slides are available to local and remote attendees on the IETF Slides are available to local and remote attendees on the IETF
servers before and during regular IETF meetings. This service is servers before and during regular IETF meetings. This service is
useful to all attendees who want to be prepared for WG meetings. The 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 slides are not only used by remote attendees listening to the WG
meeting; it is common for local attendees to download the slides and meeting; it is common for local attendees to download the slides and
view them on their laptops during meetings instead of having to read view them on their laptops during meetings instead of having to read
them at the front of the room. them at the front of the room.
**Requirement 02-48**: The RPS MUST be able to handle both PDF and **Functional spec 03-07**: The RPS MUST be able to handle both PDF
PowerPoint formats (".ppt" and ".pptx") for distributed slides. [[[ and PowerPoint formats (".ppt" and ".pptx") for distributed slides.
TODO: Is there a requirement to support other formats? ]]] [[[ TODO: [[[ TODO: Is there a requirement to support other formats? ]]] [[[
For the distributed slides, is there a requirement that animation in TODO: For the distributed slides, is there a requirement that
PowerPoint be supported, or just static slides? ]]] animation in PowerPoint be supported, or just static slides? ]]]
**Requirement 02-49**: The RPS MUST automatically convert PowerPoint **Functional spec 03-08**: The RPS MUST automatically convert
presentations to PDF and make both available for distribution at the PowerPoint presentations to PDF and make both available for
same time. distribution at the same time.
**Requirement 02-50**: Presenters MUST be able to update their slides **Requirement 03-42**: 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 chairs. is allowed by the chairs.
**Requirement 02-51**: Chairs MUST be able to approve or disapprove **Requirement 03-43**: 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.
4.7. Shared Document Editing 4.7. 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 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
text and the size of what can be displayed on the screen. In recent text and the size of what can be displayed on the screen. In recent
skipping to change at page 24, line 43 skipping to change at page 24, line 51
and for taking minutes of meetings. and for taking minutes of meetings.
An RPS tool for shared document editing would be equally useful for An RPS tool for shared document editing would be equally useful for
local and remote attendees watching the edits happen in real-time. local and remote attendees watching the edits happen in real-time.
There is a good chance that this tool would be watched by local There is a good chance that this tool would be watched by local
attendees on their laptops instead of being projected on the screen attendees on their laptops instead of being projected on the screen
because of the small size of the the text. This, in turn, means that because of the small size of the the text. This, in turn, means that
local attendees who aren't using their laptops at the moment would local attendees who aren't using their laptops at the moment would
not be able to participate by watching. not be able to participate by watching.
**Requirement 02-52**: It MUST be easy to start a new shared document **Requirement 03-44**: 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 02-53**: Shared real-time editing of text-only **Requirement 03-45**: 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 02-54**: Remote attendees MUST be able to be either the **Requirement 03-46**: Remote attendees MUST be able to be either the
writers or the readers of shared documents. writers or the readers of shared documents.
**Requirement 02-55**: Those with read access MUST be able to see the **Requirement 03-47**: Those with read access MUST be able to see the
edits made by those with write access within less that five seconds edits made by those with write access within less that five seconds
after each edit. after each edit.
**Requirement 02-56**: It MUST be easy to change the permissions for **Requirement 03-48**: 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? For example, is drawing on a whiteboard needed? ]]] formats? For example, is drawing on a whiteboard needed? ]]]
4.8. Archiving 4.8. 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 02-57**: The RPS MUST support storage and distribution **Requirement 03-49**: The RPS MUST support storage and distribution
of recordings of the audio, video, and slide presentations for all of recordings of the audio, video, and slide presentations for all WG
sessions after IETF meetings. **Requirement 02-58**: Transcripts of meetings.
the instant messaging for all meetings MUST be kept for distribution
after IETF meetings. **Requirement 02-59**: The recordings and
transcripts SHOULD be made available during the meetings, within a
day of them being made.
**Requirement 02-60**: Users MUST be able to easily find the archives **Requirement 03-50**: Transcripts of the instant messaging for all
meetings MUST be kept for distribution after IETF meetings.
**Requirement 03-51**: The recordings and transcripts SHOULD be made
available during the meetings, within a day of them being made.
**Requirement 03-52**: Users MUST be able to easily find the archives
of the recordings and instant messaging transcripts of a particular 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 02-61**: The RPS SHOULD support indexing of archived **Requirement 03-53**: 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 02-62**: The RPS MUST support recording and storage of **Requirement 03-54**: 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 03-55**: Given that interim meetings are run without
the help of the IETF Secretariat, making these recordings MUST be
easy for WG chairs.
4.9. Transcription 4.9. Transcription
**Requirement 02-63**: Transmitting real-time transcription to remote **Requirement 03-56**: Transmitting real-time transcription to remote
attendees MUST be supported. The lag in transmission MUST be less attendees MUST be supported. The lag in transmission MUST be less
than five seconds. than five seconds.
4.10. Polling 4.10. 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 02-64**: A system for polling meeting participants, **Requirement 03-57**: A system for polling meeting participants,
including remote attendees at the same time, MUST be provided. It 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 MUST be easy to set up a simple poll, and it must be easy for all
participants to find the poll and participate. Note that this would participants to find the poll and participate. Note that this would
add a requirement that everyone in a meeting be using their computer add a requirement that everyone in a meeting be using their computer
to participate in the poll. [[[ TODO: Should the RPS also provide a to participate in the poll. [[[ TODO: Should the RPS also provide a
tool that allows yes / no / abstain indications, which comes a lot tool that allows yes / no / abstain indications, which comes a lot
closer to "voting" than currently is common? ]]] closer to "voting" than currently is common? ]]]
4.11. Plenaries 4.11. 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.
**Requirement 02-65**: Remote attendees SHOULD be able to make **Requirement 03-58**: 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.
[[[ TODO: Are there other requirements that are special to plenaries [[[ TODO: Are there other 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? ]]]
4.12. Use by IETF Leadership 4.12. 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 02-66**: The IETF Secretariat MUST be able to easily **Requirement 03-59**: The IETF Secretariat MUST be able to easily
limit remote access to meetings on a room-by-room basis. limit remote access to meetings on a room-by-room basis.
**Requirement 02-67**: The IETF Secretariat must be able to limit **Requirement 03-60**: The IETF Secretariat must be able to limit
participants in restricted meetings using a simple authentication participants 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.
4.13. Additional Requirements for Remote Participation 4.13. Additional Requirements for Remote Participation
**Requirement 02-68**: Remote attendees MUST be able to easily find **Requirement 03-61**: 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 02-69**: A remote attendee who comes to a meeting late **Requirement 03-62**: A remote attendee who comes to a meeting late
MUST be able to tell what is happening in the meeting. In specific, MUST be able to tell what is happening in the meeting. In specific,
there MUST be an indication if the meeting has not started, if the there MUST be an indication if the meeting has not started, if the
meeting is happening (even if there is silence on the mics), and if meeting is happening (even if there is silence on the mics), and if
the meeting is over. the meeting is over.
Remote attendees need to be able to test the remote participation **Requirement 03-63**: There MUST be a constantly-running testing
setup before a regular meeting, and even during the meeting.
**Requirement 02-70**: 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.
**Requirement 02-71**: The testing service MUST run throughout the Remote attendees need to be able to test the remote participation
setup before a regular meeting, and even during the meeting.
**Requirement 03-64**: The testing service MUST run throughout the
meeting so that last-minute joiners can test their systems. meeting so that last-minute joiners can test their systems.
**Requirement 02-72**: The testing service SHOULD allow remote
**Requirement 03-65**: 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 02-73**: Remote attendees SHOULD be able to easily **Requirement 03-66**: 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. RPS tools, and to get fairly rapid response.
**Requirement 02-74**: Similarly, local attendees SHOULD be able to **Requirement 03-67**: Similarly, local attendees SHOULD be able to
easily contact the IETF Secretariat if there are RPS problems in the easily contact the IETF Secretariat if there are RPS problems in the
meeting rooms. meeting rooms.
**Requirement 02-75**: The RPS tools MUST be available for AD- **Requirement 03-68**: The RPS tools MUST be available for AD-
sponsored lunch meetings scheduled by the IETF Secretariat. Regular sponsored lunch meetings scheduled by the IETF Secretariat. Regular
IETF meetings are more than just a group of WG meetings. Remote IETF meetings are more than just a group of WG meetings. Remote
attendees may want to participate in the other parts of a regular attendees may want to participate in the other parts of a regular
meeting as well. meeting as well.
**Requirement 02-76**: Any tools that are used by remote attendees **Requirement 03-69**: 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.
5. Requirements for Supporting Remote Participation in Interim Meetings 5. 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.
**Requirement 02-77**: The RPS SHOULD have a central location where **Functional spec 03-09**: The RPS SHOULD have a central location
the specifics about how remote participation is supported for every where the specifics about how remote participation is supported for
WG interim meeting. This will reduce the problems often seen where every WG interim meeting. This will reduce the problems often seen
messages about how to participate in an interim meeting get buried in where messages about how to participate in an interim meeting get
the WG mailing list. buried in the WG mailing list.
**Requirement 02-78**: There SHOULD be documentation and training for **Requirement 03-70**: 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.
[[[ TODO: Determine how much or how little the IETF Secretariat [[[ TODO: Determine how much or how little the IETF Secretariat
should participate in setting up the RPS for interim meetings. The should participate in setting up the RPS for interim meetings. The
IETF Secretariat currently offers some help to some WGs, but this IETF Secretariat currently offers some help to some WGs, but this
might become more formalized in the future. ]]] might become more formalized in the future. ]]]
5.1. Requirements for Supporting Remote Participation in Face-to-Face 5.1. Requirements for Supporting Remote Participation in Face-to-Face
Interim Meetings Interim Meetings
skipping to change at page 28, line 39 skipping to change at page 28, line 51
travel for a single WG meeting than for an IETF meeting, but there travel for a single WG meeting than for an IETF meeting, but there
may also be less demand because people tend to think of interim WG may also be less demand because people tend to think of interim WG
meetings as less important than regular IETF meetings.. meetings as less important than regular IETF meetings..
Typically, the IETF Secretariat does not control the rooms in which Typically, the IETF Secretariat does not control the rooms in which
face-to-face interims are held, so they have no control over whether face-to-face interims are held, so they have no control over whether
outgoing audio will be supported, or supported well enough to outgoing audio will be supported, or supported well enough to
guarantee that remote attendees can hear. [[[ TODO: Should the IETF guarantee that remote attendees can hear. [[[ TODO: Should the IETF
Secretariat be tasked with helping set up face-to-face interims? ]]] Secretariat be tasked with helping set up face-to-face interims? ]]]
**Requirement 02-79**: The RPS tools MUST be at least partially **Requirement 03-71**: 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 Room audio o Room audio
o Instant messaging o Instant messaging
o Slide distribution o Slide distribution
 End of changes. 93 change blocks. 
141 lines changed or deleted 153 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/