Network Working Group P. Hoffman Internet-Draft VPN Consortium Intended status: Informational October 15, 2012 Expires: April 18, 2013 Requirements for Remote Participation Services for the IETF draft-ietf-genarea-rps-reqs-08 Abstract The IETF has provided some tools for remote participation in its activities for many years, and some IETF participants have also used their own tools when they felt the need arise. The IETF now wishes to support enhanced remote participation that is as seamless as possible, improving the experience for the remote attendee at the IETF regular meetings and interim meetings without degrading the experience for the people that are physically present. Before deploying the new tools and services needed for this enhanced remote participation, the requirements for such tools and services, and the impacts they will make on the current procedures and infrastructure, must be defined. This document is meant to be that definition. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Hoffman Expires April 18, 2013 [Page 1] Internet-Draft Remote Participation Reqs October 2012 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hoffman Expires April 18, 2013 [Page 2] Internet-Draft Remote Participation Reqs October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals for an Improved RPS . . . . . . . . . . . . . . . . 4 1.2. About This Document . . . . . . . . . . . . . . . . . . . 5 2. Requirements for Supporting Remote Participation in Regular IETF Meetings . . . . . . . . . . . . . . . . . . . . 7 2.1. Registration for Remote Participation . . . . . . . . . . 8 2.2. Instant Messaging . . . . . . . . . . . . . . . . . . . . 9 2.3. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Audio to Remote Attendees . . . . . . . . . . . . . . 10 2.3.2. IM-to-Mic Relay of Comments from Remote Attendees . . 10 2.3.3. Audio for Presentations from Remote Attendees . . . . 11 2.3.4. Audio from Remote Attendees to the Room for Comments . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.1. Video from the Room to Remote Attendees . . . . . . . 13 2.4.2. Video from Remote Attendees to the Room . . . . . . . 13 2.5. Slide Presentations and Distribution . . . . . . . . . . . 14 2.6. Shared Text Document Editing . . . . . . . . . . . . . . . 15 2.7. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 16 2.8. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.9. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 17 2.10. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 17 2.11. Preparation . . . . . . . . . . . . . . . . . . . . . . . 17 2.11.1. Preparation for WG Chairs . . . . . . . . . . . . . . 18 2.11.2. Preparation for Remote Attendees . . . . . . . . . . . 18 3. Requirements for Supporting Remote Participation in Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. Informative References . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Background on IETF Remote Participation . . . . . . . 21 A.1. How the IETF Meets . . . . . . . . . . . . . . . . . . . . 22 A.2. Technologies Currently Used at Regular IETF Meetings . . . 23 A.3. Locating the Meeting Information . . . . . . . . . . . . . 24 A.3.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 24 A.3.2. Instant Messaging . . . . . . . . . . . . . . . . . . 25 A.3.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 25 A.4. Remote Participation at IETF Meetings . . . . . . . . . . 25 A.4.1. Remotely Speaking at the Mic . . . . . . . . . . . . . 25 A.4.2. Remotely Presenting . . . . . . . . . . . . . . . . . 28 A.4.3. Floor Control . . . . . . . . . . . . . . . . . . . . 29 A.5. Remote Participation at IETF Interim WG Meetings . . . . . 30 A.5.1. Face-to-Face Interim Meetings . . . . . . . . . . . . 30 A.5.2. Virtual Interim Meetings . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Hoffman Expires April 18, 2013 [Page 3] Internet-Draft Remote Participation Reqs October 2012 1. Introduction There are two types of participants at the three-times-a-year IETF meetings: the people who are physically at the meeting ("local attendees") and people that are not physically at the meeting but are following the meeting online ("remote attendees"). For more than a decade, the IETF has tried to make it easier for remote attendees to participate in its face-to-face meetings in a meaningful fashion by employing various tools. At the same time, many IETF Working Groups (WGs) have started to have interim meetings that are scheduled between the regular IETF meetings; these are briefly described in [RFC2418]. Some of these interim meetings are face-to-face meetings with remote attendees, while other interim meetings only take place over the Internet or on the phone; the latter type of meeting is often called a "virtual interim". There are also interim meetings that do not support remote participation. The IETF's current remote participation system ("RPS") for the official three-times-a-year meetings ("regular IETF meetings") consists of a real-time audio stream carried to remote attendees over HTTP, textual instant messaging (IM) carried over Jabber, and slides distributed on the IETF web site. Two tools that are experimentally supported, WebEx and Meetecho, are used to sync the audio and slides during the meeting, and also replay them in the proceedings. Some WGs also employ ad-hoc tools such as Skype. For interim WG meetings, the IETF provides access to WebEx. The IETF's leadership regularly uses telephone, Jabber, and WebEx for the many meetings that happen between the IETF meetings. Many meetings use a mixture of tools, with each tool providing only part of the overall desired functionality. A more detailed description of the current IETF RPS can be found in Appendix A. 1.1. Goals for an Improved RPS The IETF wants to improve the tools provided in the RPS for many reasons. o A better RPS would allow current remote IETF attendees to participate in regular IETF meetings more effectively, and would also allow more people to become remote IETF attendees. This in turn would hopefully lead to better WG outcomes. There are many people who are active in many WGs who rarely or never come to IETF meetings; good RPS tools could allow some of these people to contribute better during meetings. Hoffman Expires April 18, 2013 [Page 4] Internet-Draft Remote Participation Reqs October 2012 o The improved RPS tools would also be used outside IETF meetings. They would be available to WGs for interim meetings, both to allow remote participation in face-to-face interims as well as to facilitate virtual interims where none of the attendees are in the same location. o The plenary sessions of IETF meetings currently only allow remote attendees to hear the speakers and read a real-time transcript. Improved RPS tools would allow remote attendees to see the speakers, to see the slides synchronized with the audio, and be able to comment at the mics like people in the room. o The IETF leadership (the IAB, IESG, IAOC, and probably others) could use the new tools to help make their own meetings more effective. o There is a desire to better capture the contributions to the IETF (as defined in [BCP78]) of remote attendees in the official record of regular IETF and interim meetings. The are many IETF-related activities that can be aided by remote participation tools. The scenarios in which the RPS described in this document is expected to be used are WG sessions at regular IETF meetings, plenaries at regular IETF meetings, AD-sponsored lunch meetings at regular IETF meetings, face-to-face interim WG meetings, and IETF leadership meetings. 1.2. About This Document The purpose of this document is to develop the requirements for the IETF's RPS that enables enhanced remote participation in meeting sessions. The RPS described in this document might augment and/or replace the current set of IETF RPS tools. The intention is to improve as much as possible of the experience of remote attendees in meetings while not having a significant negative effect on the experiences of local attendees and WG chairs. This document specifies a set of requirements based on the community desires at the time that this document is written. It is expected that the desires of the community will shift after the RPS described here is deployed and as remote participation tools evolve. The requirements here are for the RPS to be deployed in the near term; later, as the requirements change, additions and changes will certainly be made to the RPS. This document is definitely not meant to limit experimentation with participation ideas after deployment of the RPS described here. This document differentiates between requirements that have higher Hoffman Expires April 18, 2013 [Page 5] Internet-Draft Remote Participation Reqs October 2012 and lower priorities. Higher-priority requirements are intended to be delivered as soon as possible, but lower-priority requirements might be delivered later. For example, a high-priority requirement might be "remote attendees must be able to know which slide is being discussed" and a related, lower-priority requirement might be "remote attendees must be able to see the speaker pointing to the slide with a laser pointer". The eventual tools will be rolled out based on the priorities, making it likely that the community will learn more about additional requirements for lower priority items before they are deployed. Note that some of the requirements in this document for particular functionality may not be desired by all WG chairs. Different WG chairs prefer to use different tools, and that will be true when the additional tools described in this document are deployed. The use of some tools is currently required by the IETF procedures, such as the audio recordings that are put in the proceedings. This document does not mandate the use of any particular tool by a WG, but such a requirement might be made by others, such as an Area Director requiring the use of a particular tool by one or more WGs in their area. This document is being produced at the request of the IAOC. The request for proposals that led to this document can be found at [RPS-RFP]. This document does not specify specific technologies or instantiations of tools. Instead, it is meant to be used as a guide for the IAOC to later contract the development and deployment of the tools described here. It is expected that the IAOC will consider changes and additions to the RPS periodically after the RPS described here is deployed. Requirements in this document are numbered, such as "**Requirement 08-00**". The requirements covered in this document apply almost exclusively to tools and services that are used for remote participation in real- time meetings. The document does not cover the many other tools used by WGs for non-real-time communication such as mailing lists, issue trackers, document flow control systems, and so on. Many of the non- real-time tools are also being improved over time, but they are not the subject of this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document is being discussed on the vmeet@ietf.org mailing list. See for more Hoffman Expires April 18, 2013 [Page 6] Internet-Draft Remote Participation Reqs October 2012 information. 2. Requirements for Supporting Remote Participation in Regular IETF Meetings This section covers the requirements for effective remote participation in meetings where most members are in regular IETF face-to-face meetings. Some of the requirements in this section overlap with those in Section 3, but many are unique to meetings that have a large number of attendees physically present. **Requirement 08-01**: The specifications in the RPS SHOULD rely upon IETF and other open standards for all communications and interactions wherever possible. The RPS might not rely on IETF or other open standards if there is an identified gap that cannot be met by those standards. **Requirement 08-02**: All tools in the RPS MUST be able to use both IPv4 and IPv6 addresses natively. **Requirement 08-03**: All tools in the RPS SHOULD be able to be run on the widest possible array of computers. The tools may be stand- alone applications, may be run from a modern web browser, or from the command line. The highest priority is that the tool need to be available on all of (at least) MacOS version 10.6 or later, Windows 7 or later, and any common Linux distribution produced in 2010 or later. A lower priority is that the tools be able to run on IOS and Android platforms. The tools MUST NOT rely on Adobe Flash to work correctly. **Requirement 08-04**: Audio, video, instant messaging, and slide streams going to and from remote attendees SHOULD be delivered in as close to real-time as is practically possible. The system MUST minimize internal latency, should avoid unnecessary architectural latency, and be designed with a goal of having less than 200 milliseconds of delay to registered remote attendees who are on fast Internet connections. A common complaint with the current RPS is that the streaming audio can take more than 10 seconds (and sometimes as much as 30 seconds) to reach the remote attendee. This causes many of the problems listed in Appendix A.4.1. **Requirement 08-05**: The outgoing audio, video, and slide streams MUST by synchronized so the remote attendee does not get confused during slide presentations. **Requirement 08-06**: Many attendees will be in places with limited bandwidth. Remote attendees on 56Kbps Internet connections SHOULD be Hoffman Expires April 18, 2013 [Page 7] Internet-Draft Remote Participation Reqs October 2012 able to receive useable versions of streaming information. The system SHOULD take advantage of higher bandwidth audio and video encodings for participants on higher bandwidth connections. The system MUST NOT architecturally prevent other users from selecting higher bandwidth encodings. **Requirement 08-07**: Both local and remote attendees SHOULD be able to easily contact a single entity who is available throughout the meeting if they find problems with any of the RPS tools, and to get fairly rapid response. This entity needs to be able to handle as RPS tool problems in the meeting rooms, or be able to quickly contact someone who can address those problems. **Requirement 08-08**: Any tools that are used by remote attendees MUST also be available to local attendees as well. At many IETF meetings, some local attendees act as remote attendees in WG meetings that they are not sitting in, so they can attend two WGs at once. **Requirement 08-09**: The deployment of the tools here MUST take into account making the tools accessible to as many IETF attendees as possible. Such deployment is likely to include technical accommodations for those with visual and hearing disabilities. 2.1. Registration for Remote Participation Remote attendees who make contributions to the IETF (as defined in [BCP78]) are bound by the "Note Well" text. By allowing registration before participating remotely, remote attendees can be better alerted to, and thus bound to, the requirements of contributors. This is particularly important because it is easy in the IETF process to change from being an observer to being a contributor. For example, many people who say things in a WG's IM room do not realize that they are bound by the "Note Well" text. **Requirement 08-10**: All remote attendees at regular IETF meetings and interim meetings who make contributions MUST register with the IETF Secretariat before contributing using any of the RPS tools. **Requirement 08-11**: Remote attendees who will only be listening and/or watching, but not making contributions, MUST NOT be required to register. **Requirement 08-12**: The RPS MUST be able to tell which participants are registered and which are not. This is to allow different levels of service to registered users. **Requirement 08-13**: Registration for remote attendees SHOULD be no more onerous than joining a WG mailing list. Basically, the Hoffman Expires April 18, 2013 [Page 8] Internet-Draft Remote Participation Reqs October 2012 registrant should acknowledge the Note Well, prove that they are at the given email address, and receive confirmation that they are registered. The confirmation will also include any passwords needed for the RPS tools. **Requirement 08-14**: The RPS tools (particularly the registration tool) MUST gracefully handle multiple attendees who have the same name. Note that some unregistered remote attendees might expect to be able to participate but be prevented from doing so by the RPS. The IETF page for each meeting (particularly the agenda pages) can make this clearer to help remote attendees plan better for participation. Registration might happen in the IETF's Datatracker. This would allow the RPS to reuse the Datatracker's identifiers, passwords, identifications (such as who is and is not a WG chair), and so on. The cost for remote attendees to register, if any, is not covered in this document but will instead be determined by the IETF at a later time. There are many ideas on the subject (tiered costs for different services, no cost at all for the first year, and others), but the effects of different cost structures is beyond the scope of this document. 2.2. Instant Messaging Instant messaging (IM) is used both as a remote participation tool and as a communication tool for local attendees at a regular meeting. Although the current tool's Jabber room is a good way to get questions to the mic, it also becomes a second communications channel that only a few people in the room are participating in. The instant messaging system is also useful for remote users to ask about the status of the room ("is anyone there?"). **Requirement 08-15**: The IM system MUST allow anyone to see all messages in the WG's or BoF's room. **Requirement 08-16**: The IM system MUST allow any registered user to post messages in the WG's or BoF's room. **Requirement 08-17**: The date and time that a message appears in an IM stream MUST be retained. IM clients MUST be able to show an indication of the date and time for all messages. Someone coming into a meeting late requires context for which messages in an instant messaging room are recent and which are old. Hoffman Expires April 18, 2013 [Page 9] Internet-Draft Remote Participation Reqs October 2012 2.3. Audio Audio from face-to-face meetings travels in two directions: from the room to remote attendees, and (potentially) from remote attendees to the room. Comments on early drafts of this document indicated that the latter may not really be a requirement for all attendees if IM- to-mic is made predictable. Given this, reliable IM-to-mic relay for comments to speakers is highest priority, audio from remote attendees giving presentations is a second priority, and audio from remote attendees giving comments to the room is a third priority. 2.3.1. Audio to Remote Attendees **Requirement 08-18**: Remote attendees MUST be able to hear what is said by local attendees and chairs at any mic in the meeting. **Requirement 08-19**: Remote attendees SHOULD be able to hear the audio stream over the PSTN. 2.3.2. IM-to-Mic Relay of Comments from Remote Attendees As described in Appendix A.4.1, the current tools support an informal method for remote attendees to speak at the mic: in the Jabber room, they enter the string "mic:" before their comment and hope that the designated scribe or someone else goes to the mic to relay the comment. This method works, but the current implementation has significant flaws described in that section. **Requirement 08-20**: The RPS MUST enable relay of messages from IM to the mic to be able to happen as quickly as if the remote attendee was local. **Requirement 08-21**: The person relaying from IM to the mic must be available throughout the WG meeting. To date, this has been done by WG volunteers in the room. In the future, it could be done the same way, or maybe could be facilitated by hiring people to attend meetings for the specific purpose of being IM-to-mic scribes, or maybe could be done with tools that allow copy-and-paste of text from IM to a speech synthesizer that reads it to the room. **Requirement 08-22**: If multiple remote attendees want to comment at the same time, the person relaying from IM to the mic MUST be able to relay for all of them. Note: during the development of this document, there have been many suggestions for how WG chairs can better manage the IM-to-mic relaying (for example, with planned pauses, better tracking of the IM room, and so on). Because these are actually about improving WG Hoffman Expires April 18, 2013 [Page 10] Internet-Draft Remote Participation Reqs October 2012 chairs, not the RPS tools, they are out of scope for this document. 2.3.3. Audio for Presentations from Remote Attendees In order for a remote attendee to be a presenter, their voice needs to be heard in the meeting room. This functionality is different than allowing remote attendees from giving comments (covered in Section 2.3.4) in that the the WG chair needs much less floor control for one speaker than for many. **Requirement 08-23**: A remote attendee giving a presentation MUST be able to have their speaking be heard by all local and remote attendees. **Requirement 08-24**: A WG chair MUST be able to control the sound coming from any particular remote attendee. This control MUST allow reduction in volume, all the way to complete muting, of the remote speaker. **Requirement 08-25**: Audible echo in the audio stream MUST be damped and/or eliminated by the tools. The RPS MUST recognize audible echo and automatically take measures to reduce it to a level which won't distract listeners. **Requirement 08-26**: The audio system used by the RPS MUST be able to integrate with systems commonly used in the venues used for IETF meetings. These venue systems typically include line-level audio outputs from mixers that combine all the mic inputs into a single stream. Some venue systems also allow for headphone level inputs from PCs to be mixed into the audio stream. 2.3.4. Audio from Remote Attendees to the Room for Comments Note that the requirements here assume a very large change in the way that remote participation will happen. Instead of a remote attendee typing something into the Jabber room that someone will repeat at a mic in the room, remote attendees will use their own mics to speak to the meeting. Some of the requirements from Section 2.3.3 will apply here as well. Further note that, as per above, audio from remote attendees is a secondary priority. That means that the "MUST" requirements in this section are for when the priority is being met, not for when the RPS is initially rolled out. **Requirement 08-27**: Remote attendees MUST be able to speak directly to a meeting without going through a local attendee, and have their speaking be heard by local attendees. (Note that the Hoffman Expires April 18, 2013 [Page 11] Internet-Draft Remote Participation Reqs October 2012 ability to speak is controlled by the chair; see Section 2.3.4.1.) **Requirement 08-28**: Local attendees MUST be able to determine which remote attendee is speaking. **Requirement 08-29**: When a remote attendee connects to the audio stream to the room, their mic SHOULD start off muted. This will prevent problems such as those common with WebEx where a remote attendee doesn't realize that they can be heard. **Requirement 08-30**: A lower-priority requirement is for remote attendees to be able to speak to the room by originating from the PSTN. 2.3.4.1. Floor Control for Chairs for Audio from Remote Attendees It is not yet clear how the set of remote attendees would be treated for queueing. Some tools have each remote attendee being considered separately, while others pool all remote attendees into one group. This affects the chair knowing and being able to act on the order that remote attendees ask to speak. Note that, if the remote video to room requirements from Section 2.4.2 need to be met, it is very likely that a related requirement to those below is that "the audio and video floor controls must be in the same tool". **Requirement 08-31**: Remote attendees MUST have an easy and standardized way of requesting the attention of the chair when the remote attendee wants to speak. The remote attendee MUST also be able to easily cancel an attention request. **Requirement 08-32**: The RPS MUST allow a remote attendee's request for attention to include an optional short (20 characters or less) arbitrary text string. A remote attendee might want to indicate that they are asking a question of the presenter, or answering a question that someone else asked at the mic, or want to bring up a new topic. It is not acceptable to simply rely on humans reading instant messages to allow remote participants to make the request for attention. **Requirement 08-33**: The floor control portion of the RPS MUST give a remote attendee who is allowed to speak a clear signal when they should and should not speak. **Requirement 08-34**: The chair MUST be able to see all requests from remote attendees to speak at any time during the entire meeting (not just during presentations) in the floor control system. Hoffman Expires April 18, 2013 [Page 12] Internet-Draft Remote Participation Reqs October 2012 **Requirement 08-35**: The floor control system MUST allow a chair to easily mute all remote attendees. **Requirement 08-36**: The floor control system MUST allow a chair to easily allow all remote attendees to speak without requesting permission; that is, the chair SHOULD be able to easily turn on all remote attendees mics at once. **Requirement 08-37**: The floor control system for the chair MUST be able to be run by at least two users at the same time. It is common for a chair to leave the room, to have a side discussion with an AD, or to become a presenter. They should be able to do so without having to do a handoff of the floor control capability. **Requirement 08-38**: The RPS MUST authenticate users who can use the floor control system in a particular meeting using simple passwords; other forms of authentication may be used as well. **Requirement 08-39**: The IETF Secretariat MUST be able to easily set up the individuals allowed to use the floor control system for a particular meeting and to change the settings at any time, including during the meeting. 2.4. Video The IETF has experimented with one-way and two-way video at some meetings in the past few years. Remote attendees have said that seeing people in the meetings gave them a better understanding of the meeting; at a recent meeting, a remote presenter was able to see the people in line at the mic and was better able to interact with them. The requirements for video from remote attendees to meeting rooms parallel the requirements for audio from remote attendees to meeting rooms. The IETF video may need to integrate with the video systems at some meeting venues. 2.4.1. Video from the Room to Remote Attendees **Requirement 08-40**: Remote attendees MUST be able to see the presenter at a meeting. **Requirement 08-41**: A lower-priority requirement than Requirement 08-40 is that remote attendees SHOULD be able to see who is speaking at the mics in the room. 2.4.2. Video from Remote Attendees to the Room Note that the requirements in this section have the same priorities as for audio for remote presentations (Section 2.3.3) and audio from Hoffman Expires April 18, 2013 [Page 13] Internet-Draft Remote Participation Reqs October 2012 remote attendees to the room for comments (Section 2.3.4). **Requirement 08-42**: When video is allowed for remote attendees to give presentations (as described in Section 2.3.3), the audience in the room SHOULD be able to see the presenter speaking. **Requirement 08-43**: When video is allowed for remote attendees for comments, the floor management tool for audio (as described in Section 2.3.4.1) MUST also control video as well. **Requirement 08-44**: The RPS MUST have the capability of showing video of the remote attendee who is speaking over the audio to the local attendees. **Requirement 08-45**: A remote attendee who is speaking MUST be able to choose what is shown to local attendees: video of them speaking, a still picture of their face or avatar, or just their name. **Requirement 08-46**: The RPS MUST give a remote attendee a clear indication when their video image or selected image is being shown to the local attendees. 2.5. Slide Presentations and Distribution This section discusses slide presentations, which are the primary form of presentations made in WG meetings. It should be noted that are occasionally other types of presentations, such as videos; these are not dealt with in the tools proposed below. In this section, "distribute" means slides that are downloaded from the IETF site, while "transmit" means the slide stream seen in near- real-time as the presenter is speaking. **Requirement 08-47**: The RPS MUST be able to handle both PDF and PowerPoint formats (".ppt" and ".pptx") for distributed slides. **Requirement 08-48**: The RPS MUST automatically convert PowerPoint presentations to PDF and make both available for distribution at the same time. **Requirement 08-49**: Presenters MUST be able to update their slides on the IETF site up to just before their presentation, if such update is allowed by the WG chairs. **Requirement 08-50**: Chairs MUST be able to approve or disapprove of any slide submission or updates, with the default being that all submissions are allowed. Hoffman Expires April 18, 2013 [Page 14] Internet-Draft Remote Participation Reqs October 2012 In many current remote participation systems, slide presentations and the video coming from in-meeting cameras are sent as two separate streams (called the "slide stream" and the "camera stream"). The slide stream is usually much lower bandwidth than the camera stream, so remote attendees with limited bandwidth can choose to watch just the slide stream. Separating the streams allows remote attendees to see the slide stream and the camera streams in separate windows that can be independently sized. **Requirement 08-51**: The RPS MUST transmit the slide stream separately from the camera stream. **Requirement 08-52**: The slide stream MUST represent the slides as they are projected in the room, allowing the presenter to go back and forth, as well as to edit slides in real time. This makes it clear to the remote attendees which set of slides, and which slide number, is being currently shown. **Requirement 08-53**: When remote presentations are supported (see Section 2.3.3), the remote presenter SHOULD be able to control the slides. This is a lower-priority requirement because this could be easily done by a local attendee listening to the remote presenter. 2.6. Shared Text Document Editing In some WG meetings, there is an attempt to edit a text document with input from the local attendees. This is typically done for proposed charter changes, but sometimes happens on a WG document or the meeting's agenda. This is usually unsuccessful, given the amount of text and the size of what can be displayed on the screen. In recent meetings, shared text document editing has been used for editing charters and for taking minutes of meetings. An RPS tool for shared text document editing would be equally useful for local and remote attendees watching the edits happen in real- time. There is a good chance that this tool would be watched by local attendees on their laptops instead of being projected on the screen because of the small size of the the text. This, in turn, means that local attendees who aren't using their laptops at the moment would not be able to participate by watching. **Requirement 08-54**: Shared real-time editing of text documents MUST be supported. This system must allow at least three people to have write access and hundreds of people to have read access to any particular document. **Requirement 08-55**: It MUST be easy to start a new text shared document and to import existing text into a shared document. Hoffman Expires April 18, 2013 [Page 15] Internet-Draft Remote Participation Reqs October 2012 **Requirement 08-56**: Remote attendees MUST be able to be either the writers or the readers of shared documents. **Requirement 08-57**: The edits MUST be reasonably synchronized with the sound and video so that those with read access can see the edits made by those with write access as they are listing to the meeting. **Requirement 08-58**: It MUST be easy to change the permissions for who gets write access to a document during an editing session. **Requirement 08-59**: A much-lower priority requirement is the ability for group-editing of graphics. 2.7. Archiving Archived recordings of the events of the meetings are valuable for remote attendees who are not able to hear everything in real time. **Requirement 08-60**: The RPS MUST support storage and distribution of recordings of the audio, video, and slide presentations for all WG meetings. **Requirement 08-61**: Transcripts of the instant messaging for all meetings MUST be kept for distribution after IETF meetings. **Requirement 08-62**: The recordings and transcripts SHOULD be made available during the meetings, within a day of them being made. **Requirement 08-63**: Users MUST be able to easily find the archives of the recordings and instant messaging transcripts of a particular WG or BoF session at a particular meeting. **Requirement 08-64**: The RPS SHOULD support indexing of archived audio and video for particular events in meetings such as when speakers change. This is a frequently-requested feature, although there is not yet widespread agreement on standards to do so. **Requirement 08-65**: The RPS MUST support recording and storage of recordings of the audio, video, and slide presentations of interim meetings as well as regular IETF meetings. **Requirement 08-66**: Given that interim meetings are often run without the help of the IETF Secretariat, making these recordings MUST be easy for WG chairs. Hoffman Expires April 18, 2013 [Page 16] Internet-Draft Remote Participation Reqs October 2012 2.8. Polling The common IETF method of assessing support is a straw poll, sometimes managed by audible humming, sometimes by raising hands. **Requirement 08-67**: A system for yes/no/abstain polling meeting attendees, including remote attendees at the same time, MUST be provided. It MUST be easy to set up a simple poll, and it must be easy for all local and remote attendees to find the poll and participate. Note that this would add a requirement that everyone in a meeting be using their computer to participate in the poll. 2.9. Plenaries **Requirement 08-68**: Remote attendees SHOULD be able to make comments at the mic approximately as well as if they were local attendees. This means that either remote audio to the plenary room speakers be available, or that IM-to-room relay be available. **Requirement 08-69**: Transmitting real-time transcription of plenary speakers to remote attendees MUST be supported. The lag in transmission MUST be less than five seconds. 2.10. Use by IETF Leadership The requirements for bodies like the IESG and IAB to use the RPS during regular IETF meetings are similar to those of most WGs. The main difference is that they need a way to limit who can participate remotely. **Requirement 08-70**: The chair or meeting facilitator MUST be able to easily limit remote access of all tools (both for listening/ observing and contributing) to meetings on a room-by-room basis. **Requirement 08-71**: The IETF Secretariat must be able to limit attendees in restricted meetings using a simple authentication mechanism. Note that the IETF leadership will also heavily use the remote participation tools between IETF meetings in a manner that is very similar to virtual interim meetings. 2.11. Preparation Both WG chairs and attendees need to be able to prepare for an IETF meeting and individual WG meetings. The more tools that might be used in a meeting, the more important it is that the chairs and attendees be able to prepare easily. Hoffman Expires April 18, 2013 [Page 17] Internet-Draft Remote Participation Reqs October 2012 2.11.1. Preparation for WG Chairs **Requirement 08-72**: Sessions MUST NOT be associated with physical rooms until just before session starts. This allows a previous session to run over its time into the break period without inconveniencing remote users or the archives. **Requirement 08-73**: The RPS MUST allow a session to be moved from one room to another during the session This is needed because the Secretariat sometimes need to swap the rooms for WGs when it becomes clear that one is too full and another room has excess space. **Requirement 08-74**: WG chairs MUST be able to test whether or not the tools for their session are working at least 30 minutes before the meeting begins (unless, of course, there is already another meeting occurring in the room during that time). Session testing is done before session is associated with a physical room. **Requirement 08-75**: There MUST be written operational documentation for each RPS tool that is accessible at all times. This will help reduce problems where a WG chair is having problems during a meeting that is affecting the meeting as a whole. **Requirement 08-76**: There SHOULD be training materials for WG chairs in how to use the RPS tools. **Requirement 08-77**: There SHOULD be a custom checklist for each WG that helps the chair prepare for their meeting. The checklist would enumerate the steps needed before the meeting begins, to start the meeting, during the meeting, to close the meeting, and after a meeting. 2.11.2. Preparation for Remote Attendees **Requirement 08-78**: Remote attendees MUST be able to easily find all the material they need to effectively participate, including links to audio, video, instant messaging, slides, and so on. This material MUST be available well before the time of the meeting. The page with the meeting material SHOULD allow the remote attendee to easily perform a time conversion to and from the local time at the IETF meeting. **Requirement 08-79**: There MUST be a constantly-running testing service that covers all interactive tools (audio, video, slide display, and so on) for at least a week before the meeting begins. This would be similar to the "call here to ensure your voice and video are set up correctly" test available for other services. Remote attendees need to be able to test the remote participation Hoffman Expires April 18, 2013 [Page 18] Internet-Draft Remote Participation Reqs October 2012 setup before a regular meeting, and even during the meeting. **Requirement 08-80**: The testing service MUST run throughout the meeting so that last-minute joiners can test their systems. **Requirement 08-81**: The testing service SHOULD allow remote attendees to also test whether their outgoing audio, video, and slide control works. **Requirement 08-82**: A remote attendee who starts using one or more tools after a meeting has begun MUST be able to tell what is happening in the meeting. In specific, there MUST be an indication if the meeting has not started, if the meeting is happening (even if there is silence on the mics), and if the meeting is over. 3. Requirements for Supporting Remote Participation in Interim Meetings One of the goals of this document is to increase the effectiveness of interim meetings. Interim meetings are now uncommon, but might become more common (and more effective) if the remote participation becomes more useful. The requirements for meetings that are all remote (that is, with no local attendees) are mostly a subset of the requirements for remote participation in a regular IETF meetings and face-to-face interim meeting. **Requirement 08-83**: The RPS SHOULD have a central location where the specifics about how remote participation is supported for every WG interim meeting. This will reduce the problems often seen where messages about how to participate in an interim meeting get buried in the WG mailing list. **Requirement 08-84**: There SHOULD be documentation and training for the RPS tools specifically targeted at WG chairs who will lead interim meetings. **Requirement 08-85**: The RPS tools MUST be at least partially usable at face-to-face meetings other than regular IETF meetings. The number of the tools that might be available will be different for different venues for the virtual interims, but at a minimum, the following MUST be supported for remote attendees: o Registration o Room audio Hoffman Expires April 18, 2013 [Page 19] Internet-Draft Remote Participation Reqs October 2012 o Instant messaging o Slide distribution o Slide presentation o Shared document editing 4. IANA Considerations None. [[ ...and thus this section can be removed before publication as an RFC... ]] 5. Security Considerations People who participate remotely in face-to-face IETF meetings might expect the same level of privacy as they have when they participate directly in those meetings. Some of the proposed tools might cause it to be easier to know which WGs a remote attendee was following. When RPS tools are deployed, the IETF should describe the privacy implications of using such a tool to the users so they can decide whether or not to use the tools. The eventual RPS tools will have some user authentication that will associate people with actions. For example, a remote user might need to authenticate to the system in order to give a presentation or speak during a session. The credentials needed for this authentication will need to be managed in a secure fashion, both by the system and by the people who are being identified. 6. Acknowledgements Many of the ideas in this document were contributed by members of the IETF community based on their experiences during recent IETF meetings. There are also many contributions from people on the vmeet@ietf.org mailing list, WG chairs, and attendees in the RPSREQS BoF at IETF 83 in Paris. Some of the text in this document originated in the request for proposals that was issued by the IAOC that led to this document. 7. Informative References [BCP78] Bradner, S. and J. Contreras, "Rights Contributors Provide Hoffman Expires April 18, 2013 [Page 20] Internet-Draft Remote Participation Reqs October 2012 to the IETF Trust", BCP 78, RFC 5378, November 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011. [RPS-RFP] IAOC, "Request for Proposals for Requirements Development for Remote Participation Services", 2011, . Appendix A. Background on IETF Remote Participation The IETF has a long history of using remote participation tools. This history causes many IETF participants to have strong opinions about what future tools should provide and who should benefit from those tools. The purpose of this section is to describe many of the common perceptions of the current tools so that the reader understands what might be expected of future tools. Users' experience with the current IETF tools vary widely. Some participants think the tools are fine and are grateful that they exist. Other participants find them barely acceptable because they have used better tools in other environments. Often, local attendees mostly forget that the remote attendees are participating until one gets gets reminded, such as by something said at the mic. Local attendees don't have a feeling for how many remote attendees are just listening like most of the local attendees. The variety of current experiences can help inform the discussion of how to improve the tools. The experiences described in this appendix are derived from the current tools. It is important to note that people who attend IETF meetings often experience the tools quite differently than those who participate remotely. The IETF has years of experience with the three primary tools used at its regular meetings: prepared slides that are distributed before and during the meeting, Jabber for IM, and streaming audio. This section Hoffman Expires April 18, 2013 [Page 21] Internet-Draft Remote Participation Reqs October 2012 discusses some of the reactions of users -- those in the meetings and those who have participated remotely -- to the current tools. Remote attendees typically participate by asking questions or making statements during or after presentations, and they also participate in discussions in the instant messaging channel. Local attendees who are using the RPS typically don't participate "remotely": they are using the tools to be able to see what is happening in different rooms when they need to be two or more places at once. A.1. How the IETF Meets o WG sessions at regular IETF meetings -- A typical regular IETF meeting has about 150 sessions lasting one to two and one half hours each, with up to 8 of those sessions happening at the same time. A session might have between 20 and 200 local attendees in the room, and might have only a few or many dozens of remote attendees. WG sessions typically have one to three co-chairs at the front of the room and a series of individuals who come to the front to present; some presentations are made by small panels. o Plenaries at regular IETF meetings -- There are usually two plenaries at a regular IETF meeting, with on-site attendance of about 700 local attendees and dozens of remote attendees. There are from 1 to 20 presenters; presentations may be made by multiple people. o AD-sponsored lunch meetings at regular IETF meetings -- These meetings are scheduled by the IETF Secretariat. Regular IETF meetings are more than just a group of WG meetings. Remote attendees may want to participate in the other parts of a regular meeting as well. o Face-to-face interim WG meetings -- Between regular IETF meetings, some WGs hold interim meetings where attendees get together at a site (often a company's meeting room, but sometimes a meeting room rented at a hotel). At such meetings, there are between a handful and a few dozen local attendees and a similar number of remote attendees, if remote participation is supported. Presentations are common. There are typically fewer than 15 face-to-fact interim meetings a year. o Virtual interim WG meetings -- Between regular IETF meetings, some WGs hold virtual interim meetings where there are no local attendees because there is no central meeting location. There are between a handful and a few dozen attendees. Presentations are common. There are typically fewer than 25 face-to-fact interim meetings a year. Hoffman Expires April 18, 2013 [Page 22] Internet-Draft Remote Participation Reqs October 2012 o IETF leadership meetings -- The IETF leadership (the IESG, IAOC, IAB, and probably others) have periodic virtual meetings, usually with presentations. These groups also meet at the regular IETF meetings, and sometimes have remote attendees at those meetings (such as members who cannot attend the IETF meeting or presenters who are not part of the leadership group). The form of "presentations" changes from meeting to meeting, but almost always includes prepared static slides and audio of the speaker. Presentations sometimes also includes non-static slides (usually animations within a slide) and sometimes video. A.2. Technologies Currently Used at Regular IETF Meetings There are three tools that are used by remote attendees for WG participation at regular IETF meetings: real-time audio, instant messaging, and slides. For the past few years, the IETF has used audio streamed over HTTP over TCP. TCP is often buffered at many places between (and in) the origination in the IETF meeting venue and the users' computer. At recent meetings, delays of around 30 seconds have been recorded, with minimum delays typically being five seconds. This delay is caused by buffering at the hop-by-hop ISPs and in the remote attendee's computer. At recent IETF meetings, remote attendance is almost always less than 10% of local attendance, and is often less than 5%. (There are more remote attendees when the IETF meeting is in the U.S.) Each stream is represented by an MP3 playlist (sometimes called an "m3u file"). The IETF long ago standardized on Jabber / XMPP ([RFC6120], [RFC6121], and others) for instant messaging used within the IETF. Jabber rooms (formally called "multi-user conferences" or "MUCs") exist for every WG, and those rooms are live all the time, not just during regular IETF meetings. BoFs have jabber rooms that are available during IETF meetings. There are also stable Jabber rooms for the plenaries and certain other activities. BoFs are usually assigned Jabber rooms before a regular meeting. Presentation slides normally are stored either as PDFs or in one of Microsoft's formats for PowerPoint. They are projected on a local screen from someone's laptop computer. Proceedings are currently stored as PDF of the slides, although they used to be stored as HTML. There has been experience at recent meetings with two tools, WebEx and Meetecho, which are supported experimentally by the IETF. Each tool was used by a handful of WGs with mixed success. The tools require remote attendees to use specific clients, and installation of Hoffman Expires April 18, 2013 [Page 23] Internet-Draft Remote Participation Reqs October 2012 those clients caused problems for some people. On the other hand, the tools have much more robust meeting control features, and attendees appreciated the real-time showing of slides during presentations. A.3. Locating the Meeting Information Finding information for the real-time audio, instant messaging, and slides for an upcoming or current regular meeting is complicated by that information being in many different locations on the IETF web site, and the fact that the relevant URLs can change before and even during the meeting. Further, a WG chair might copy the latest information and send it to the WG mailing list, but there can be later changes. Experienced remote attendees have gotten used to checking just before the meeting itself, but even that does not always guarantee the correct information. Currently, the meeting information appears in two different agendas: o The official agenda on the IETF Datatracker includes links to venue maps, WG charters, agendas, and Internet-Drafts. For example, see . o The unofficial "tools-style agenda" includes the same links as the official agenda plus links to the presentations, audio, minutes, Jabber room, and Jabber logs 9represnted as small icons). For example, see . A.3.1. Audio The URL for the audio stream for a WG or BoF meeting is based on the room that the meeting is in. The audio streams are announced on the general IETF mailing list (ietf@ietf.org) before each meeting. A common complaint is that when a WG meeting moves to a different room, remote users need to know about the move so that they can use the proper URL to hear the audio stream. The room changes are often, but not always, announced on WG mailing lists; when they are not announced, there is no easy way for a remote attendee to find out which audio stream they should be listening to. Sometimes, room changes happen just as a WG meeting is starting, making it nearly impossible for a remote attendee to know about the change in streams. IETF meetings happen in venues such as hotels and conference centers, most of which have their own audio setups. The IETF Secretariat contracts with those venues for the use of some or all of their audio system. Without such integration, audio from remote attendees might Hoffman Expires April 18, 2013 [Page 24] Internet-Draft Remote Participation Reqs October 2012 not be reliably heard by local attendees. A.3.2. Instant Messaging The Jabber rooms used by WGs and BoFs do not change between IETF meetings, so finding the right Jabber room is relatively easy. Some Jabber clients have odd interfaces for joining Jabber rooms, and this can cause some problems; even though attendees can test their Jabber clients before a meeting, there still seems to be some who need help just before a WG meeting. There are sometimes problems with people joining Jabber rooms; in these cases, the attendee needs to find someone already in the Jabber room to invite them to the discussion. A.3.3. Slides Slides are presented in regular IETF meetings with projectors on a screen at the front of the room from the video output of one or more local attendees' computers. The same slides are available online for remote attendees. Slides are available to local and remote attendees on the IETF servers before and during regular IETF meetings. This service is useful to all attendees who want to be prepared for WG meetings. The slides are not only used by remote attendees listening to the WG meeting; it is common for local attendees to download the slides and view them on their laptops during meetings instead of having to read them from the front of the room. Slides are available from the meeting materials page. Many, but certainly not all, local and remote attendees know how to find the meeting materials page. It has become fairly common for presenters to not have their presentations available for distribution until just before the WG meeting. Because materials are uploaded by the WG chairs, this often causes the beginning of WG meetings to be a dance involving presenters giving the chairs their slides, followed by chairs uploading the slides to the IETF site, followed by the chairs saying "the slides are there now". A.4. Remote Participation at IETF Meetings A.4.1. Remotely Speaking at the Mic Newcomers to regular IETF meetings often expect the floor control in WG meetings to be fairly straight-forward. By Tuesday, they might be shaking their heads, wondering why some people cut into the mic lines, why some people get up to the mics after the chair has closed Hoffman Expires April 18, 2013 [Page 25] Internet-Draft Remote Participation Reqs October 2012 the line, why some people ignore presenters' requests to hold questions to the end, and so on. Mixing remote attendees into this social structure will be a daunting task, but one that has been dealt with in many remote participation systems. In order for a remote attendee to speak at the mic, a local attendee must say it for them. In most WG and BoF meetings, this is done by the remote attendee typing into the Jabber room for the meeting, and some local attendee going to the mic and repeating what was typed into the Jabber room. Remote attendees often precede what they want said at the mic with the string "mic:" to differentiate that from the rest of the discussion in the Jabber room. In some WGs, there have been experiments of getting remote attendees voices into the room either by hooking into the room's sound system or pointing a mic at the speaker of a laptop. This sometimes works, but sometimes has bad feedback and delay issues that make the remote participation worse than having a person reading their comments at the mic. The "Jabber-to-mic" method of participation often works adequately, but there are many places where it fails. It has issues similar to most proxy approaches where a human is in center of the loop. The following is a compendium of stories from recent IETF meetings and interim face-to-face meetings where remotely speaking at the mic didn't work as well as it could have. The list is given here to both point out what some WGs are willing to put up with currently, and to show what is needed if the eventual RPS uses Jabber-to-mic as part of the solution. The attendees are Chris and Carl (WG co-chairs), Sam (volunteer Jabber scribe), Rachel and Robert (remote attendees), Pete (presenter), and Len and Lee (local attendees). o Robert cannot understand what Pete is saying about slide 5, but Sam doesn't get Pete's attention until Pete is already on slide 7 and Pete doesn't want to go back. o Rachel wants to say something, but Sam's Jabber client has crashed and no one else in the Jabber room knows why Sam isn't going to the mic. o Robert wants to say something, but Sam is already at the mic speaking for Rachel so Sam doesn't see Robert's message until he has gotten out of the mic line. o Sam is speaking for Robert, and Rachel wants to comment on what Robert said. Unless Sam reads the message as he is walking back to his seat, Rachel doesn't get to speak. Hoffman Expires April 18, 2013 [Page 26] Internet-Draft Remote Participation Reqs October 2012 o Robert wants to say something at the mic, but Sam is having an important side discussion with the AD. o Sam is also the minutes taker, and is too busy at the moment catching up with the lively debate at the mic to relay a question from Rachel. o Chris thought Carl was watching the Jabber room, but Carl was reading the draft that is being discussed. o Chris and Carl start the meeting by asking for volunteers to take minutes and be Jabber scribe. They couldn't find a Jabber scribe, and it took a lot of begging to get someone to take minutes, so they figured that was the best they could do. o Sam is also a presenter, and Robert has a question about Sam's presentation, but Sam is obviously not looking at the Jabber room at the time. o Rachel asks a question through Sam, and Pete replies. Len, who is next in line at the mic, starts talking before Sam has a chance to see whether or not Rachel has a follow-up question. o Robert makes a point about one of Pete's slides, and Pete responds "I don't think you're looking at the right slide" and continues with his presentation. Robert cannot reply in a timely fashion due to the lag in the audio channel. o Pete starts his presentation by asking for questions to be held until the end. Robert has a question about slide 5, and is waiting until the end of the presentation to post the question in the Jabber room. After slide 7, Len jumps to the mic and vehemently disagrees with something that Pete said. Then Lee gets up to respond to Len, and the three of them go at it for a while, with Lee getting up again after slide 10. The presentation ends and is over time, so Carl says "we need to move on", so Robert never gets to ask his question. o Chris asks "are there any more questions" while Rachel is typing furiously, but she doesn't finish before Chris says "I don't see anyone, thanks Pete, the next speaker is...". o Rachel comments on Pete's presentation though Sam. Sam doesn't understand what Rachel is asking, and Len goes to the mic to explain. However, Len gets his explanation of what Rachel said wrong and by the time Pete answers Len's interpretation, Rachel gives up. Hoffman Expires April 18, 2013 [Page 27] Internet-Draft Remote Participation Reqs October 2012 o This is the first time Pete is presenting at an IETF meeting, and Robert has the first question, which is relayed through Sam. Pete stays silent, not responding the question. Robert can't see Pete's face to know if Pete is just not understanding what he asked, is too afraid to answer, is just angry, or something else. o Pete says something incorrect in his presentation, and Len asks the folks in the Jabber room about it. Rachel figures out what Pete should have said, and others in the Jabber room agree. No one goes to the mic because Pete has left the topic, but only the people watching Jabber know that the presentation was wrong. o Pete says something that the AD sitting at the front of the room (not near a mic) doesn't like, and the AD says a few sentences but doesn't go to the mic. The chairs try to repeat what the AD says, get it only approximately right, but the remote attendees do not hear what really was said and therefore cannot comment effectively. o Sam only volunteered to be scribe because no one else would do it, and isn't sitting close to the mic, and gets tired of getting up and down all the time, and doesn't really agree with Robert on a particular issue, so Sam doesn't relay a request from Robert. o Rachel cannot join the Jabber room due to a client or server software issue. She finally finds someone else on Jabber who is also in the meeting, and gets them to invite her into the room. A.4.2. Remotely Presenting Some WGs have experimented with remote presentations at regular IETF meetings, with quite mixed results. For some, it works fine: the remote presenter speaks, the chair moves the slides forward, and questions can be heard easily. For others, it is a mess: the local attendees can't hear the presenter very well, the presenter can't hear questions or there is a long delay, and it was not clear when the presenter was waiting for input or there was a lag in the sound. At a recent meeting that had a remote presenter, a WG had a video camera set up at the chairs' desk pointed towards the audience so that the presenter could see who was at the mic; this was considered to be a great help and a lot friendlier because the presenter could address the people at the mic by name. They also had the presenter's head projected on the screen in the room, which led to a lot of jokes and discussion of whether seeing the remote presenter caused people to pay more attention. Remote presenters have commented how difficult it is to set up their Hoffman Expires April 18, 2013 [Page 28] Internet-Draft Remote Participation Reqs October 2012 systems, particularly because they are not sure whether their setup is working until the moment they are supposed to be presenting. Even then, the first few minutes of the presentation has a feeling of "is this really working?". A.4.3. Floor Control Although Appendix A.4.1 may seem like it is a bit harsh on WG chairs, the current tools do not give them the kind of control over remote attendees that they have over local attendees. The chairs can tell what is happening at the mics, but have much less view into what is happening on Jabber, even if they are watching the Jabber room. Without as much view, they cannot assist the flow of the conversation as well. o Carl sees that the Jabber room has an active and useful back- channel discussion during Pete's provocative presentation. Pete finishes and asks for questions. Lee and Len rush to the mic line, and it takes Robert a few seconds to get his question into the Jabber room and for Sam to go to the mic. Carl tries to prioritize Sam forward in the line, but Len gets upset when he does. o Rachel asks a question, but Sam is not going to the mic to relay it. In fact, Sam has pretty much stopped paying attention. Chris cannot do something about the situation without making Sam look bad. o Pete has run over time, Robert asks what is supposed to be the last question, and Pete doesn't understand what Sam said. Carl cannot tell whether to wait for Robert to rephrase the question or whether Robert even heard Pete's response. o In a virtual interim where remote attendees all participate by voice, someone can be heard typing / eating / talking loudly to someone else. Carl and Chris try to get that person's attention over the audio and Jabber, but to no avail. The tool being used does not have the ability to mute individual attendees, so the meeting is disrupted until that person finally realizes that he or she is not muted. Some of these problems are alleviated by some of the proprietary solutions that have been experimented with. For example, WebEx and other systems have a "raise hand" feature where a remote attendee can indicate in the application or through a web form that they want to speak. Hoffman Expires April 18, 2013 [Page 29] Internet-Draft Remote Participation Reqs October 2012 A.5. Remote Participation at IETF Interim WG Meetings Face-to-face interim meetings have many things in common with regular IETF meetings, but there are also many significant differences. For most WGs, fewer people attend interim meetings than IETF meetings, although those who travel to a face-to-face interim meeting are often the more active WG participants. There may be a larger demand for remote participation because people have a harder time justifying travel for a single WG meeting than for an IETF meeting, but there may also be less demand because people tend to think of interim WG meetings as less important than regular IETF meetings.. Typically, the IETF Secretariat does not control the rooms in which face-to-face interims are held, so they have no control over whether outgoing audio will be supported, or supported well enough to guarantee that remote attendees can hear. A.5.1. Face-to-Face Interim Meetings Many interim meetings are held face-to-face in conference rooms supplied by companies active in the IETF (and, much less often, in commercial conference facilities such as hotels). Because these facilities are not administered by the IETF Secretariat, the ability to include remote attendees varies widely. Some facilities can distribute the in-room audio over the Internet just fine, while others have no or limited abilities to do so. For example, a recent face-to-face interim meeting was supposed to be open to remote attendees through WebEx, but the sound coming from the room was too soft to hear reliably. Even if a face-to-face interim meeting has good facilities for audio and slide presenting, it will probably have an experience similar to regular IETF meetings. A.5.2. Virtual Interim Meetings Because few WGs have virtual interim meetings (those with no face-to- face attendees), there is less experience with the tools that are commonly used for them. The IETF has had free use of WebEx for a few years, and some WGs have used different tools for audio participation. For example, some virtual interims are held using Skype, others with TeamSpeak, and so on. So far, the experience with virtual interim meetings has been reasonably good, and some people say that it is better than for remote attendees at regular IETF meetings and face-to-face interims because everyone has the same problems with getting the group's attention. Also, there are no problems getting the in-room audio into the RPS because all attendees are using their own computers for Hoffman Expires April 18, 2013 [Page 30] Internet-Draft Remote Participation Reqs October 2012 speaking to the group. One of the often-debated aspects of virtual interim meetings is what time to have them in order to make them available to all attendees. Such scheduling of virtual interim meetings is out of scope for this document. However, it is noted that because many attendees will be attending at different times of day and night, no assumption can be made that attendees will be at an "office". This debate also affects face-to-face interim meetings because the meeting hosts normally will schedule the meeting during business hours at the host company, but that might be terribly inconvenient for some WG members. Author's Address Paul Hoffman VPN Consortium Email: paul.hoffman@vpnc.org Hoffman Expires April 18, 2013 [Page 31]