draft-ietf-genarea-rps-reqs-01.txt   draft-ietf-genarea-rps-reqs-02.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational January 18, 2012 Intended status: Informational February 20, 2012
Expires: July 21, 2012 Expires: August 23, 2012
Requirements for Remote Participation Services for the IETF Requirements for Remote Participation Services for the IETF
draft-ietf-genarea-rps-reqs-01 draft-ietf-genarea-rps-reqs-02
Abstract Abstract
The IETF has provided some tools for remote participation in its The IETF has provided some tools for remote participation in its
activities for many years, and some IETF participants have also used activities for many years, and some IETF participants have also used
their own tools when they felt the need arise. The IETF now wishes their own tools when they felt the need arise. The IETF now wishes
to support enhanced remote participation that is as seamless as to support enhanced remote participation that is as seamless as
possible, approaching the quality of direct physical attendance for possible, approaching the quality of direct physical attendance for
the various roles, including chair, presenter and simple attendee. the various roles, including chair, presenter and simple attendee.
Before deploying the new tools and services needed for this enhanced Before deploying the new tools and services needed for this enhanced
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 21, 2012. This Internet-Draft will expire on August 23, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. About This Document . . . . . . . . . . . . . . . . . . . 4 1.1. About This Document . . . . . . . . . . . . . . . . . . . 5
2. Scenarios Required to be Supported . . . . . . . . . . . . . . 6 2. Scenarios Required to be Supported . . . . . . . . . . . . . . 7
3. Interactions with Current RPS Tools Used by the IETF . . . . . 7 3. Interactions with Current RPS Tools Used by the IETF . . . . . 8
3.1. Technologies Currently Used at Regular IETF Meetings . . . 7 3.1. Technologies Currently Used at Regular IETF Meetings . . . 8
3.2. Locating the Meeting Information . . . . . . . . . . . . . 8 3.2. Locating the Meeting Information . . . . . . . . . . . . . 9
3.2.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Instant Messaging . . . . . . . . . . . . . . . . . . 9 3.2.2. Instant Messaging . . . . . . . . . . . . . . . . . . 10
3.2.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Remotely Speaking at the Mic . . . . . . . . . . . . . . . 9 3.3. Remote Participation at IETF Meetings . . . . . . . . . . 10
3.4. Chairs and Floor Control for Remote Attendees . . . . . . 11 3.3.1. Remotely Speaking at the Mic . . . . . . . . . . . . . 10
3.5. Remotely Presenting at Regular IETF Meetings . . . . . . . 12 3.3.2. Remotely Presenting . . . . . . . . . . . . . . . . . 13
3.6. Experiences with Remote Participation in Virtual 3.3.3. Floor Control . . . . . . . . . . . . . . . . . . . . 13
Interim Meetings . . . . . . . . . . . . . . . . . . . . . 13 3.4. Remote Participation at IETF Interim WG Meetings . . . . . 14
3.4.1. Face-to-Face Interim Meetings . . . . . . . . . . . . 14
3.4.2. Virtual Interim Meetings . . . . . . . . . . . . . . . 14
4. Requirements for Supporting Remote Participation in 4. Requirements for Supporting Remote Participation in
Face-to-Face Meetings . . . . . . . . . . . . . . . . . . . . 13 Regular IETF Meetings . . . . . . . . . . . . . . . . . . . . 15
4.1. Registration for Remote Participation . . . . . . . . . . 14 4.1. Registration for Remote Participation . . . . . . . . . . 17
4.2. Technologies . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. IM-to-Mic Relay of Comments from Remote
4.2.2. Video . . . . . . . . . . . . . . . . . . . . . . . . 16 Participants . . . . . . . . . . . . . . . . . . . . . 18
4.2.3. Instant Messaging . . . . . . . . . . . . . . . . . . 16 4.2.2. Audio from Remote Participants to the Room . . . . . . 19
4.2.4. Slide Presentations . . . . . . . . . . . . . . . . . 17 4.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5. Slide Distribution . . . . . . . . . . . . . . . . . . 18 4.3.1. Video from the Room to Remote Participants . . . . . . 21
4.2.6. Shared Document Editing . . . . . . . . . . . . . . . 18 4.3.2. Video from Remote Participants to the Room . . . . . . 22
4.3. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. Instant Messaging . . . . . . . . . . . . . . . . . . . . 22
4.3.1. Requirements for Remote Participation . . . . . . . . 19 4.5. Slide Presentations . . . . . . . . . . . . . . . . . . . 23
4.3.2. Floor Control for Chairs . . . . . . . . . . . . . . . 20 4.6. Slide Distribution . . . . . . . . . . . . . . . . . . . . 23
4.3.3. Archiving . . . . . . . . . . . . . . . . . . . . . . 21 4.7. Shared Document Editing . . . . . . . . . . . . . . . . . 24
4.3.4. Transcription . . . . . . . . . . . . . . . . . . . . 22 4.8. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.5. Polling . . . . . . . . . . . . . . . . . . . . . . . 22 4.9. Transcription . . . . . . . . . . . . . . . . . . . . . . 25
4.4. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 22 4.10. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 22 4.11. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 26
5. Requirements for Supporting All-Remote Meetings . . . . . . . 23 4.12. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 4.13. Additional Requirements for Remote Participation . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5. Requirements for Supporting Remote Participation in
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 27
9. Informative References . . . . . . . . . . . . . . . . . . . . 24 5.1. Requirements for Supporting Remote Participation in
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Face-to-Face Interim Meetings . . . . . . . . . . . . . . 28
5.2. Requirements for Supporting All-Remote Interim Meetings . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
9. Informative References . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
There are two types of participants at the three-times-a-year IETF There are two types of participants at the three-times-a-year IETF
meetings: the people who are physically at the meeting ("local meetings: the people who are physically at the meeting ("local
attendees") and people that are not physically at the meeting but are attendees") and people that are not physically at the meeting but are
following the meeting online ("remote attendees"). For more than a following the meeting online ("remote attendees"). For more than a
decade, the IETF has tried to make it easier for remote attendees to decade, the IETF has tried to make it easier for remote attendees to
participate in its face-to-face meetings in a meaningful fashion by participate in its face-to-face meetings in a meaningful fashion by
providing supported and experimental online services. providing supported and experimental online services.
At the same time, many IETF Working Groups (WGs) have started to have At the same time, many IETF Working Groups (WGs) have started to have
interim meetings that are scheduled between the regular IETF interim meetings that are scheduled between the regular IETF
meetings; these are described (briefly) in [RFC2418]. Some of these meetings; these are described (briefly) in [RFC2418]. Some of these
interim meetings are face-to-face meetings with remote attendees, interim meetings are face-to-face meetings with remote attendees,
while other interim meetings only take place over the Internet or on while other interim meetings only take place over the Internet or on
the phone; the latter type of meeting is often called a "virtual the phone; the latter type of meeting is often called a "virtual
interim". interim". There are also interim meetings that do not support remote
participation.
The IETF's current remote participation system ("RPS") for the The IETF's current remote participation system ("RPS") for the
official three-times-a-year meetings ("regular IETF meetings") official three-times-a-year meetings ("regular IETF meetings")
consists of a real-time audio stream carried over HTTP, textual consists of a real-time audio stream carried over HTTP, textual
instant messaging (IM) carried over Jabber, as well as experimental instant messaging (IM) carried over Jabber, as well as experimental
support for two integrated tools, WebEx and Meetecho. Some WGs support for two integrated tools, WebEx and Meetecho. Some WGs
employ ad-hoc tools such as Skype. For interim WG meetings, the IETF employ ad-hoc tools such as Skype. For interim WG meetings, the IETF
provides access to WebEx. The IETF's leadership regularly uses provides access to WebEx. The IETF's leadership regularly uses
telephone, Jabber, and WebEx for the many meetings that happen telephone, Jabber, and WebEx for the many meetings that happen
between the IETF meetings. between the IETF meetings.
skipping to change at page 4, line 28 skipping to change at page 5, line 30
document might augment and/or replace the current set of IETF RPS document might augment and/or replace the current set of IETF RPS
tools. The intention is for the experience of remote attendees to tools. The intention is for the experience of remote attendees to
rival those of local attendees. rival those of local attendees.
After the tools that meet the requirements in this document are After the tools that meet the requirements in this document are
deployed, there will probably be a change in the participation in deployed, there will probably be a change in the participation in
regular IETF meetings. regular IETF meetings.
o Some people who would make an effort to come to a particular IETF o Some people who would make an effort to come to a particular IETF
meeting might be more likely to attend remotely. Such a change meeting might be more likely to attend remotely. Such a change
will reduce the number of local participants, which will both will reduce the number of local attendees, which will both reduce
reduce the amount that the IETF makes from registration fees and the amount that the IETF makes from registration fees and makes
makes the informal gatherings during the IETF meeting less the informal gatherings during the IETF meeting less valuable
valuable because of the reduced networking effects. because of the reduced networking effects.
o People who are active on WG mailing lists but not in the regular o People who are active on WG mailing lists but not in the regular
meetings are more likely to participate in the meetings remotely. meetings are more likely to participate in the meetings remotely.
Such a change might cause more effective meetings for WGs that Such a change might cause more effective meetings for WGs that are
currently have little energy because more people will participate. lagging in energy because more people will participate. WG
WG meetings that already have lots of participants will probably meetings that already have lots of participants will probably
become busier. Presentations on documents where none of the become busier. Presentations on documents where none of the
authors come to regular IETF meetings will be much more likely to authors come to regular IETF meetings will be much more likely to
be given by the authors instead of by their proxies. be given by the authors instead of by their proxies.
o If the tools make regular IETF meetings and interim meetings much o If the tools make regular IETF meetings and interim meetings much
more effective, the IETF might be able to reduce the number of more effective, the IETF might be able to reduce the number of
regular meetings each year from three to two. This would regular meetings each year from three to two. This would
significantly reduce the impact of travel on regular IETF significantly reduce the impact of travel on regular IETF
participants and make meeting planning much easier, but would participants and make meeting planning much easier, but could
significantly reduce the amount of income for the IETF and also significantly change the finances for the IETF and also reduce the
reduce the amount of side-meeting value per year for participants. amount of side-meeting value per year for participants.
Note that some of the requirements in this document for particular Note that some of the requirements in this document for particular
functionality may not be desired by all WG chairs. The tools functionality may not be desired by all WG chairs. The tools
proposed will not force a particular WG to use all the features proposed will not force a particular WG to use all the features
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
01-00**". In the IETF, there is an active (and never-ending) debate 02-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
skipping to change at page 7, line 45 skipping to change at page 8, line 45
origination in the IETF meeting venue and the users' computer. At origination in the IETF meeting venue and the users' computer. At
recent meetings, delays of around 30 seconds have been recorded, with recent meetings, delays of around 30 seconds have been recorded, with
minimum delays typically being five seconds. This delay is caused by minimum delays typically being five seconds. This delay is caused by
buffering at the hop-by-hop ISPs and in the remote attendee's buffering at the hop-by-hop ISPs and in the remote attendee's
computer. At recent IETF meetings, remote attendance is almost computer. At recent IETF meetings, remote attendance is almost
always less than 10% of local attendance, and is often less than 5%. always less than 10% of local attendance, and is often less than 5%.
(There are more remote attendees when the IETF meeting is in the (There are more remote attendees when the IETF meeting is in the
U.S.) Each stream is represented by an MP3 playlist (sometimes called U.S.) Each stream is represented by an MP3 playlist (sometimes called
an "m3u file"). an "m3u file").
The IETF long ago standardized on Jabber / XMPP ([RFC3920], The IETF long ago standardized on Jabber / XMPP ([RFC6120],
[RFC3921], and others) for instant messaging used within the IETF. [RFC6121], and others) for instant messaging used within the IETF.
Jabber rooms (formally called "multi-user conferences" or "MUCs") Jabber rooms (formally called "multi-user conferences" or "MUCs")
exist for every WG, and those rooms are live all the time, not just exist for every WG, and those rooms are live all the time, not just
during regular IETF meetings. There are also stable Jabber rooms for during regular IETF meetings. There are also stable Jabber rooms for
the plenaries and certain other activities. BoFs are usually the plenaries and certain other activities. BoFs are usually
assigned Jabber rooms before a regular meeting. assigned Jabber rooms before a regular meeting.
Presentation slides normally are stored either as PDFs or in one of Presentation slides normally are stored either as PDFs or in one of
Microsoft's formats for PowerPoint. They are projected on a local Microsoft's formats for PowerPoint. They are projected on a local
screen from someone's laptop computer. screen from someone's laptop computer.
skipping to change at page 9, line 15 skipping to change at page 10, line 15
changes happen just as a WG meeting is starting, making it nearly changes happen just as a WG meeting is starting, making it nearly
impossible for a remote attendee to know about the change in streams. impossible for a remote attendee to know about the change in streams.
3.2.2. Instant Messaging 3.2.2. Instant Messaging
The Jabber rooms used by WGs and BoFs do not change between IETF The Jabber rooms used by WGs and BoFs do not change between IETF
meetings, so finding the right Jabber room is relatively easy. Some meetings, so finding the right Jabber room is relatively easy. Some
Jabber clients have odd interfaces for joining Jabber rooms, and this Jabber clients have odd interfaces for joining Jabber rooms, and this
can cause some problems; even though participants can test their can cause some problems; even though participants can test their
Jabber clients before a meeting, there still seems to be some who Jabber clients before a meeting, there still seems to be some who
need help just before a WG meeting. need help just before a WG meeting. There are sometimes problems
with people joining Jabber rooms; in these cases, the participant
needs to find someone already in the Jabber room to invite them to
the discussion.
3.2.3. Slides 3.2.3. Slides
Slides are available from the meeting materials page. Many, but Slides are available from the meeting materials page. Many, but
certainly not all, local and remote attendees know how to find the certainly not all, local and remote attendees know how to find the
meeting materials page. meeting materials page.
It has become fairly common for presenters to not have their It has become fairly common for presenters to not have their
presentations available for distribution until just before the WG presentations available for distribution until just before the WG
meeting. Because materials are uploaded by the WG chairs, this often meeting. Because materials are uploaded by the WG chairs, this often
causes the beginning of WG meetings to be a dance involving causes the beginning of WG meetings to be a dance involving
presenters giving the chairs their slides, followed by chairs presenters giving the chairs their slides, followed by chairs
uploading the slides to the IETF site, followed by the chairs saying uploading the slides to the IETF site, followed by the chairs saying
"the slides are there now". "the slides are there now".
3.3. Remotely Speaking at the Mic 3.3. Remote Participation at IETF Meetings
3.3.1. Remotely Speaking at the Mic
In order for a remote attendee to speak at the mic, a local attendee In order for a remote attendee to speak at the mic, a local attendee
must say it for them. In most WG and BoF meetings, this is done by must say it for them. In most WG and BoF meetings, this is done by
the remote attendee typing into the Jabber room for the meeting, and the remote attendee typing into the Jabber room for the meeting, and
some local attendee going to the mic and repeating what was typed some local attendee going to the mic and repeating what was typed
into the Jabber room. into the Jabber room. Remote attendees often precede what they want
said at the mic with the string "mic:" to differentiate that from the
rest of the discussion in the Jabber room.
This method of participation often works adequately, but there are This method of participation often works adequately, but there are
many places where it fails. The following is a compendium of stories many places where it fails. The following is a compendium of stories
from recent IETF meetings where remotely speaking at the mic didn't from recent IETF meetings and interim face-to-face meetings where
work as well as it could have. The participants are Chris and Carl remotely speaking at the mic didn't work as well as it could have.
(WG co-chairs), Sam (volunteer Jabber scribe), Rachel and Robert The participants are Chris and Carl (WG co-chairs), Sam (volunteer
(remote attendees), Pete (presenter), and Len and Lee (local Jabber scribe), Rachel and Robert (remote attendees), Pete
attendees). (presenter), and Len and Lee (local attendees).
o Robert cannot understand what Pete is saying about slide 5, but o Robert cannot understand what Pete is saying about slide 5, but
Sam doesn't get Pete's attention until Pete is already on slide 7 Sam doesn't get Pete's attention until Pete is already on slide 7
and Pete doesn't want to go back. and Pete doesn't want to go back.
o Rachel wants to say something, but Sam's Jabber client has crashed o Rachel wants to say something, but Sam's Jabber client has crashed
and no one else in the Jabber room knows why Sam isn't going to and no one else in the Jabber room knows why Sam isn't going to
the mic. the mic.
o Robert wants to say something, but Sam is already at the mic o Robert wants to say something, but Sam is already at the mic
skipping to change at page 10, line 24 skipping to change at page 11, line 29
Robert said. Unless Sam reads the message as he is walking back Robert said. Unless Sam reads the message as he is walking back
to his seat, Rachel doesn't get to speak. to his seat, Rachel doesn't get to speak.
o Robert wants to say something at the mic, but Sam is having an o Robert wants to say something at the mic, but Sam is having an
important side discussion with the AD. important side discussion with the AD.
o Sam is also the minutes taker, and is too busy at the moment o Sam is also the minutes taker, and is too busy at the moment
catching up with the lively debate at the mic to relay a question catching up with the lively debate at the mic to relay a question
from Rachel. from Rachel.
o Robert cannot understand what Pete is saying about slide 5, but
Sam doesn't get Pete's attention until Pete is already on slide 7
and Pete doesn't want to go back.
o Chris thought Carl was watching the Jabber room, but Carl was o Chris thought Carl was watching the Jabber room, but Carl was
reading the draft that is being discussed. reading the draft that is being discussed.
o Chris and Carl start the meeting by asking for volunteers to take o Chris and Carl start the meeting by asking for volunteers to take
minutes and be Jabber scribe. They couldn't find a Jabber scribe, minutes and be Jabber scribe. They couldn't find a Jabber scribe,
and it took a lot of begging to get someone to take minutes, so and it took a lot of begging to get someone to take minutes, so
they figured that was the best they could do. they figured that was the best they could do.
o Sam is also a presenter, and Robert has a question about Sam's o Sam is also a presenter, and Robert has a question about Sam's
presentation, but Sam is obviously not looking at the Jabber room presentation, but Sam is obviously not looking at the Jabber room
skipping to change at page 11, line 44 skipping to change at page 12, line 46
doesn't go to the mic. The chairs try to repeat what the AD says, doesn't go to the mic. The chairs try to repeat what the AD says,
get it only approximately right, but the remote attendees do not get it only approximately right, but the remote attendees do not
hear what really was said and therefore cannot comment hear what really was said and therefore cannot comment
effectively. effectively.
o Sam only volunteered to be scribe because no one else would do it, o Sam only volunteered to be scribe because no one else would do it,
and isn't sitting close to the mic, and gets tired of getting up and isn't sitting close to the mic, and gets tired of getting up
and down all the time, and doesn't really agree with Robert on a and down all the time, and doesn't really agree with Robert on a
particular issue, so Sam doesn't relay a request from Robert. particular issue, so Sam doesn't relay a request from Robert.
o [[[ TODO: More here, of course. ]]] o Rachel cannot join the Jabber room due to a client or server
software issue. She finally finds someone else on Jabber who is
also in the meeting, and gets them to invite her into the room.
3.4. Chairs and Floor Control for Remote Attendees 3.3.2. Remotely Presenting
Although the previous section may seem like it is a bit harsh on WG Some WGs have experimented with remote presentations at regular IETF
chairs, the current tools do not give them the kind of control over meetings, with quite mixed results. For some, it works fine: the
remote attendees that they have over local attendees. The chairs can remote presenter speaks, the chair moves the slides forward, and
tell what is happening at the mics, but have much less view into what questions can be heard easily. For others, it is a mess: the local
is happening on Jabber, even if they are watching the Jabber room. attendees can't hear the presenter very well, the presenter can't
hear questions or there is a long delay, and it was not clear when
the presenter was waiting for input or there was a lag in the sound.
At a recent meeting that had a remote presenter, a WG had a video
camera set up at the chairs' desk pointed towards the audience so
that the presenter could see who was at the mic; this was considered
to be a great help and a lot friendlier because the presenter could
address the people at the mic by name. They also had the presenter's
head projected on the screen in the room, which led to a lot of jokes
and discussion of whether seeing the remote presenter caused people
to pay more attention.
Remote presenters have commented how difficult it is to set up their
systems, particularly because they are not sure whether their setup
is working until the moment they are supposed to be presenting. Even
then, the first few minutes of the presentation has a feeling of "is
this really working?".
[[[ TODO: More discussion about experiences with remote presenters.
Include more discussion of where it went well. ]]]
3.3.3. Floor Control
Although Section 3.3.1 may seem like it is a bit harsh on WG chairs,
the current tools do not give them the kind of control over remote
attendees that they have over local attendees. The chairs can tell
what is happening at the mics, but have much less view into what is
happening on Jabber, even if they are watching the Jabber room.
Without as much view, they cannot assist the flow of the conversation Without as much view, they cannot assist the flow of the conversation
as well. as well.
o Carl sees that the Jabber room has an active and useful back- o Carl sees that the Jabber room has an active and useful back-
channel discussion during Pete's provocative presentation. Pete channel discussion during Pete's provocative presentation. Pete
finishes and asks for questions. Lee and Len rush to the mic finishes and asks for questions. Lee and Len rush to the mic
line, and it takes Robert a few seconds to get his question into line, and it takes Robert a few seconds to get his question into
the Jabber room and for Sam to go to the mic. Carl tries to the Jabber room and for Sam to go to the mic. Carl tries to
prioritize Sam forward in the line, but Len gets upset when he prioritize Sam forward in the line, but Len gets upset when he
does. does.
skipping to change at page 12, line 34 skipping to change at page 14, line 20
whether Robert even heard Pete's response. whether Robert even heard Pete's response.
o In a virtual interim where remote attendees all participate by o In a virtual interim where remote attendees all participate by
voice, someone can be heard typing / eating / talking loudly to voice, someone can be heard typing / eating / talking loudly to
someone else. Carl and Chris try to get that person's attention someone else. Carl and Chris try to get that person's attention
over the audio and Jabber, but to no avail. The tool being used over the audio and Jabber, but to no avail. The tool being used
does not have the ability to mute individual participants, so the does not have the ability to mute individual participants, so the
meeting is disrupted until that person finally realizes that he or meeting is disrupted until that person finally realizes that he or
she is not muted. she is not muted.
o [[[ TODO: More here, of course. ]]] 3.4. Remote Participation at IETF Interim WG Meetings
3.5. Remotely Presenting at Regular IETF Meetings
Some WGs have experimented with remote presentations in recent years
with quite mixed results. For some, it works fine: the remote
presenter speaks, the chair moves the slides forward, and questions
can be heard easily. For others, it is a mess: the local attendees
can't hear the presenter very well, the presenter can't hear
questions or there is a long delay, and it was not clear when the
presenter was waiting for input or there was a lag in the sound.
At a recent meeting that had a remote presenter, a WG had a video 3.4.1. Face-to-Face Interim Meetings
camera set up at the chairs' desk pointed towards the audience so
that the presenter could see who was at the mic; this was considered
to be a great help and a lot friendlier because the presenter could
address the people at the mic by name. They also had the presenter's
head projected on the screen in the room, which led to a lot of jokes
and discussion of whether seeing the remote presenter caused people
to pay more attention.
Remote presenters have commented how difficult it is to set up their Many interim meetings are held face-to-face in conference rooms
systems, particularly because they are not sure whether their setup supplied by companies active in the IETF (and, much less often, in
is working until the moment they are supposed to be presenting. Even commercial conference facilities such as hotels). Because these
then, the first few minutes of the presentation has a feeling of "is facilities are not controlled by the IETF Secretariat, the ability to
this really working?". include remote attendees varies widely. Some facilities can
distribute the in-room audio over the Internet just fine, while
others have no or limited abilities to do so.
[[[ TODO: More discussion about experiences with remote presenters. For example, a recent face-to-face interim meeting was supposed to be
Include more discussion of where it went well. ]]] open to remote attendees through WebEx, but the sound coming from the
room was too soft to hear reliably. Even if a face-to-face interim
meeting has good facilities for audio and slide presenting, it will
probably have similar to regular IETF meetings.
3.6. Experiences with Remote Participation in Virtual Interim Meetings 3.4.2. Virtual Interim Meetings
Because few WGs have virtual interim meetings, there is less Because few WGs have virtual interim meetings (those with no face-to-
experience with the tools that are commonly used for them. The IETF face attendees), there is less experience with the tools that are
has had free use of WebEx for a few years, and some WGs have used commonly used for them. The IETF has had free use of WebEx for a few
different tools for audio participation. For example, some virtual years, and some WGs have used different tools for audio
interims are held using Skype, others with TeamSpeak, and so on. participation. For example, some virtual interims are held using
Skype, others with TeamSpeak, and so on.
So far, the experience with virtual interim meetings has been So far, the experience with virtual interim meetings has been
reasonably good, and some people say that it is better than for reasonably good, and some people say that it is better than for
remote attendees at regular IETF meetings because everyone has the remote attendees at regular IETF meetings and face-to-face interims
same problems with getting the group's attention. because everyone has the same problems with getting the group's
attention. Also, there are no problems getting the in-room audio
into the RPS because all attendees are using their own computers for
speaking to the group.
One of the often-debated aspects of virtual interim meetings is what One of the often-debated aspects of virtual interim meetings is what
time to have them in order to make them available to all time to have them in order to make them available to all
participants. That topic is (thankfully) not covered in this participants. Such scheduling of virtual interim meetings is out of
document. scope for this document. However, it is noted that because many
participants will be attending at different times of day and night,
no assumption can be made that participants will be at an "office".
This debate also affects face-to-face interim meetings because the
meeting hosts normally will schedule the meeting during business
hours at the host company, but that might be terribly inconvenient
for some WG members.
[[[ TODO: More discussion about experiences with virtual interims. [[[ TODO: More discussion about experiences with virtual interims.
Focus on differences between the all-in-one systems like WebEx and Focus on differences between the all-in-one systems like WebEx and
the cobble-together systems where there is an audio feed with no the cobble-together systems where there is an audio feed with no
floor control plus pre-distributed slideware. ]]] floor control plus pre-distributed slideware. ]]]
4. Requirements for Supporting Remote Participation in Face-to-Face 4. Requirements for Supporting Remote Participation in Regular IETF
Meetings Meetings
This section covers the functional specification for effective remote This section covers the functional specification for effective remote
participation in meetings where some members are in a face-to-face participation in meetings where some members are in regular IETF
meeting, such as the regular IETF meetings and interim WG meetings face-to-face meetings. Some of the requirements in this section
that are held in a meeting room. 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 significant physical presence.
There is an assumption in this section that the meeting chairs will There is an assumption in this section that the meeting chairs will
continue to control the flow of the discussion. That is, if a continue to control the flow of the discussion. That is, if a
presenter is speaking and a remote attendee wants to ask a question, presenter is speaking and a remote attendee wants to ask a question,
the request to do so goes to the chair, not to the presenter. the request to do so goes to the chair, not to the presenter. This
is covered in more detail in Section 4.2.2.1.
**Requirement 01-01**: The specifications SHOULD rely upon IETF and **Requirement 02-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 01-02**: All tools in the RPS SHOULD be able to be run **Requirement 02-02**: All tools in the RPS SHOULD be able to be run
on the widest possible array of computers. This means that they need on the widest possible array of computers. The tool may be a stand-
to be able to be run as an application, from any modern web browser, alone application, from any modern web browser, or from the command
or from the command line of all of (at least) MacOS version 10.6 or line, but needs to be available on all of (at least) MacOS version
later, Windows 7 or later, and any common Linux distribution produced 10.6 or later, Windows 7 or later, and any common Linux distribution
in 2010 or later. [[[ TODO: Do we need to include IOS and Android produced in 2010 or later. This also means that the tools MUST NOT
platforms in that list? ]]] rely on Adobe Flash to work correctly. [[[ TODO: Do we need to
include IOS and Android platforms in that list? ]]]
A common complaint with the current RPS is that the streaming audio **Requirement 02-03**: Audio, video, instant messaging, and slide
can take more than 10 seconds (and sometimes as much as 30 seconds) streams going to and from remote attendees SHOULD be delivered in as
to reach the remote attendee. This causes many of the problems close to real-time as is practically possible. A common complaint
listed in Section 3.3. **Requirement 01-03**: Audio, video, instant with the current RPS is that the streaming audio can take more than
messaging, and slide streams going to and from remote attendees 10 seconds (and sometimes as much as 30 seconds) to reach the remote
SHOULD be delivered in as close to real-time as is practically attendee. This causes many of the problems listed in Section 3.3.1.
possible.
[[[ 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 01-04**: Audible echo in the audio stream MUST be **Requirement 02-04**: The outgoing audio, video, and slide streams
MUST have the same delays so the remote participant does not get
confused during slide presentations.
**Requirement 02-05**: All streaming information from the RPS MUST be
usable over slow Internet connections. Many remote attendees will be
in places with limited bandwidth. [[[ TODO: We need to define "slow"
here, or drop the requirement.]]]
**Requirement 02-06**: All proposed tools MUST detail the bandwidth
required for each participant for various levels of participation
(audio-only, audio and video, and so on).
[[[ TODO: Is there a requirement for PSTN for audio-only? ]]]
**Requirement 02-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
the tools for their session are working at least 30 minutes before
the meeting begins (unless, of course, there is already another
meeting occurring in the room during that time).
**Requirement 02-09**: There MUST be written operational
documentation for each RPS tool that is accessible at all times.
This will help reduce problems where a WG chair is having problems
during a meeting that is affecting the meeting as a whole.
**Requirement 02-10**: There SHOULD be training materials for WG
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 remote attendees are or There has been periodic discussion of whether or not remote attendees
are not bound by the "note well" text that local attendees are bound are bound by the "Note Well" text that local attendees are bound to.
to. By requiring registration before participating, remote attendees The core question is which local and remote attendees are
can be better bound to that text. "contributors" based on the definitions in [BCP78]. By requiring
registration before participating, remote attendees can be better
alerted to, and thus hopefully bound to, the requirements of
contributors.
The cost for remote attendees to register, if any, is not covered in 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 01-05**: All remote attendees MUST register with the **Requirement 02-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
in that an unregistered person would not be able to use the IM
system. [[[ TODO: Should this be split into "unregistered people can
listen and read, but not contribute"? ]]]
**Requirement 01-06**: The RPS MUST have a system where a remote **Requirement 02-12**: 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 01-07**: A remote attendee who doesn't want to **Requirement 02-13**: A remote attendee may register a nickname that
identified MUST be able to use an anonymized name when appearing in will be shown to other attendees during the meeting. A remote
video and instant messaging. [[[TODO: Is the anonymity appropriate attendee must register with a "verified" name with the IETF
in light of the "note well" and floor control requirements? ]]] Secretariat. The nickname will appear in video and instant
messaging. [[[TODO: Is this anonymity appropriate in light of the
"note well" and floor control requirements? ]]]
**Requirement 01-08**: The RPS MUST gracefully handle multiple **Requirement 02-14**: The RPS tools (particularly the registration
attendees who have the same name. tool) MUST gracefully handle multiple attendees who have the same
name.
4.2. Technologies **Requirement 02-15**: To support the "blue sheet" functionality for
remote attendees, the registration tool SHOULD allow a registered
user to indicate which sessions he or she attended. This notations
SHOULD be allowed for all WG meetings throughout the meeting period.
The registration system SHOULD remind all registered remote attendees
at the end of the week to update their notations.
4.2.1. Audio 4.2. Audio
Audio from face-to-face meetings travels in two directions: from the
room to remote attendees, and from remote attendees to the room.
A few requirements come from the IETF's current use of audio in 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
said by local attendees and chairs at any mic in the meeting.
Comments on early drafts of this document indicated that the latter
may not really be a requirement for all participants if IM-to-mic is
made predictable. The two options are split below to make the
discussion clearer. Note that even if the consensus is towards IM-
to-mic, remote-to-room might still be required to enable remote
presenters; in this case, there would probably be little need for
floor control. The requirements for audio are expected to be
important discussion points in future versions of this document.
[[[ TODO: Should the ability to dial into a meeting stream via POTS
be a requirement? ]]]
4.2.1. IM-to-Mic Relay of Comments from Remote Participants
As described in Section 3.3.1, the current tools support an informal
method for remote attendees to speak at the mic: in the Jabber room,
they enter "mic:" before their comment and hope that the designated
scribe or someone else goes to the mic to relay the comment. This
method works, but has significant flaws described in that section.
**Requirement 02-17**: Relay of messages from IM to the mic MUST
happen as quickly as if the remote attendee was local.
**Requirement 02-18**: The person relaying from IM to the mic must be
available throughout the WG meeting. This could be facilitated by
hiring people to attend meetings for the specific purpose of being
IM-to-mic scribes.
**Requirement 02-19**: If multiple remote attendees want to comment
at the same time, the person relaying from IM to the mic MUST be able
to relay for all of them.
Note: during the development of this document, there have been many
suggestions for how WG chairs can better manage the IM-to-mic
relaying (for example, with planned pauses, better tracking of the IM
room, and so on). Some of those suggestions might turn into
requirements to be included in this document, but so far most of them
seem to be really about improving WG chairs, not the RPS tools.
4.2.2. Audio from Remote Participants to the Room
Note that the requirements here assume a very large change in the way 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 01-09**: Remote attendees MUST be able to hear what is **Requirement 02-20**: Remote attendees MUST be able to speak
said by local attendees and chairs at any mic in the meeting.
**Requirement 01-10**: Remote attendees MUST be able to speak
directly to a meeting without going through a local attendee, and directly to a meeting without going through a local attendee, and
have their speaking be heard by local attendees. (Note that the have their speaking be heard by local attendees. (Note that the
ability to speak is controlled by the chair; see Section 4.3.2.) ability to speak is controlled by the chair; see Section 4.2.2.1.)
**Requirement 01-11**: Local attendees MUST be able to determine **Requirement 02-21**: Local attendees MUST be able to determine
which remote attendee is speaking, unless the remote attendee is which remote attendee is speaking. If the remote attendee is using a
using an anonymized display name (see Requirement 01-07). nickname (see Requirement 02-13), that nickname can be used by the
remote speaker.
**Requirement 01-12**: The RPS MUST give a remote attendee who is **Requirement 02-22**: The floor control portion of the RPS MUST give
allowed to speak a clear signal when they should and should not a remote attendee who is allowed to speak a clear signal when they
speak. should and should not speak.
IETF meetings happen in venues such as hotels and conference centers, **Requirement 02-23**: The audio system used by the RPS MUST be able
most of which have their own audio setups. The IETF Secretariat to integrate with systems commonly used in the venues used for IETF
contracts with those venues for the use of some or all of their audio meetings. IETF meetings happen in venues such as hotels and
system. **Requirement 01-13**: The audio system used by the RPS MUST conference centers, most of which have their own audio setups. The
be able to integrate with systems commonly used in the venues used IETF Secretariat contracts with those venues for the use of some or
for IETF meetings. all of their audio system. Without such integration, audio from
remote attendees might not be reliably heard by local participants.
4.2.2. Video **Requirement 02-24**: When a remote attendee connects to the audio
stream to the room, their mic SHOULD start off muted. This will
prevent problems such as those common with WebEx where a remote
attendee doesn't realize that they can be heard.
**Requirement 02-25**: Remote participants MUST be able to unmute
themselves; unmuting MUST NOT require interaction from the chair.
4.2.2.1. Floor Control for Chairs for Audio from Remote Attendees
Newcomers to regular IETF meetings often expect the floor control in
WG meetings to be fairly straight-forward. By Tuesday, they might be
shaking their heads, wondering why some people cut into the mic
lines, why some people get up to the mics after the chair has closed
the line, why some people ignore presenters' requests to hold
questions to the end, and so on. Mixing remote attendees into this
social structure will be a daunting task, but one that has been dealt
with in many remote participation systems.
It is not yet clear how the set of remote attendees would be treated
for queueing. Some tools have each remote attendee being considered
separately, while others pool all remote attendees into one group.
This affects the chair knowing and being able to act on the order
that remote attendees ask to speak.
Note that, if the remote video to room requirements from
Section 4.3.2 need to be met, it is very likely that a related
requirement to those below is that "the audio and video floor
controls must be in the same tool".
**Requirement 02-26**: Remote attendees MUST have an easy and
standardized way of requesting the attention of the chair when the
remote attendee wants to speak. The remote attendee MUST also be
able to easily cancel an attention request. (Note that Requirement
02-69 implies that someone is watching the request queue, something
that does not happen consistently with the current tools.)
A remote attendee might want to indicate that they are asking a
question of the presenter, or answering a question that someone else
asked at the mic, or want to bring up a new topic. **Requirement
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
floor control tool, not in the instant messaging system.
**Requirement 02-29**: The chair MUST be able to see all requests
from remote attendees to speak at any time during the entire meeting
(not just during presentations) in the floor control system.
**Requirement 02-30**: 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 02-31**: The floor control system MUST allow a chair to
easily mute all remote attendees.
**Requirement 02-32**: The floor control system MUST allow a chair to
easily allow all remote attendees to speak without requesting
permission; that is, the chair MUST be able to easily turn on all
remote attendees mics at once.
It is common for a chair to leave the room, to have a side discussion
with an AD, or to become a presenter. They should be able to do so
without having to do a handoff of the floor control capability.
**Requirement 02-33**: The floor control system for the chair MUST be
able to be run by at least two users at the same time.
**Requirement 02-34**: The RPS MUST authenticate users who can use
the floor control system in a particular meeting using simple
passwords.
**Requirement 02-35**: The IETF Secretariat MUST be able to easily
set up the individuals allowed to use the floor control system for a
particular meeting and to change the settings at any time, including
during the meeting. [[[ TODO: Should those who are given floor
control be allowed to augment that list to meet changing needs
without going back to the Secretariat? ]]]
[[[ TODO: Is it possible to tell if a remote attendee who is speaking
loses network connectivity? If so, maybe this can be shown to the
chair. ]]]
**Requirement 02-36**: The chair SHOULD be able to monitor the sound
levels of the audio being delivered to remote attendees to be sure
that they can hear what is going on in the room.
4.3. Video
The RFP that preceded the current document, [RPS-RFP], discusses 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. ]]]
**Requirement 01-14**: Remote attendees MUST be able to see the 4.3.1. Video from the Room to Remote Participants
presenter at a meeting. **Requirement 01-15**: Remote attendees MUST
be able to see local attendees at any mic in the meeting.
**Requirement 01-16**: The RPS MUST have the capability of showing **Requirement 02-37**: Remote attendees MUST be able to see the
video of the remote attendee who is speaking over the audio to the presenter at a meeting.
local attendees. **Requirement 01-17**: A remote attendee who is
speaking MUST be able to choose what is shown to local attendees: **Requirement 02-38**: Remote attendees MUST be able to see local
video of them speaking, a still picture of their face, or just their attendees at any mic in the meeting.
name. **Requirement 01-18**: The RPS MUST give a remote attendee a
clear indication when their video image is being shown to the local
attendees.
[[[ TODO: Is there a requirement that IETF video integrate with the [[[ TODO: Is there a requirement that IETF video integrate with the
venue video, if any? ]]] venue video, if any? ]]]
4.2.3. Instant Messaging 4.3.2. Video from Remote Participants to the Room
Note that the requirements in this section probably only apply if
there is consensus that audio from remote participants to the room is
required. If so, there will probably also be requirements for video
floor control as well.
**Requirement 02-39**: The RPS MUST have the capability of showing
video of the remote attendee who is speaking over the audio to the
local attendees.
**Requirement 02-40**: A remote attendee who is speaking MUST be able
to choose what is shown to local attendees: video of them speaking, a
still picture of their face, or just their name.
**Requirement 02-41**: The RPS MUST give a remote attendee a clear
indication when their video image is being shown to the local
attendees.
[[[ TODO: The way to fulfill these might be that the IETF provide a
laptop for the chair that has the right tools on it, and that laptop
is the one connected to the projector. ]]]
4.4. Instant Messaging
Instant messaging (IM) is used both as a remote participation tool
and as a communication tool for local attendees at a regular meeting.
As noted earlier, while the current tool's Jabber room is a good way 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 01-19**: The instant messaging system MUST allow anyone **Requirement 02-42**: The IM system MUST allow anyone to see all
to see all messages in the WG's or BoF's room. **Requirement 01-20**: messages in the WG's or BoF's room. **Requirement 02-43**: The IM
The instant messaging system MUST allow any registered user (even system MUST allow any registered user (even those registered to use
those registered to use anonymous names) to post messages in the WG's anonymous names) to post messages in the WG's or BoF's room.
or BoF's room.
Someone coming into a meeting late requires context for which Someone coming into a meeting late requires context for which
messages in an instant messaging room are recent and which are old. messages in an instant messaging room are recent and which are old.
**Requirement 01-21**: The date and time that a message appears in a **Requirement 02-44**: The date and time that a message appears in an
room MUST be retained. Instant messaging clients MUST be able to IM stream MUST be retained. IM clients MUST be able to show an
show an indication of the date and time for all messages. indication of the date and time for all messages.
[[[ TODO: Should there be multiple rooms for a meeting? There were [[[ TODO: Should there be multiple rooms for a meeting? There were
many requests for a separate "speak into the mic" room, but that is many requests for a separate "speak into the mic" room, but that is
not needed if the requirements in Section 4.2.1 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? ]]]
4.2.4. Slide Presentations 4.5. Slide Presentations
Slides are presented in regular IETF meetings with projectors on a
screen at the front of the room from the video output of one or more
local attendees' computers. If slides are to be presented to remote
attendees, the slides being projecte need to also be sent as a stream
to the remote attendees.
In many current remote participation systems, slide presentations and 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 01-22**: The RPS MUST transmit the slide stream **Requirement 02-45**: The RPS MUST transmit the slide stream
separately from the camera stream. **Requirement 01-23**: The slide separately from the camera stream. **Requirement 02-46**: The slide
stream MUST represent the slides as they are projected in the room, 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 allowing the presenter to go back and forth, as well as to edit
slides in real time. slides in real time.
**Requirement 01-24**: It MUST be made clear to the remote attendees **Requirement 02-47**: 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.2.5. 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 01-25**: The RPS MUST be able to handle both PDF and **Requirement 02-48**: The RPS MUST be able to handle both PDF and
PowerPoint for distributed slides. [[[ TODO: Is there a requirement PowerPoint formats (".ppt" and ".pptx") for distributed slides. [[[
to support other formats? ]]] [[[ TODO: For the distributed slides, TODO: Is there a requirement to support other formats? ]]] [[[ TODO:
is there a requirement that animation in PowerPoint be supported, or For the distributed slides, is there a requirement that animation in
just static slides? ]]] PowerPoint be supported, or just static slides? ]]]
**Requirement 01-26**: The RPS MUST automatically convert PowerPoint **Requirement 02-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 01-27**: Presenters MUST be able to update their slides **Requirement 02-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 chairs. is allowed by the chairs.
**Requirement 01-28**: Chairs MUST be able to approve or disapprove **Requirement 02-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.
4.2.6. 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
meetings, shared document editing has been used for editing charters meetings, shared document editing has been used for editing charters
and for taking minutes of meetings. and for taking minutes of meetings.
**Requirement 01-29**: It MUST be easy to start a new shared document An RPS tool for shared document editing would be equally useful for
local and remote attendees watching the edits happen in real-time.
There is a good chance that this tool would be watched by local
attendees on their laptops instead of being projected on the screen
because of the small size of the the text. This, in turn, means that
local attendees who aren't using their laptops at the moment would
not be able to participate by watching.
**Requirement 02-52**: 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 01-30**: Shared real-time editing of text-only **Requirement 02-53**: 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 01-31**: Remote attendees MUST be able to be either the **Requirement 02-54**: Remote attendees MUST be able to be either the
writers or the readers of shared documents. writers or the readers of shared documents.
**Requirement 01-32**: Those with read access MUST be able to see the **Requirement 02-55**: 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 01-33**: It MUST be easy to change the permissions for **Requirement 02-56**: 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.3. Tools 4.8. Archiving
4.3.1. Requirements for Remote Participation Archived recordings of the events of the meetings are valuable for
remote attendees who are not able to hear everything in real time.
**Requirement 01-34**: Remote attendees MUST be able to easily find **Requirement 02-57**: The RPS MUST support storage and distribution
of recordings of the audio, video, and slide presentations for all
sessions after IETF meetings. **Requirement 02-58**: Transcripts of
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
of the recordings and instant messaging transcripts of a particular
WG or BoF session at a particular meeting.
**Requirement 02-61**: The RPS SHOULD support indexing of archived
audio and video for particular events in meetings such as when
speakers change.
**Requirement 02-62**: The RPS MUST support recording and storage of
recordings of the audio, video, and slide presentations of interim
meetings as well as regular IETF meetings.
4.9. Transcription
**Requirement 02-63**: Transmitting real-time transcription to remote
attendees MUST be supported. The lag in transmission MUST be less
than five seconds.
4.10. Polling
The common IETF method of assessing support is a straw poll,
sometimes managed by audible humming, sometimes by raising hands.
**Requirement 02-64**: A system for polling meeting participants,
including remote attendees at the same time, MUST be provided. It
MUST be easy to set up a simple poll, and it must be easy for all
participants to find the poll and participate. Note that this would
add a requirement that everyone in a meeting be using their computer
to participate in the poll. [[[ TODO: Should the RPS also provide a
tool that allows yes / no / abstain indications, which comes a lot
closer to "voting" than currently is common? ]]]
4.11. Plenaries
At recent IETF meetings, there has been very little input from remote
attendees even when there is a lot in the room, but that may be due
to the current setup, not lack of interest.
**Requirement 02-65**: Remote attendees SHOULD be able to make
comments at the mic approximately as well as if they were local
attendees. This means that either remote audio to the plenary room
speakers be available, or that IM-to-room relay be available.
[[[ TODO: Are there other requirements that are special to plenaries
that are not covered above? Are there requirements not listed above
that mostly come from plenaries that would also apply to very large
WGs? ]]]
4.12. Use by IETF Leadership
The requirements for bodies like the IESG and IAB to use the RPS
during regular IETF meetings are similar to those of most WGs. The
main difference is that they need a way to limit who can participate
remotely.
**Requirement 02-66**: The IETF Secretariat MUST be able to easily
limit remote access to meetings on a room-by-room basis.
**Requirement 02-67**: The IETF Secretariat must be able to limit
participants in restricted meetings using a simple authentication
mechanism.
Note that the IETF leadership will also heavily use the remote
participation tools between IETF meetings in a manner that is very
similar to virtual interim meetings.
4.13. Additional Requirements for Remote Participation
**Requirement 02-68**: 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 01-35**: A remote attendee who comes to a meeting late **Requirement 02-69**: 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 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 01-36**: There MUST be a constantly-running testing **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 01-37**: The testing service MUST run throughout the **Requirement 02-71**: 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 01-38**: The testing service SHOULD allow remote **Requirement 02-72**: 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 01-39**: Remote attendees SHOULD be able to easily **Requirement 02-73**: Remote attendees SHOULD be able to easily
contact the IETF Secretariat if they find problems with any of the contact the IETF Secretariat if they find problems with any of the
RPS tools, and to get fairly rapid response. **Requirement 01-40**: RPS tools, and to get fairly rapid response.
Similarly, local attendees SHOULD be able to easily contact the IETF
Secretariat if there are RPS problems in the meeting rooms.
Regular IETF meetings are more than just a group of WG meetings.
Remote attendees may want to participate in the other parts of a
regular meeting as well. **Requirement 01-41**: The RPS tools MUST be
available for AD-sponsored lunch meetings scheduled by the IETF
Secretariat.
At many IETF meetings, some local attendees act as remote attendees
in WG meetings that they are not sitting in, so they can attend two
WGs at once. **Requirement 01-42**: Any tools that are used by remote
attendees MUST also be available to local attendees as well.
Many remote attendees will be in places with limited bandwidth.
**Requirement 01-43**: All streaming information from the RPS MUST be
usable over slow Internet connections. [[[ TODO: We need to define
"slow" here, or drop the requirement.]]]
4.3.2. Floor Control for Chairs
Newcomers to regular IETF meetings often expect the floor control in
WG meetings to be fairly straight-forward. By Tuesday, they might be
shaking their heads, wondering why some people cut into the mic
lines, why some people get up to the mics after the chair has closed
the line, why some people ignore presenters' requests to hold
questions to the end, and so on. Mixing remote attendees into this
social structure will be a daunting task, but one that has been dealt
with in many remote participation systems.
It is not yet clear how the set of remote attendees would be treated
for queueing. Some tools have each remote attendee being considered
separately, while others pool all remote attendees into one group.
This affects the chair knowing and being able to act on the order
that remote attendees ask to speak.
**Requirement 01-44**: Remote attendees MUST have an easy and
standardized way of requesting the attention of the chair when the
remote attendee wants to speak. The remote attendee MUST also be
able to easily cancel an attention request. (Note that Requirement
01-35 implies that someone is watching the request queue, something
that does not happen consistently with the current tools.)
A remote attendee might want to indicate that they are asking a
question of the presenter, or answering a question that someone else
asked at the mic, or want to bring up a new topic. **Requirement
01-45**: The RPS MUST allow a remote attendee's request for attention
to include an optional short text string.
**Requirement 01-46**: Remote attendee's requests MUST be part of the
floor control tool, not in the instant messaging system.
**Requirement 01-47**: The chair MUST be able to see all requests
from remote attendees to speak at any time during the entire meeting
(not just during presentations) in the floor control system.
**Requirement 01-48**: 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 01-49**: The floor control system MUST allow a chair to
easily mute all remote attendees.
**Requirement 01-50**: The floor control system MUST allow a chair to
easily allow all remote attendees to speak without requesting
permission; that is, the chair MUST be able to easily turn on all
remote attendees mics at once.
It is common for a chair to leave the room, to have a side discussion
with an AD, or to become a presenter. They should be able to do so
without having to do a handoff of the floor control capability.
**Requirement 01-51**: The floor control system for the chair MUST be
able to be run by at least two users at the same time.
**Requirement 01-52**: The RPS MUST authenticate users who can use
the floor control system in a particular meeting using simple
passwords.
**Requirement 01-53**: The IETF Secretariat MUST be able to easily
set up the individuals allowed to use the floor control system for a
particular meeting and to change the settings at any time, including
during the meeting. [[[ TODO: Should those who are given floor
control be allowed to augment that list to meet changing needs
without going back to the Secretariat? ]]]
[[[ TODO: Is it possible to tell if a remote attendee who is speaking **Requirement 02-74**: Similarly, local attendees SHOULD be able to
loses network connectivity? If so, maybe this can be shown to the easily contact the IETF Secretariat if there are RPS problems in the
chair. ]]] meeting rooms.
**Requirement 01-54**: The chair SHOULD be able to monitor the sound **Requirement 02-75**: The RPS tools MUST be available for AD-
levels of the audio being delivered to remote attendees to be sure sponsored lunch meetings scheduled by the IETF Secretariat. Regular
that they can hear what is going on in the room. IETF meetings are more than just a group of WG meetings. Remote
attendees may want to participate in the other parts of a regular
meeting as well.
4.3.3. Archiving **Requirement 02-76**: Any tools that are used by remote attendees
MUST also be available to local attendees as well. At many IETF
meetings, some local attendees act as remote attendees in WG meetings
that they are not sitting in, so they can attend two WGs at once.
Archived recordings of the events of the meetings are valuable for 5. Requirements for Supporting Remote Participation in Interim Meetings
remote attendees who are not able to hear everything in real time.
**Requirement 01-55**: The RPS MUST support storage and distribution One of the goals of this document is to increase the effectiveness of
of recordings of the audio, video, and slide presentations for all interim meetings. Interim meetings are now uncommon, but might
sessions after IETF meetings. **Requirement 01-56**: Transcripts of become more common (and more effective) if the remote participation
the instant messaging for all meetings MUST be kept for distribution becomes more useful.
after IETF meetings. **Requirement 01-57**: The recordings and
transcripts SHOULD be made available during the meetings, within a
day of them being made.
**Requirement 01-58**: Users MUST be able to easily find the archives **Requirement 02-77**: The RPS SHOULD have a central location where
of the recordings and instant messaging transcripts of a particular the specifics about how remote participation is supported for every
WG or BoF session at a particular meeting. WG interim meeting. This will reduce the problems often seen where
messages about how to participate in an interim meeting get buried in
the WG mailing list.
**Requirement 01-59**: The RPS SHOULD support indexing of archived **Requirement 02-78**: There SHOULD be documentation and training for
audio and video for particular events in meetings such as when the RPS tools specifically targeted at WG chairs who will lead
speakers change. interim meetings.
4.3.4. Transcription [[[ TODO: Determine how much or how little the IETF Secretariat
should participate in setting up the RPS for interim meetings. The
IETF Secretariat currently offers some help to some WGs, but this
might become more formalized in the future. ]]]
**Requirement 01-60**: Transmitting real-time transcription to remote 5.1. Requirements for Supporting Remote Participation in Face-to-Face
attendees MUST be supported. The lag in transmission MUST be less Interim Meetings
than five seconds.
4.3.5. Polling Face-to-face interim meetings have many things in common with regular
IETF meetings, but there are also many significant differences. For
most WGs, fewer people attend interim meetings than IETF meetings,
although those who travel to a face-to-face interim meeting are often
the more active WG participants. There may be a larger demand for
remote participation because people have a harder time justifying
travel for a single WG meeting than for an IETF meeting, but there
may also be less demand because people tend to think of interim WG
meetings as less important than regular IETF meetings..
The common IETF method of assessing support is a straw poll, Typically, the IETF Secretariat does not control the rooms in which
sometimes managed by audible humming, sometimes by raising hands. face-to-face interims are held, so they have no control over whether
outgoing audio will be supported, or supported well enough to
guarantee that remote attendees can hear. [[[ TODO: Should the IETF
Secretariat be tasked with helping set up face-to-face interims? ]]]
**Requirement 01-61**: A system for polling meeting participants, **Requirement 02-79**: The RPS tools MUST be at least partially
including remote attendees at the same time, MUST be provided. It usable at face-to-face meetings other than regular IETF meetings.
MUST be easy to set up a simple poll, and it must be easy for all The number of the tools that might be available will be different for
participants to find the poll and participate. [[[ TODO: Should the different venues for the virtual interims, but at a minimum, the
RPS also provide a tool that allows yes / no / abstain indications, following MUST be supported for remote attendees:
which comes a lot closer to "voting" than currently is common? ]]]
4.4. Use by IETF Leadership o Room audio
The requirements for bodies like the IESG and IAB to use the RPS o Instant messaging
during regular IETF meetings are similar to those of most WGs. The
main difference is that they need a way to limit who can participate
remotely. **Requirement 01-62**: The IETF Secretariat MUST be able to
easily limit remote access to meetings on a room-by-room basis.
**Requirement 01-63**: The IETF Secretariat must be able to limit
participants in restricted meetings using a simple authentication
mechanism.
4.5. Plenaries o Slide distribution
At recent IETF meetings, there has been very little input from remote o Slide presentation
attendees even when there is a lot in the room, but that may be due o Shared document editing
to the current setup, not lack of interest.
[[[ TODO: Are there any requirements that are special to plenaries [[[ TODO: What are the requirements for registering? Interim
that are not covered above? Are there requirements not listed above meetings are generally considered to have a very different feeling
that mostly come from plenaries that would also apply to very large than regular IETF meetings; does this affect the idea of
WGs? ]]] registration? What if registration is cheap but not free? ]]]
5. Requirements for Supporting All-Remote Meetings 5.2. Requirements for Supporting All-Remote Interim Meetings
The requirements for meetings that are all remote (that is, with no The requirements for meetings that are all remote (that is, with no
local attendees) are mostly a subset of the requirements for remote local attendees) are mostly a subset of the requirements for remote
participation in a face-to-face meeting. This section highlights the participation in a regular IETF meetings and face-to-face interim
differences from Section 4. meeting. This section highlights the differences from Section 4 and
Section 5.1.
Video for all-remote meetings may be more important than for face-to- Video for all-remote meetings may be more important than for face-to-
face meetings. [[[ TODO: Determine if this is true and, if so, the face meetings in order to help the chair with floor control. [[[
additional requirements for all the remote attendees. ]]] TODO: Determine if this is true and, if so, the additional
requirements for all the remote attendees. ]]]
Nearly all current remote participation systems have some way for
changing slides to be presented to all remote attendees. [[[ TODO: Is
this a requirement for the IETF RPS? ]]]
Attendance at virtual interim meetings is supposed to be taken, but Attendance at virtual interim meetings is supposed to be taken, but
this is sometimes ignored. A system that is probably at least this is sometimes ignored. A system that is probably at least
somewhat different than that in Section 4.3.1 may be needed for somewhat different than that in Section 4.13 may be needed for
collecting attendance at virtual interim meetings. collecting attendance at virtual interim meetings. [[[ TODO: What are
the requirements for registering? Virtual interim meetings are
[[[ TODO: What are the requirements for registering? Virtual interim generally considered to have a very different feeling than regular
meetings are generally considered to have a very different feeling IETF meetings; does this affect the idea of registration? ]]]
than regular IETF meetings; does this affect the idea of
registration? ]]]
[[[ TODO: Are there different floor control issues for all-remote [[[ TODO: Are there different floor control issues for all-remote
meetings? ]]] meetings? ]]]
6. IANA Considerations 6. IANA Considerations
None. [[ ...and thus this section can be removed before publication None. [[ ...and thus this section can be removed before publication
as an RFC... ]] as an RFC... ]]
7. Security Considerations 7. Security Considerations
skipping to change at page 24, line 25 skipping to change at page 30, line 24
Many of the ideas in this document were contributed by members of the Many of the ideas in this document were contributed by members of the
IETF community based on their experiences during recent IETF IETF community based on their experiences during recent IETF
meetings. There are also many contributions from people on the meetings. There are also many contributions from people on the
vmeet@ietf.org mailing list as well as WG chairs. vmeet@ietf.org mailing list as well as WG chairs.
Some of the text in this document originated in the request for Some of the text in this document originated in the request for
proposals that was issued by the IAOC that led to this document. proposals that was issued by the IAOC that led to this document.
9. Informative References 9. Informative References
[BCP78] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and [RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998. Procedures", BCP 25, RFC 2418, September 1998.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", Protocol (XMPP): Instant Messaging and Presence",
RFC 3921, October 2004. RFC 6121, March 2011.
[RPS-RFP] IAOC, "Request for Proposals for Requirements Development [RPS-RFP] IAOC, "Request for Proposals for Requirements Development
for Remote Participation Services", 2011, <http:// for Remote Participation Services", 2011, <http://
iaoc.ietf.org/documents/ iaoc.ietf.org/documents/
RPS-Specifications-RFP-2011-10-19.pdf>. RPS-Specifications-RFP-2011-10-19.pdf>.
Author's Address Author's Address
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
 End of changes. 105 change blocks. 
372 lines changed or deleted 619 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/