Network Working Group                                         P. Hoffman
Internet-Draft                                            VPN Consortium
Intended status: Informational                             March 9,                               May 7, 2012
Expires: September 10, November 8, 2012

      Requirements for Remote Participation Services for the IETF
                     draft-ietf-genarea-rps-reqs-03
                     draft-ietf-genarea-rps-reqs-04

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, approaching improving the quality of direct physical attendance experience for the various roles, including chair, presenter and simple attendee. remote attendee 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 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 September 10, November 8, 2012.

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
   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  About This Document  . . .  Goals for an Improved RPS  . . . . . . . . . . . . . . . .  5
   2.  Scenarios Required to be Supported  4
     1.2.  About This Document  . . . . . . . . . . . . . .  7
   3.  Interactions with Current RPS Tools Used by the IETF . . . . .  8
     3.1.  Technologies Currently Used at  5
   2.  Requirements for Supporting Remote Participation in
       Regular IETF Meetings  . . .  8
     3.2.  Locating the Meeting Information . . . . . . . . . . . . .  9
       3.2.1.  Audio . . . .  6
     2.1.  Registration for Remote Participation  . . . . . . . . . .  7
     2.2.  Instant Messaging  . . . . . . . . . .  9
       3.2.2.  Instant Messaging . . . . . . . . . .  8
     2.3.  Audio  . . . . . . . . 10
       3.2.3.  Slides . . . . . . . . . . . . . . . . . .  9
       2.3.1.  Audio to Remote Attendees  . . . . . . 10
     3.3.  Remote Participation at IETF Meetings . . . . . . . .  9
       2.3.2.  IM-to-Mic Relay of Comments from Remote Attendees  . . 10
       3.3.1.  Remotely Speaking at the Mic  9
       2.3.3.  Audio for Presentations from Remote Attendees  . . . . 10
       2.3.4.  Audio from Remote Attendees to the Room for
               Comments . . . . . . . . . 10
       3.3.2.  Remotely Presenting . . . . . . . . . . . . . . 10
     2.4.  Video  . . . 13
       3.3.3.  Floor Control . . . . . . . . . . . . . . . . . . . . 13
     3.4.  Remote Participation at IETF Interim WG Meetings . . . 12
       2.4.1.  Video from the Room to Remote Attendees  . . 14
       3.4.1.  Face-to-Face Interim Meetings . . . . . 12
       2.4.2.  Video from Remote Attendees to the Room  . . . . . . . 14
       3.4.2.  Virtual Interim Meetings 13
     2.5.  Slide Presentations and Distribution . . . . . . . . . . . 13
     2.6.  Shared Text Document Editing . . . . 14
   4.  Requirements for Supporting Remote Participation in
       Regular IETF Meetings . . . . . . . . . . . 14
     2.7.  Archiving  . . . . . . . . . 15
     4.1.  Registration for Remote Participation . . . . . . . . . . 17
     4.2.  Audio . . . . . 15
     2.8.  Polling  . . . . . . . . . . . . . . . . . . . . . 18
       4.2.1.  IM-to-Mic Relay of Comments from Remote
               Participants . . . . 15
     2.9.  Plenaries  . . . . . . . . . . . . . . . . . 18
       4.2.2.  Audio from Remote Participants to the Room . . . . . . 19
     4.3.  Video . 16
     2.10. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 16
     2.11. Preparation  . . . . . . . 21
       4.3.1.  Video from the Room to Remote Participants . . . . . . 21
       4.3.2.  Video from Remote Participants to the Room . . . . . . 22
     4.4.  Instant Messaging . . . . 16
       2.11.1. Preparation for WG Chairs  . . . . . . . . . . . . . . 16
       2.11.2. Preparation for Remote Attendees . . 22
     4.5.  Slide Presentations . . . . . . . . . 17
   3.  Requirements for Supporting Remote Participation in
       Interim Meetings . . . . . . . . . . . 23
     4.6.  Slide Distribution . . . . . . . . . . . . 18
   4.  IANA Considerations  . . . . . . . . 24
     4.7.  Shared Document Editing . . . . . . . . . . . . . 18
   5.  Security Considerations  . . . . 24
     4.8.  Archiving . . . . . . . . . . . . . . . 19
   6.  Acknowledgements . . . . . . . . . 25
     4.9.  Transcription . . . . . . . . . . . . . . 19
   7.  Informative References . . . . . . . . . 26
     4.10. Polling . . . . . . . . . . . 19
   Appendix A.  Background on IETF Remote Participation . . . . . . . 20
     A.1.  How the IETF Meets . . . . . . . 26
     4.11. Plenaries . . . . . . . . . . . . . 20
     A.2.  Technologies Currently Used at Regular IETF Meetings . . . 22
     A.3.  Locating the Meeting Information . . . . . . . . 26
     4.12. Use by IETF Leadership . . . . . 22
       A.3.1.  Audio  . . . . . . . . . . . . . 26
     4.13. Additional Requirements for Remote Participation . . . . . 27
   5.  Requirements for Supporting Remote Participation in
       Interim Meetings . . . . . . 23
       A.3.2.  Instant Messaging  . . . . . . . . . . . . . . . . . 28
     5.1.  Requirements for Supporting Remote Participation in
           Face-to-Face  Interim Meetings . 23
       A.3.3.  Slides . . . . . . . . . . . . . 28
     5.2.  Requirements for Supporting All-Remote Interim . . . . . . . . . . . 24
     A.4.  Remote Participation at IETF Meetings  . 29
   6.  IANA Considerations . . . . . . . . . 24
       A.4.1.  Remotely Speaking at the Mic . . . . . . . . . . . . 29
   7.  Security Considerations . 24
       A.4.2.  Remotely Presenting  . . . . . . . . . . . . . . . . . 27
       A.4.3.  Floor Control  . . . 30
   8.  Acknowledgements . . . . . . . . . . . . . . . . . 27
     A.5.  Remote Participation at IETF Interim WG Meetings . . . . . 28
       A.5.1.  Face-to-Face Interim Meetings  . 30
   9.  Informative References . . . . . . . . . . . 29
       A.5.2.  Virtual Interim Meetings . . . . . . . . . 30 . . . . . . 29
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 30

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
   providing supported and experimental online services.
   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 (briefly) 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, as well as experimental and slides
   distributed on the IETF web site.  Experimental support for two
   integrated tools, WebEx and Meetecho. 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 more people current remote IETF attendees to
      participate in regular IETF meetings more effectively, hopefully leading to better WG
      outcomes such as faster progression of WG documents, more
      reviewers of WG documents, and would
      also allow more discussion of changes needed people to those documents during the become remote IETF attendees.  This in
      turn would hopefully lead to better WG process. 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
      significantly better during meetings like they do on the mailing lists. meetings.

   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" virtual interims where none of the participants 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
      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.

1.1.

   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 and
   functional specifications 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 for to
   improve as much as possible of the experience of remote attendees to
   rival those in
   meetings while not significantly affecting the experiences of local attendees.

   After the tools
   attendees and WG chairs.

   This document differentiates between requirements that meet the have higher
   and lower priorities.  Higher-priority requirements in this document are
   deployed, there will probably intended to
   be delivered as soon as possible, but lower-priority requirements
   might be delivered later.  For example, a change in the participation in
   regular IETF meetings.

   o  Some people who would make an effort to come high-priority requirement
   might be "remote attendees must be able to know which slide is being
   discussed" and a particular IETF
      meeting related, lower-priority requirement might be more likely "remote
   attendees must be able to attend remotely.  Such a change
      will reduce see the number of local attendees, which speaker pointing to the slide with
   a laser pointer".  The eventual tools will both reduce be rolled out based on the amount
   priorities, making it likely that the IETF makes from registration fees and makes
      the informal gatherings during the IETF meeting less valuable
      because of the reduced networking effects.

   o  People who are active on WG mailing lists but not in the regular
      meetings are more likely to participate in the meetings remotely.
      Such a change might cause more effective meetings for WGs that are
      lagging in energy because more people will participate.  WG
      meetings that already have lots of participants will probably
      become busier.  Presentations on documents where none of the
      authors come to regular IETF meetings community will be much more likely to
      be given by the authors instead of by their proxies.

   o  If the tools make regular IETF meetings and interim meetings much learn more effective, the IETF might be able to reduce the number of
      regular meetings each year from three to two.  This would
      significantly reduce the impact of travel on regular IETF
      participants and make meeting planning much easier, but could
      significantly change the finances for the IETF and also reduce the
      amount of side-meeting value per year about
   additional requirements for participants. 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
   proposed will is currently required by the IETF procedures, such as the
   audio recordings that are put in the proceedings.  This document does
   not force a particular WG to mandate the use all of any particular tool by a WG, but such a
   requirement might be made by others, such as an Area Director
   requiring the features
   proposed. 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.

   Requirements in this document are numbered, such as "**Requirement
   03-00**".  In the IETF, there is an active (and never-ending) debate
   about what is a "requirement".  In the context of this document, a
   requirement is something that must appear in one of the iterations of
   the eventual RPS in order to support the mission of enabling useful
   remote participation in meeting sessions.

   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 future versions of the RPS.  For
   example, a requirement for the first version of the RPS might be
   "chairs must be able to specify which remote attendee can speak
   next", whereas a requirement for a later version of the RPS might be
   "chairs must be able to perform many or all chair duties at a regular
   IETF meeting while participating remotely". [[[ TODO: come up with a
   way to differentiate these two and start marking them as such. ]]]

   A functional specification is an approach to meeting one or more
   requirement.  For example, a requirement might be "chairs must be
   able to specify which remote attendee can speak next" and a
   function's specification associated with that requirement might be
   "floor control can be done through a stand-alone application or web
   form".  Functional specifications are called out in this document as
   "**Functional spec 03-00**".
   04-00**".

   The requirements and functional specifications covered in this document apply almost exclusively to
   tools and services that are used for remote participation in real-time 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 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 <https://www.ietf.org/mailman/listinfo/vmeet> for more
   information.

2.  Scenarios Required to be Supported

   The are many IETF-related activities that can be aided by remote
   participation tools.  The scenarios  Requirements for Supporting Remote Participation in which Regular IETF
    Meetings

   This section covers the RPS described requirements for effective remote
   participation in
   this document is expected to be used are:

   o  WG sessions at regular IETF meetings -- A typical where most members are in regular IETF
      meeting has about 150 sessions, with up to 8
   face-to-face meetings.  Some of those sessions
      happening at the same time.  A session might have between 20 and
      200 local attendees requirements in the room, and might this section
   overlap with those in Section 3, but many are unique to meetings that
   have only a few or many
      dozens large number of remote attendees.  WG sessions typically have one attendees physically present.

   **Requirement 04-01**: The specifications in the RPS MUST rely upon
   IETF and other open standards for all communications and interactions
   wherever possible unless there is an identified gap that cannot be
   met by those standards.

   **Requirement 04-02**: All tools in the RPS SHOULD be able to
      three co-chairs at be run
   on the front widest possible array of the room and computers.  The tools may be stand-
   alone applications, may be run from a series of
      individuals who come to modern web browser, or from the front
   command line.  The highest priority is that the tool need 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 be
   available on all of
      about 700 local attendees (at least) MacOS version 10.6 or later, Windows 7
   or later, and dozens 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 04-03**: Audio, video, instant messaging, and slide
   streams going to and from remote attendees SHOULD be delivered in as
   close to real-time as is practically possible.  When possible, the
   delivery SHOULD have delays of less than 200 milliseconds to remote attendees.  There
   attendees who are from 1 to 20 presenters; presentations may be made by multiple
      people.

   o  Face-to-face interim WG meetings -- Between regular IETF meetings,
      some WGs hold interim meetings where participants get together at
      a site (often a company's meeting room, but on fast Internet connections.  A common complaint
   with the current RPS is that the streaming audio can take more than
   10 seconds (and 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 as much as 30 seconds) to reach the remote attendees.  Presentations are common.

   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.

   o  IETF leadership meetings --
   attendee.  This causes many of the problems listed in Appendix A.4.1.

   **Requirement 04-04**: The IETF leadership (the IESG, IAOC,
      IAB, outgoing audio, video, and probably others) slide streams
   MUST have periodic virtual meetings, usually
      with the same delays so the remote attendee does not get
   confused during slide presentations.  These groups also meet at

   **Requirement 04-05**: All streaming information from the regular IETF
      meetings, RPS SHOULD
   be usable over Internet connections running at 56Kbps.  Many remote
   attendees will be in places with limited bandwidth.

   **Requirement 04-06**: Both local and sometimes have remote attendees at those meetings
      (such as members SHOULD be able
   to easily contact a single entity who cannot attend is available throughout the IETF
   meeting or presenters
      who are not part of the leadership group).

   [[[ TODO: Count the number if they find problems with any of f2f and virtual interims from the past
   few years. ]]]

3.  Interactions with Current RPS Tools Used by the IETF

   Users' experience with the current IETF tools vary widely.  Some
   participants think 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 04-07**: Any tools are fine and are grateful that they
   exist.  Other participants find them barely acceptable because they
   have are used better tools in other environments.  Often, by remote attendees
   MUST also be available to local attendees
   mostly forget that the as well.  At many IETF
   meetings, some local attendees act as remote attendees in WG meetings
   that they are participating until one
   gets something said not sitting in, so they can attend two WGs at the mic.  Local attendees don't have a feeling once.

2.1.  Registration for how many remote Remote Participation

   Remote attendees who make contributions to the IETF (as defined in
   [BCP78]) are just listening like most of bound by the
   local attendees.

   The variety of current experiences "Note Well" text.  By allowing registration
   before participating remotely, remote attendees can help inform the discussion of
   how to improve be better alerted
   to, and thus bound to, the tools.  The requirements here are derived from of contributors.  This is
   particularly important because it is easy in the
   current tools; later sections derive requirements IETF process to
   change from needs 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
   not at all met bound by the current tools.

   The IETF has years of experience with the two primary tools used "Note Well" text.

   **Requirement 04-08**: All remote attendees at
   its regular IETF meetings (Jabber for IM
   and streaming audio).  This
   section discusses some of interim meetings who make contributions MUST register with the reactions
   IETF Secretariat before contributing using any of users -- those in the
   meetings and those RPS tools.

   **Requirement 04-09**: Remote attendees who have participated remotely -- will only be listening
   and/or watching, but not making contributions, MUST NOT be required
   to the current
   tools.

3.1.  Technologies Currently Used at Regular IETF Meetings

   There are three tools that are used by register.

   **Requirement 04-10**: Registration for remote attendees for SHOULD be no
   more onerous than joining a WG
   participation at regular IETF meetings: real-time audio, instant
   messaging, and slides.

   For mail list.  Basically, the past few years, registrant
   should acknowledge the IETF has used audio streamed over HTTP
   over TCP.  TCP is often buffered Note Well, prove that they are at many places between (and in) the
   origination in the IETF meeting venue given
   email address, and receive confirmation that they are registered.
   The confirmation will also include any passwords needed for the users' computer.  At
   recent meetings, delays of around 30 seconds RPS
   tools.

   **Requirement 04-11**: The RPS tools (particularly the registration
   tool) MUST gracefully handle multiple attendees who have been recorded, with
   minimum delays typically being five seconds.  This delay the same
   name.

   The cost for remote attendees to register, if any, is caused not covered in
   this document but will instead be determined by
   buffering the IETF at a later
   time.  There are many ideas on the hop-by-hop ISPs subject (tiered costs for
   different services, no cost at all for the first year, and in others),
   but the remote attendee's
   computer.  At recent IETF meetings, remote attendance is almost
   always less than 10% effects of local attendance, and different cost structures is often less than 5%.
   (There are more remote attendees when beyond the IETF meeting is in the
   U.S.) Each stream scope of
   this document.

2.2.  Instant Messaging

   Instant messaging (IM) is represented by an MP3 playlist (sometimes called
   an "m3u file").

   The IETF long ago standardized on Jabber / XMPP ([RFC6120],
   [RFC6121], used both as a remote participation tool
   and others) as a communication tool for instant messaging used within local attendees at a regular meeting.
   Although the IETF. current tool's Jabber rooms (formally called "multi-user conferences" or "MUCs")
   exist for every WG, and those rooms are live all room is a good way to get
   questions to the time, not just
   during regular IETF meetings.  There 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 stable Jabber rooms useful for remote users to ask about the plenaries
   status of the room ("is anyone there?").

   **Requirement 04-12**: The IM system MUST allow anyone to see all
   messages in the WG's or BoF's room.

   **Requirement 04-13**: The IM system MUST allow any registered user
   to post messages in the WG's or BoF's room.

   **Requirement 04-14**: The date and certain other activities.  BoFs are usually
   assigned Jabber rooms before time that a regular meeting.

   Presentation slides normally are stored either as PDFs or message appears in one an
   IM stream MUST be retained.  IM clients MUST be able to show an
   indication of
   Microsoft's formats the date and time for PowerPoint.  They are projected on all messages.  Someone coming
   into a local
   screen from someone's laptop computer.

   There has been experience at recent meetings with two tools, WebEx
   and Meetecho, meeting late requires context for which are supported experimentally by messages in an instant
   messaging room are recent and which are old.

2.3.  Audio

   Audio from face-to-face meetings travels in two directions: from the IETF.  Each
   tool was used by a handful of WGs with mixed success.  The tools
   require
   room to remote attendees, and (potentially) from remote attendees to use specific clients, and installation of
   those clients caused problems for some people.  On the other hand,
   the tools have much more robust meeting control features, and
   participants appreciated the real-time showing room.  Comments on early drafts of slides during
   presentations.

3.2.  Locating this document indicated that
   the Meeting Information

   Finding information latter may not really be a requirement for the real-time audio, instant messaging, and
   slides all attendees if IM-
   to-mic is made predictable.  Given this, reliable IM-to-mic relay for an upcoming or current regular meeting
   comments to speakers is complicated by
   that information being in many different locations on the IETF web
   site, highest priority, audio from remote attendees
   giving presentations is a second priority, and audio from remote
   attendees giving comments to the fact that the relevant URLs can change before room is a third priority.

2.3.1.  Audio to Remote Attendees

   **Requirement 04-15**: Remote attendees MUST be able to hear what is
   said by local attendees and even
   during chairs at any mic in the meeting.  Further, a WG chair might copy the latest
   information and send it

   **Requirement 04-16**: Remote attendees SHOULD be able to hear the WG mailing list, but there can be
   later changes.  Experienced
   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 have gotten used to
   checking just before speak at the meeting itself, but even that does not
   always guarantee mic: in the correct information.

   Currently, Jabber room,
   they enter the meeting information appears in two different agendas:

   o  The official agenda on string "mic:" before their comment and hope that the IETF Datatracker includes links
   designated scribe or someone else goes to
      venue maps, WG charters, agendas, and Internet-Drafts.  For
      example, see
      <https://datatracker.ietf.org/meeting/82/agenda.html>.

   o  The unofficial "tools-style agenda" includes the same links as mic to relay the
      official agenda plus links
   comment.  This method works, but the current implementation has
   significant flaws described in that section.

   **Requirement 04-17**: Relay of messages from IM to the presentations, audio, minutes,
      Jabber room, and Jabber logs 9represnted mic MUST be
   able to happen as small icons).  For
      example, see <http://tools.ietf.org/agenda/82/>.

3.2.1.  Audio quickly as if the remote attendee was local.

   **Requirement 04-18**: The URL for person relaying from IM to the mic must be
   available throughout the audio stream for a WG or BoF meeting is based on meeting.  To date, this has been done by
   WG volunteers in the
   room that room.  In the meeting is in.  The audio streams are announced on future, it could be done the
   general IETF mailing list (ietf@ietf.org) before each meeting.

   A common complaint is 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 when a WG meeting moves allow copy-and-paste of text from
   IM to a different
   room, speech synthesizer that reads it to the room.

   **Requirement 04-19**: If multiple remote users need attendees want to know about comment
   at the move so that they can use same time, the proper URL person relaying from IM to hear the audio stream.  The room changes 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 often,
   but not always, announced on actually about improving WG mailing lists; when
   chairs, not the RPS tools, they are not
   announced, there is no easy way out of scope for this document.

2.3.3.  Audio for Presentations from Remote Attendees

   In order for a remote attendee to find out
   which audio stream they should be listening to.  Sometimes, room
   changes happen just as a WG presenter, their voice needs
   to be heard in the meeting room.  This functionality is starting, making it nearly
   impossible for a different
   than allowing remote attendee to know about the change attendees from giving comments (covered in streams.

3.2.2.  Instant Messaging

   The Jabber rooms used by WGs and BoFs do not change between IETF
   meetings, so finding
   Section 2.3.4) in that the right Jabber room is relatively easy.  Some
   Jabber clients have odd interfaces the WG chair needs much less floor control
   for joining Jabber rooms, and this
   can cause some problems; even though participants can test their
   Jabber clients before one speaker than for many.

   **Requirement 04-20**: A remote attendee giving a meeting, there still seems presentation MUST
   be able to have their speaking be some who
   need help just before a heard by all local and remote
   attendees.

   **Requirement 04-21**: A WG meeting.  There are sometimes problems
   with people joining Jabber rooms; in these cases, the participant
   needs chair MUST be able to find someone already in control the Jabber room to invite them to
   the discussion.

3.2.3.  Slides

   Slides are available sound
   coming from the meeting materials page.  Many, but
   certainly not all, local and a remote attendees know how to find attendee.  This control MUST allow reduction in
   volume, all the
   meeting materials page.

   It has become fairly common for presenters way to not have their
   presentations available for distribution until just before complete muting, of the WG
   meeting.  Because materials are uploaded by remote speaker.

   **Requirement 04-22**: Audible echo in the WG chairs, this often
   causes audio stream MUST be
   damped and/or eliminated by the beginning of WG meetings tools.  The RPS MUST recognize
   audible echo and automatically take measures to reduce it to be a dance involving
   presenters giving the chairs their slides, followed level
   which won't distract listeners.

   **Requirement 04-23**: The audio system used by chairs
   uploading the slides RPS MUST be able
   to integrate with systems commonly used in the venues used for IETF site, followed by the chairs saying
   "the slides are there now".

3.3.
   meetings.

2.3.4.  Audio from Remote Participation at IETF Meetings

3.3.1.  Remotely Speaking at Attendees to the Mic

   In order Room for a remote attendee to speak at Comments

   Note that the mic, requirements here assume a local attendee
   must say it for them.  In most WG and BoF meetings, this is done by very large change in the way
   that remote participation will happen.  Instead of a remote attendee
   typing something into the Jabber room for the meeting, and
   some local attendee going to the that someone will repeat at a
   mic and repeating what was typed
   into in the Jabber room.  Remote room, remote attendees often precede what they want
   said at will use their own mics to speak to
   the mic with meeting.  Some of the string "mic:" requirements from Section 2.3.3 will apply
   here as well.

   **Requirement 04-24**: Remote attendees MUST be able to differentiate speak
   directly to a meeting without going through a local attendee, and
   have their speaking be heard by local attendees.  (Note that from the
   rest of the discussion in
   ability to speak is controlled by the Jabber room.

   This method of participation often works adequately, but there are
   many places where it fails.  The following chair; see Section 2.3.4.1.)

   **Requirement 04-25**: Local attendees MUST be able to determine
   which remote attendee is speaking.

   **Requirement 04-26**: When a compendium of stories
   from recent IETF meetings and interim face-to-face meetings where
   remotely speaking at remote attendee connects to the audio
   stream to the room, their mic didn't work as well SHOULD start off muted.  This will
   prevent problems such as it could have.
   The participants 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 those common with WebEx where a remote
   attendee doesn't get Pete's attention until Pete realize that they can be heard.

   **Requirement 04-27**: A lower-priority requirement is already on slide 7
      and Pete doesn't want for remote
   attendees to go back.

   o  Rachel wants be able to say something, but Sam's Jabber client has crashed
      and no one else in the Jabber room knows why Sam isn't going speak to the mic.

   o  Robert wants to say something, but Sam is already at room by originating from the mic
      speaking
   PSTN.

2.3.4.1.  Floor Control for Rachel so Sam doesn't see Robert's message until he
      has gotten out of the mic line.

   o  Sam Chairs for Audio from Remote Attendees

   It is speaking not yet clear how the set of remote attendees would be treated
   for Robert, 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 Rachel wants being able to comment act on what
      Robert said.  Unless Sam reads the message as he is walking back
      to his seat, Rachel doesn't get order
   that remote attendees ask to speak.

   o  Robert wants to say something at

   Note that, if the mic, but Sam remote video to room requirements from
   Section 2.4.2 need to be met, it is having an
      important side discussion with the AD.

   o  Sam very likely that a related
   requirement to those below is also that "the audio and video floor
   controls must be in the minutes taker, same tool".

   **Requirement 04-28**: Remote attendees MUST have an easy and is too busy at
   standardized way of requesting the moment
      catching up with attention of the lively debate at chair when the mic
   remote attendee wants to relay speak.  The remote attendee MUST also be
   able to easily cancel an attention request.

   **Requirement 04-29**: The RPS MUST allow a remote attendee's request
   for attention to include an optional short text string.  A remote
   attendee might want to indicate that they are asking a question
      from Rachel.

   o  Chris thought Carl was watching the Jabber room, but Carl was
      reading of
   the draft presenter, or answering a question that is being discussed.

   o  Chris and Carl start someone else asked at the meeting by asking for volunteers
   mic, or want to take
      minutes and be Jabber scribe.  They couldn't find a Jabber scribe,
      and it took bring up a lot new topic.

   **Requirement 04-30**: Remote attendee's requests MUST be part 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
   floor control tool, not looking at in the Jabber room
      at instant messaging system.

   **Requirement 04-31**: The floor control portion of the time.

   o  Rachel asks RPS MUST give
   a question through Sam, and Pete replies.  Len, remote attendee who is
      next in line at the mic, starts talking before Sam has a chance allowed to
      see whether or not Rachel has a follow-up question.

   o  Robert makes speak a point about one of Pete's slides, clear signal when they
   should and Pete responds
      "I don't think you're looking should not speak.

   **Requirement 04-32**: The chair MUST be able to see all requests
   from remote attendees to speak at any time during the right slide" and continues
      with his presentation.  Robert cannot reply entire meeting
   (not just during presentations) in the floor control system.

   **Requirement 04-33**: The floor control system MUST allow a timely fashion
      due chair to the lag in the audio channel.

   o  Pete starts his presentation by asking for questions
   easily turn off and on an individual's ability to be held
      until speak over the end.  Robert has
   audio at any time.

   **Requirement 04-34**: The floor control system MUST allow a question about slide 5, and is
      waiting until the end of the presentation chair to post the question in
      the Jabber room.  After slide 7, Len jumps
   easily mute all remote attendees.

   **Requirement 04-35**: The floor control system MUST allow a chair to the mic and
      vehemently disagrees with something that Pete said.  Then Lee gets
      up
   easily allow all remote attendees to respond speak without requesting
   permission; that is, the chair MUST be able to Len, and easily turn on all
   remote attendees mics at once.

   **Requirement 04-36**: The floor control system for the three of them go chair MUST be
   able to be run by at it least two users at the same time.  It is common
   for a while, chair to leave the room, to have a side discussion with Lee getting up again after slide 10.  The presentation ends
      and is over time, so Carl says "we need an AD,
   or to move on", become a presenter.  They should be able to do so Robert
      never gets without
   having 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, do a handoff of the next speaker is...".

   o  Rachel comments on Pete's presentation though Sam. Sam doesn't
      understand what Rachel is asking, and Len goes floor control capability.

   **Requirement 04-37**: The RPS MUST authenticate users who can use
   the floor control system in a particular meeting using simple
   passwords.

   **Requirement 04-38**: The IETF Secretariat MUST be able to easily
   set up the mic individuals allowed to
      explain.  However, Len gets his explanation of what Rachel said
      wrong use the floor control system for a
   particular meeting and by to change the time Pete answers Len's interpretation, Rachel
      gives up.

   o  This is the first time Pete is presenting settings at an IETF meeting, and
      Robert has any time, including
   during the first question, which is relayed through Sam. Pete
      stays silent, not responding meeting.

   **Requirement 04-39**: The chair SHOULD be able to monitor the question.  Robert can't see
      Pete's face sound
   levels of the audio being delivered to know if Pete is just not understanding what he
      asked, is too afraid remote attendees to answer, be sure
   that they can hear what is just angry, or something else.

   o  Pete says something incorrect going on in his presentation, and Len asks the folks room.

2.4.  Video

   The IETF has experimented with one-way and two-way video at some
   meetings in the Jabber room about it.  Rachel figures out what
      Pete should past few years.  Remote attendees have said, and others said that
   seeing people 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 meetings gave them a better understanding of the presentation
   meeting; at a recent meeting, a remote presenter was wrong.

   o  Pete says something that able to see the AD sitting
   people in line at the front of the room
      (not near a mic) doesn't like, mic and the AD says a few sentences but
      doesn't go was better able to the mic. interact with them.
   The chairs try requirements for video from remote attendees to repeat what the AD says,
      get it only approximately right, but meeting rooms
   parallel the requirements for audio from 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 meeting
   rooms.  The IETF video may need to the mic, and gets tired of getting up
      and down all the time, and doesn't really agree integrate with Robert on a
      particular issue, so Sam doesn't relay a request the video systems
   at some meeting venues.

2.4.1.  Video from Robert.

   o  Rachel cannot join the Jabber room due Room to Remote Attendees

   **Requirement 04-40**: Remote attendees MUST be able to see the
   presenter at a client or server
      software issue.  She finally finds someone else on Jabber meeting.  A lower-priority requirement is that remote
   attendees SHOULD be able to see who is
      also speaking at the mics in the meeting, and gets them
   room.

   **Requirement 04-41**: Remote attendees MUST be able to invite her into see local
   attendees at any mic in the room.

3.3.2.  Remotely Presenting

   Some WGs meeting.

2.4.2.  Video from Remote Attendees to the Room

   Note that the requirements in this section have experimented with the same priorities
   as for audio for remote presentations at regular IETF
   meetings, with quite mixed results.  For some, it works fine: the (Section 2.3.3) and audio from
   remote presenter speaks, the chair moves attendees to the slides forward, and
   questions can be heard easily.  For others, it room for comments (Section 2.3.4).

   **Requirement 04-42**: When video is a mess: the local allowed for remote attendees can't hear to
   give presentations (as described in Section 2.3.3), the presenter very well, audience in
   the room SHOULD be able to see the presenter can't
   hear questions or there speaking.

   **Requirement 04-43**: When video is a long delay, and it was not clear when allowed for remote attendees for
   comments, the presenter was waiting floor management tool for input or there was a lag audio (as described in the sound.

   At a recent meeting that had a remote presenter, a WG had a
   Section 2.3.4.1) MUST also control video
   camera set up at the chairs' desk pointed towards as well.

   **Requirement 04-44**: The RPS MUST have the audience so
   that capability of showing
   video of the presenter could see remote attendee 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 is speaking over the room, which led audio to a lot of jokes
   and discussion of whether seeing the
   local attendees.

   **Requirement 04-45**: A remote presenter caused people
   to pay more attention.

   Remote presenters have commented how difficult it attendee who is speaking MUST be able
   to set up their
   systems, particularly because they are not sure whether their setup choose what is working until the moment they are supposed shown to be presenting.  Even
   then, the first few minutes local attendees: video of the presentation has them speaking, a feeling
   still picture of "is
   this really working?".

   [[[ TODO: More discussion about experiences with their face or avatar, or just their name.

   **Requirement 04-46**: The RPS MUST give a 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 attendee a bit harsh on WG chairs,
   the current tools do not give them clear
   indication when their video image or selected image is being shown to
   the kind of control over remote
   attendees that they have over local attendees.

2.5.  Slide Presentations and Distribution

   **Requirement 04-47**: The chairs can tell
   what is happening RPS MUST be able to handle both PDF and
   PowerPoint formats (".ppt" and ".pptx") for distributed slides.

   **Requirement 04-48**: The RPS MUST automatically convert PowerPoint
   presentations to PDF and make both available for distribution at the mics, but have much less view into what is
   happening
   same time.

   **Requirement 04-49**: Presenters MUST be able to update their slides
   on Jabber, even if they are watching the Jabber room.
   Without as much view, they cannot assist IETF site up to just before their presentation, if such update
   is allowed by the flow WG chairs.

   **Requirement 04-50**: Chairs MUST be able to approve or disapprove
   of any slide submission or updates, with the conversation
   as well.

   o  Carl sees default being that the Jabber room has an active and useful back-
      channel discussion during Pete's provocative presentation.  Pete
      finishes all
   submissions are allowed.

   In many current remote participation systems, slide presentations and asks for questions.  Lee
   the video coming from in-meeting cameras are sent as two separate
   streams (called the "slide stream" and Len rush 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 mic
      line, and it takes Robert a few seconds slide stream.  Separating the streams allows remote attendees to get his question into
   see the Jabber room slide stream and for Sam to go to the mic.  Carl tries to
      prioritize Sam forward camera streams in separate windows that
   can be independently sized.

   **Requirement 04-51**: The RPS MUST transmit the line, but Len gets upset when he
      does.

   o  Rachel asks a question, but Sam is not going to slide stream
   separately from the mic to relay
      it.  In fact, Sam has pretty much stopped paying attention.  Chris
      cannot do something about camera stream.

   **Requirement 04-52**: The slide stream MUST represent the situation without making Sam look
      bad.

   o  Pete has run over time, Robert asks what is supposed to be slides as
   they are projected in the
      last question, room, allowing the presenter to go back and Pete doesn't understand what Sam said.  Carl
      cannot tell whether
   forth, as well as to wait for Robert edit slides in real time.  This makes it clear
   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 which set of slides, and Chris try which slide number,
   is being currently shown.

   **Requirement 04-53**: When remote presentations are supported (see
   Section 2.3.3), the remote presenter SHOULD be able to get that person's attention
      over control the audio and Jabber, but
   slides.  This is a lower-priority requirement because this could be
   easily done by a local attendee listening to no avail.  The tool being used
      does not have the ability remote presenter.

2.6.  Shared Text Document Editing

   In some WG meetings, there is an attempt to mute individual participants, so edit a text document with
   input from the
      meeting local attendees.  This is disrupted until that person finally realizes that he typically done for proposed
   charter changes, but sometimes happens on a WG document or
      she the
   meeting's agenda.  This is not muted.

3.4.  Remote Participation at IETF Interim WG Meetings

3.4.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 controlled by usually unsuccessful, given the IETF Secretariat, amount of
   text and the ability to
   include remote attendees varies widely.  Some facilities size of what 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 displayed on the
   room was too soft to hear reliably.  Even if a face-to-face interim
   meeting screen.  In recent
   meetings, shared text document editing has good facilities been used for audio editing
   charters and slide presenting, it will
   probably have similar to regular IETF meetings.

3.4.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 taking minutes of WebEx meetings.

   An RPS tool for a few
   years, and some WGs have used different tools shared text document editing would be equally useful
   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, local 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 watching the in-room audio
   into 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 RPS
   screen because all of the small size of the the text.  This, in turn,
   means that local attendees are who aren't using their own computers for
   speaking to laptops at the group.

   One
   moment would not be able to participate by watching.

   **Requirement 04-54**: Shared real-time editing of the often-debated aspects text documents
   MUST be supported.  This system must allow at least three people to
   have write access and hundreds of virtual interim meetings is what
   time people to have them in order read access to make them available any
   particular document.

   **Requirement 04-55**: It MUST be easy to all
   participants.  Such scheduling of virtual interim meetings is out of
   scope for this start a new text shared
   document and to import existing text into a shared document.  However, it is noted that because many
   participants will

   **Requirement 04-56**: Remote attendees MUST be attending at different times able to be either the
   writers or the readers of day and night,
   no assumption can shared documents.

   **Requirement 04-57**: Those with read access MUST be able to see the
   edits made by those with write access within less that participants will five seconds
   after each edit.

   **Requirement 04-58**: It MUST be at an "office".
   This debate also affects face-to-face interim meetings because the
   meeting hosts normally will schedule easy to change the meeting permissions for
   who gets write access to a document during business
   hours at an editing session.

   **Requirement 04-59**: A much-lower priority requirement is the host company, but that might be terribly inconvenient
   ability for some WG members.

   [[[ TODO: More discussion about experiences with virtual interims.
   Focus on differences between group-editing of graphics.

2.7.  Archiving

   Archived recordings of the all-in-one systems like WebEx and events of the cobble-together systems where there is an audio feed with no
   floor control plus pre-distributed slideware. ]]]

4.  Requirements meetings are valuable for Supporting Remote Participation
   remote attendees who are not able to hear everything in Regular IETF
    Meetings

   This section covers real time.

   **Requirement 04-60**: The RPS MUST support storage and distribution
   of recordings of the requirements audio, video, and functional specification slide presentations for
   effective remote participation in meetings where some members are in
   regular IETF face-to-face all WG
   meetings.  Some

   **Requirement 04-61**: Transcripts of the requirements in this
   section overlap with those in Section 5, but many are unique to instant messaging for all
   meetings that have MUST be kept for distribution after IETF meetings.

   **Requirement 04-62**: The recordings and transcripts SHOULD be made
   available during the meetings, within a large number day of attendees physically present.

   There is an assumption in this section that the meeting chairs will
   continue them being made.

   **Requirement 04-63**: Users MUST be able to control easily find the flow archives
   of the discussion.  That is, if a
   presenter is speaking recordings and instant messaging transcripts of a remote attendee wants to ask particular
   WG or BoF session at a question,
   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. particular meeting.

   **Requirement 03-01**: 04-64**: The specifications RPS SHOULD rely upon IETF support indexing of archived
   audio and
   other open standards video for all communications and interactions wherever
   possible.

   **Requirement 03-02**: All tools particular events in the RPS SHOULD be able to be run
   on the widest possible array of computers. meetings such as when
   speakers change.

   **Requirement 04-65**: The tool may be a stand-
   alone application, from any modern web browser, or from the command
   line, but needs to be available on all of (at least) MacOS version
   10.6 or later, Windows 7 or later, and any common Linux distribution
   produced in 2010 or later.  This also means that the tools RPS MUST NOT
   rely on Adobe Flash to work correctly. [[[ TODO: Do we need to
   include IOS support recording and Android platforms in that list? ]]]
   **Requirement 03-03**: Audio, storage of
   recordings of the audio, video, instant messaging, and slide
   streams going to and from remote attendees SHOULD be delivered in presentations of interim
   meetings as
   close to real-time well as is practically possible.  A common complaint
   with the current RPS is regular IETF meetings.

   **Requirement 04-66**: Given that interim meetings are run without
   the streaming audio can take more than
   10 seconds (and sometimes as much as 30 seconds) to reach the remote
   attendee.  This causes many help of the problems listed in Section 3.3.1.

   [[[ TODO: Proposed replacement IETF Secretariat, making these recordings MUST be
   easy for this requirement WG chairs.

2.8.  Polling

   The common IETF method of assessing support is "Delays a straw poll,
   sometimes managed by audible humming, sometimes by raising hands.

   **Requirement 04-67**: A system for yes/no/abstain polling meeting
   attendees, including remote attendees at the same time, MUST be less than X milliseconds greater than the network delay
   provided.  It MUST be easy to the
   remote attendee."  Two values set up a simple poll, and it must be
   easy for X have been proposed: 200 all local and 500.
   ]]]

   [[[ TODO: A possibly different way remote attendees to set find the poll and
   participate.  Note that this would add a requirement is "The
   audio MUST achieve that everyone in
   a MOS (Mean Opinion Score) of 3.5 or better."  And
   there should probably meeting be a discussion of a possible equivalent for
   video.  A proposal was "320x240 @ 15fps". ]]]

   **Requirement 03-04**: The outgoing audio, video, and slide streams
   MUST have the same delays so using their computer to participate in the remote participant does not get
   confused during slide presentations. poll.

2.9.  Plenaries

   **Requirement 03-05**: All streaming information from the RPS MUST be
   usable over slow Internet connections.  Many remote 04-68**: Remote attendees will SHOULD be
   in places with limited bandwidth. [[[ TODO: We need able to define "slow"
   here, or drop the requirement.]]]

   **Requirement 03-06**: All proposed tools MUST detail make
   comments at the bandwidth
   required for each participant for various levels of participation
   (audio-only, mic approximately as well as if they were local
   attendees.  This means that either remote audio and video, and so on).

   [[[ TODO: Is there a requirement for PSTN for audio-only? ]]] to the plenary room
   speakers be available, or that IM-to-room relay be available.

   **Requirement 03-07**: Audible echo 04-69**: Transmitting real-time transcription of
   plenary speakers to remote attendees MUST be supported.  The lag in the audio stream
   transmission MUST be
   damped and/or eliminated less than five seconds.

2.10.  Use by IETF Leadership

   The requirements for bodies like the tools. [[[ TOOD: Proposed
   replacement: the RPS MUST recognize audible echo IESG and automatically
   take measures IAB to reduce it use the RPS
   during regular IETF meetings are similar to those of most WGs.  The
   main difference is that they need a level which won't distract listeners.
   ]]] way to limit who can participate
   remotely.

   **Requirement 03-08**: WG chairs 04-70**: The chair or meeting facilitator MUST be able
   to test whether or not
   the easily limit remote access of all tools (both 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). listening/
   observing and contributing) to meetings on a room-by-room basis.

   **Requirement 03-09**: There MUST 04-71**: The IETF Secretariat must be written operational
   documentation for each RPS 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.

2.11.1.  Preparation for WG Chairs

   **Requirement 04-72**: 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 04-73**: 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 03-10**: 04-74**: There SHOULD be training materials for WG
   chairs in how to use the RPS tools.

4.1.  Registration for Remote Participation

   **Requirement 04-75**: There has been periodic discussion of whether or not remote attendees
   are bound by SHOULD be a tool that allows a WG chair
   to prepare each tool that will be used in their WG meeting.  Such a
   tool would let the "Note Well" text WG chair specify which RPS tools they will use.

   **Requirement 04-76**: There SHOULD be a custom checklist for each WG
   that local attendees are bound to. helps the chair prepare for their meeting.  The core question is which local and remote attendees are
   "contributors" based on checklist would
   enumerate the definitions in [BCP78].  By requiring
   registration steps needed before participating, remote attendees can be better
   alerted to, and thus hopefully bound to, the requirements of
   contributors.

   The cost for remote attendees meeting begins, to register, if any, is not covered in
   this document but will instead be determined by start the IETF at a later
   time.  There are many ideas on
   meeting, during the subject (tiered costs for
   different services, no cost at all for meeting, to close the first year, meeting, and others),
   but the effects of different cost structures is beyond the scope of
   this document. after a
   meeting.

2.11.2.  Preparation for Remote Attendees

   **Requirement 03-11**: All remote 04-77**: Remote attendees MUST register with the
   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 easily find
   all the IM
   system. [[[ TODO: Should this be split into "unregistered people can
   listen material they need to effectively participate, including
   links to audio, video, instant messaging, slides, and read, but not contribute"? ]]]

   **Functional spec 03-01**: The RPS so on.  This
   material MUST have a system where a be available well before the time of the meeting.  The
   page with the meeting material SHOULD allow the remote attendee can register their name to
   easily perform a time conversion to and have that name be used in from the local time at the
   instant messaging and video systems.  Registration must only need to
   be done once for an entire regular
   IETF meeting.

   **Requirement 03-12**: A remote attendee may register 04-78**: There MUST be a nickname constantly-running testing
   service that
   will covers all interactive tools (audio, video, slide
   display, and so on) for at least a week before the meeting begins.
   Remote attendees need to be shown able to other attendees during test the meeting.  A remote
   attendee must register with participation
   setup before a "verified" name with the IETF
   Secretariat.  The nickname will appear in video regular meeting, and instant
   messaging.  [[[TODO: Is this anonymity appropriate in light of even during the
   "note well" and floor control requirements? ]]] meeting.

   **Requirement 03-13**: 04-79**: The RPS tools (particularly the registration
   tool) testing service MUST gracefully handle multiple attendees who have the same
   name.

   **Functional spec 03-02**: 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 run throughout the
   meeting period. so that last-minute joiners can test their systems.

   **Requirement 04-80**: The registration system testing service SHOULD remind all registered allow remote
   attendees
   at the end of the week to update also test whether their notations.

4.2.  Audio

   Audio from face-to-face meetings travels in two directions: from the
   room to remote attendees, outgoing audio, video, and from remote attendees to the room. slide
   control works.

   **Requirement 04-81**: A few requirements come from the IETF's current use of audio in
   meetings.  Meeting rooms have many mics: remote attendee who starts using one or two for the chairs,
   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
   the room and in the audience.

   **Requirement 03-14**: Remote attendees
   tools after a meeting has begun MUST be able to hear tell what is
   said by local attendees and chairs at any mic
   happening in the meeting.

   Comments on early drafts of this document indicated that  In specific, there MUST be an indication
   if the latter
   may meeting has not really be a requirement for all participants started, if IM-to-mic the meeting is
   made predictable.  The two options are split below to make happening (even if
   there is silence on the
   discussion clearer.  Note that even mics), and if the consensus meeting is towards IM-
   to-mic, remote-to-room might still be required to enable remote
   presenters; over.

3.  Requirements for Supporting Remote Participation in Interim Meetings

   One of the goals of this case, there would probably be little need for
   floor control.  The requirements for audio are expected document is to be
   important discussion points in future versions increase the effectiveness of this document.

   [[[ TODO: Should
   interim meetings.  Interim meetings are now uncommon, but might
   become more common (and more effective) if the ability to dial into a meeting stream via POTS
   be remote participation
   becomes more useful.

   The requirements for meetings that are all remote (that is, with no
   local attendees) are mostly a requirement? ]]]

4.2.1.  IM-to-Mic Relay subset of Comments from Remote Participants

   As described in Section 3.3.1, the current tools support an informal
   method requirements for remote attendees to speak at the mic:
   participation in the Jabber room,
   they enter "mic:" before their comment a regular IETF meetings and hope that the designated
   scribe or someone else goes to the mic to relay face-to-face interim
   meeting.

   **Requirement 04-82**: The RPS SHOULD have a central location where
   the comment. specifics about how remote participation is supported for every
   WG interim meeting.  This
   method works, but has significant flaws described in that section.

   **Requirement 03-15**: Relay of will reduce the problems often seen where
   messages from IM about how to participate in an interim meeting get buried in
   the mic MUST
   happen as quickly as if WG mailing list.

   **Requirement 04-83**: There SHOULD be documentation and training for
   the remote attendee was local. RPS tools specifically targeted at WG chairs who will lead
   interim meetings.

   **Requirement 03-16**: 04-84**: The person relaying from IM to RPS tools MUST be at least partially
   usable at face-to-face meetings other than regular IETF meetings.
   The number of the mic must tools that might be available throughout the WG meeting.  This could will be facilitated by
   hiring people to attend meetings different for
   different venues for the specific purpose of being
   IM-to-mic scribes.

   **Requirement 03-17**: If multiple remote attendees want to comment virtual interims, but at a minimum, the same time, the person relaying from IM to the mic
   following MUST be able
   to relay supported for all of them.

   Note: during the development of remote attendees:

   o  Registration

   o  Room audio

   o  Instant messaging

   o  Slide distribution

   o  Slide presentation

   o  Shared document editing

4.  IANA Considerations

   None. [[ ...and thus this document, there have been many
   suggestions for how WG chairs section can better manage be removed before publication
   as an RFC... ]]

5.  Security Considerations

   People who participate remotely in face-to-face IETF meetings might
   expect the IM-to-mic
   relaying (for example, with planned pauses, better tracking same level of the IM
   room, and so on). privacy as they have when they participate
   directly in those meetings.  Some of those suggestions the proposed tools might turn into
   requirements cause
   it to be included in this document, but so far most of them
   seem easier to be really about improving WG chairs, not the know which WGs a remote attendee was following.
   When RPS tools.

4.2.2.  Audio from Remote Participants to the Room

   Note that tools are deployed, the requirements here assume a very large change in IETF should describe the way
   that remote participation will happen.  Instead privacy
   implications of using such a remote attendee
   typing something into tool to the Jabber room users so they can decide
   whether or not to use the tools.

   The eventual RPS tools will have some user authentication that someone will repeat at
   associate people with actions.  For example, a
   mic in the room, remote attendees will use their own mics user might need
   to speak authenticate to the meeting.

   **Requirement 03-18**: Remote attendees MUST be able to speak
   directly system in order to give a meeting without going through presentation or
   speak during a local attendee, and
   have their speaking be heard by local attendees.  (Note that the
   ability session.  The credentials needed for this
   authentication will need to speak is controlled by the chair; see Section 4.2.2.1.)

   **Requirement 03-19**: Local attendees MUST be able to determine
   which remote attendee is speaking.  If the remote attendee is using managed in a
   nickname (see Requirement 03-12), that nickname can be used secure fashion, both by
   the
   remote speaker.

   **Requirement 03-20**: The floor control portion of the RPS MUST give
   a remote attendee who is allowed to speak a clear signal when they
   should and should not speak.

   **Requirement 03-21**: The audio system used and by the RPS MUST be able
   to integrate with systems commonly used people who are being identified.

6.  Acknowledgements

   Many of the ideas in this document were contributed by members of the venues used for
   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 meetings happen 83 in venues such as hotels and
   conference centers, most Paris.

   Some 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 not be reliably heard text in this document originated in the request for
   proposals that was issued by local participants.

   **Requirement 03-22**: When a remote attendee connects to the audio
   stream IAOC that led 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 03-23**: Remote participants MUST be able this document.

7.  Informative References

   [BCP78]    Bradner, S. and J. Contreras, "Rights Contributors Provide
              to unmute
   themselves; unmuting MUST NOT require interaction from the chair.

4.2.2.1.  Floor Control IETF Trust", BCP 78, RFC 5378, November 2008.

   [RFC2119]  Bradner, S., "Key words for Chairs 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 Audio from Remote Attendees

   Newcomers to regular Participation Services", 2011, <http://
              iaoc.ietf.org/documents/
              RPS-Specifications-RFP-2011-10-19.pdf>.

Appendix A.  Background on IETF meetings often expect the floor control in
   WG meetings Remote Participation

   The IETF has a long history of using remote participation tools.
   This history causes many IETF participants 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 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 mics after
   common perceptions of the chair has closed current tools so that the line, why some people ignore presenters' requests to hold
   questions to reader
   understands what might be expected of future tools.

   Users' experience with the end, current IETF tools vary widely.  Some
   participants think the tools are fine and so on.  Mixing remote attendees into this
   social structure will be a daunting task, but one are grateful that has been dealt
   with they
   exist.  Other participants find them barely acceptable because they
   have used better tools in many remote participation systems.

   It is not yet clear how other environments.  Often, local attendees
   mostly forget that the set of remote attendees would be treated
   for queueing.  Some tools are participating until one
   gets gets reminded, such as by something said at the mic.  Local
   attendees don't have each remote attendee being considered
   separately, while others pool all a feeling for how many remote attendees into one group.
   This affects are just
   listening like most of the chair knowing and being able to act on local attendees.

   The variety of current experiences can help inform the order
   that remote attendees ask discussion of
   how to speak.

   Note that, if improve the remote video to room requirements tools.  The experiences described in this appendix
   are derived from
   Section 4.3.2 need to be met, it the current tools.  It is very likely that a related
   requirement important to note that
   people who attend IETF meetings often experience the tools quite
   differently than those below is who participate remotely.

   The IETF has years of experience with the three primary tools used at
   its regular meetings: prepared slides that "the audio are distributed before and video floor
   controls must be in
   during the same tool".

   **Requirement 03-24**: Remote attendees MUST have an easy meeting, Jabber for IM, and
   standardized way streaming audio.  This section
   discusses some of requesting the attention reactions of users -- those in the chair when the
   remote attendee wants meetings and
   those who have participated remotely -- to speak.  The remote attendee MUST also be
   able to easily cancel an attention request.  (Note that Requirement
   03-62 implies that someone is watching the request queue, something
   that does not happen consistently with the current tools.)

   **Functional spec 03-03**: The RPS MUST allow a remote attendee's
   request for attention to include an optional short text string.  A
   remote attendee might want to indicate that they are tools.

   Remote attendees typically participate by asking a
   question of the presenter, questions or answering a question that someone else
   asked at the mic, making
   statements during or want to bring up a new topic.

   **Functional spec 03-04**: Remote attendee's requests MUST be part of
   the floor control tool, not after presentations, and they also participate
   in discussions in the instant messaging system.

   **Requirement 03-25**: The chair MUST channel.  Local attendees who
   are using the RPS typically don't participate "remotely": they are
   using the tools to be able to see all requests
   from remote attendees what is happening in different
   rooms when they need to speak be two or more places at any time during once.

A.1.  How the entire IETF Meets

   o  WG sessions at regular IETF meetings -- A typical regular IETF
      meeting
   (not just during presentations) in the floor control system.

   **Requirement 03-26**: The floor control system MUST allow a chair has about 150 sessions lasting one to
   easily turn off two and on an individual's ability one half
      hours each, with up to speak over the
   audio 8 of those sessions happening at any the same
      time.

   **Requirement 03-27**: The floor control system MUST allow  A session might have between 20 and 200 local attendees in
      the room, and might have only a chair to
   easily mute all few or many dozens of remote
      attendees.

   **Requirement 03-28**: The floor control system MUST allow a chair to
   easily allow all remote attendees  WG sessions typically have one to speak without requesting
   permission; that is, three co-chairs at
      the chair MUST be able front of the room and a series of individuals who come to easily turn on all
   remote attendees mics at once.

   **Requirement 03-29**: The floor control system for the chair MUST be
   able
      front to be run present; some presentations are made by small panels.

   o  Plenaries at least regular IETF meetings -- There are usually two users
      plenaries at the same time.  It is common
   for a chair to leave the room, to have a side discussion regular IETF meeting, with an AD,
   or on-site attendance of
      about 700 local attendees and dozens of remote attendees.  There
      are from 1 to become a presenter.  They should 20 presenters; presentations may be able to do so without
   having to do 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 handoff group of the floor control capability.

   **Functional spec 03-05**: The RPS MUST authenticate users who can
   use the floor control system WG meetings.  Remote
      attendees may want to participate in the other parts of a particular regular
      meeting using simple
   passwords.

   **Requirement 03-30**: The as well.

   o  Face-to-face interim WG meetings -- Between regular IETF Secretariat MUST be able to easily
   set up the individuals allowed to use the floor control system for meetings,
      some WGs hold interim meetings where attendees get together at a
   particular
      site (often a company's meeting and to change the settings room, but sometimes a meeting room
      rented at any time, including
   during the meeting. [[[ TODO: Should those who a hotel).  At such meetings, there 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 between a remote attendee who is speaking
   loses network connectivity?  If so, maybe this can be shown to the
   chair. ]]]

   **Requirement 03-31**: The chair SHOULD be able to monitor the sound
   levels handful
      and a few dozen local attendees and a similar number of the audio being delivered to 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 to be sure
   that they can hear what because there is going on in the room.

4.3.  Video

   The RFP that preceded the current document, [RPS-RFP], discusses
   video as 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 requirement. year.

   o  IETF leadership meetings -- The IETF has experimented leadership (the IESG, IAOC,
      IAB, and probably others) have periodic virtual meetings, usually
      with one-way presentations.  These groups also meet at the regular IETF
      meetings, and
   two-way video sometimes have remote attendees at some those meetings in
      (such as members who cannot attend the past few years.  Remote
   attendees have said that seeing people in IETF meeting or presenters
      who are not part of the meetings gave them a
   better understanding leadership group).

   The form of "presentations" changes from meeting to meeting, but
   almost always includes prepared static slides and audio of the meeting; at a recent meeting,
   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
   presenter was able to see the people in line attendees for WG
   participation at the mic regular IETF meetings: real-time audio, instant
   messaging, and was
   better able to interact with them. [[[ TODO: determine how much of
   this is needed for effective participation. ]]]

4.3.1.  Video from slides.

   For the Room to Remote Participants

   **Requirement 03-32**: Remote attendees MUST be able to see past few years, the
   presenter at a meeting.

   **Requirement 03-33**: Remote attendees MUST be able to see local
   attendees IETF has used audio streamed over HTTP
   over TCP.  TCP is often buffered at any mic many places between (and in) the
   origination in the meeting.

   [[[ TODO: Is there a requirement that IETF video integrate with the meeting venue video, if any? ]]]

4.3.2.  Video from Remote Participants to and the Room

   Note that 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 requirements hop-by-hop ISPs and in this section probably only apply if
   there is consensus that audio from remote participants to the room remote attendee's
   computer.  At recent IETF meetings, remote attendance is
   required.  If so, there will probably also be requirements for video
   floor control as well.

   **Requirement 03-34**: The RPS MUST have the capability of showing
   video almost
   always less than 10% of the remote attendee who local attendance, and is speaking over often less than 5%.
   (There are more remote attendees when the audio to IETF meeting is in the
   local attendees.

   **Requirement 03-35**: A remote attendee who
   U.S.) Each stream 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 03-36**: The RPS MUST give a remote attendee a clear
   indication when their video image is being shown to the local
   attendees.

   [[[ TODO: represented by an MP3 playlist (sometimes called
   an "m3u file").

   The way to fulfill these might be that the IETF provide a
   laptop long ago standardized on Jabber / XMPP ([RFC6120],
   [RFC6121], and others) for instant messaging used within the chair 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 has are
   available during IETF meetings.  There are also stable Jabber rooms
   for the right tools on it, plenaries and that 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
   is computer.  Proceedings are currently
   stored as PDF of the one connected 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 projector. ]]]

4.4.  Instant Messaging

   Instant messaging (IM) is IETF.  Each
   tool was used both as by a handful of WGs with mixed success.  The tools
   require remote participation tool attendees to use specific clients, and as a communication tool installation of
   those clients caused problems for local attendees at a regular meeting.
   As noted earlier, while some people.  On 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 other hand,
   the room are participating in.
   This document does not address how to prevent that problem (or
   whether it really is tools have much of a problem).  The instant messaging
   system is also useful for remote users to ask about more robust meeting control features, and
   attendees appreciated the status real-time showing of slides during
   presentations.

A.3.  Locating the
   room ("is anyone there?").

   **Requirement 03-37**: The IM system MUST allow anyone to see all
   messages in Meeting Information

   Finding information for the WG's real-time audio, instant messaging, and
   slides for an upcoming or BoF's room.

   **Requirement 03-38**: The IM system MUST allow any registered user
   (even those registered to use anonymous names) to post messages current regular meeting is complicated by
   that information being in many different locations on the WG's or BoF's room.

   **Requirement 03-39**: The date IETF web
   site, and time the fact that a message appears in an
   IM stream MUST be retained.  IM clients MUST be able to show an
   indication of the date relevant URLs can change before and time for all messages.  Someone coming
   into even
   during the meeting.  Further, a meeting late requires context for which messages in an instant
   messaging room are recent WG chair might copy the latest
   information and which are old.

   [[[ TODO: Should send it to the WG mailing list, but there can be multiple rooms for a meeting?  There were
   many requests for a separate "speak into
   later changes.  Experienced remote attendees have gotten used to
   checking just before the mic" room, meeting itself, but even that is does not needed if
   always guarantee the requirements in Section 4.2.2 are met.  Is there a
   need for other rooms? ]]]

   [[[ TODO: Should non-registered people be allowed to read the IM
   traffic in real time, given that anyone can register anonymously?
   Should people registered anonymously be allowed to post in IM rooms?
   Should non-registered attendees be able to post to correct information.

   Currently, the IM rooms? ]]]

4.5.  Slide Presentations

   Slides are presented meeting information appears in regular IETF meetings with projectors two different agendas:

   o  The official agenda 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 IETF Datatracker includes links to remote
   attendees,
      venue maps, WG charters, agendas, and Internet-Drafts.  For
      example, see
      <https://datatracker.ietf.org/meeting/82/agenda.html>.

   o  The unofficial "tools-style agenda" includes the slides being projecte need to also be sent same links as a stream the
      official agenda plus links to the remote attendees.

   In many current remote participation systems, slide presentations presentations, audio, minutes,
      Jabber room, and
   the video coming from in-meeting cameras are sent Jabber logs 9represnted as two separate
   streams (called small icons).  For
      example, see <http://tools.ietf.org/agenda/82/>.

A.3.1.  Audio

   The URL for the "slide stream" and audio stream for a WG or BoF meeting is based on the "camera stream").
   room that the meeting is in.  The
   slide stream audio streams are announced on the
   general IETF mailing list (ietf@ietf.org) before each meeting.

   A common complaint is usually much lower bandwidth than that when a WG meeting moves to a different
   room, remote users need to know about the camera stream, move so remote attendees with limited bandwidth that they can choose use
   the proper URL to watch just hear the slides audio stream.  The room changes are often,
   but not the local attendees.  Further, separating the
   streams allows remote attendees to see the slide stream and the
   camera streams in separate windows that can be independently sized.

   **Functional spec 03-06**: The RPS MUST transmit the slide stream
   separately from the camera stream.

   **Requirement 03-40**: The slide stream MUST represent the slides as always, announced on WG mailing lists; when they are projected in the room, allowing the presenter to go back and
   forth, as well as to edit slides in real time.

   **Requirement 03-41**: It MUST be made clear to the not
   announced, there is no easy way for a remote attendees
   which set of slides, and attendee to find out
   which slide number, is being currently
   shown.

   [[[ TODO: If the slides will audio stream they should be visible to remote attendees listening to.  Sometimes, room
   changes happen just as they
   are presented, is there a requirement that presenters be able to use
   the equivalent of WG meeting is starting, making it nearly
   impossible for a laser pointer? ]]]

4.6.  Slide Distribution

   Slides are available to local and remote attendees on attendee to know about the change in streams.

   IETF
   servers before meetings happen in venues such as hotels and during regular conference centers,
   most of which have their own audio setups.  The IETF meetings.  This service is
   useful to Secretariat
   contracts with those venues for the use of some or all of their audio
   system.  Without such integration, audio from remote attendees who want to might
   not be prepared for WG meetings. reliably heard by local attendees.

A.3.2.  Instant Messaging

   The
   slides are not only Jabber rooms used by remote attendees listening to WGs and BoFs do not change between IETF
   meetings, so finding the WG
   meeting; it right Jabber room is common for local 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 at from the front of the room.

   **Functional spec 03-07**: The RPS MUST be able to handle both PDF
   and PowerPoint formats (".ppt"

   Slides are available from the meeting materials page.  Many, but
   certainly not all, local and ".pptx") for distributed slides.
   [[[ TODO: Is there a requirement remote attendees know how to support other formats? ]]] [[[
   TODO: For find the distributed slides, is there a requirement that
   animation in PowerPoint be supported, or just static slides? ]]]

   **Functional spec 03-08**: The RPS MUST automatically convert
   PowerPoint presentations
   meeting materials page.

   It has become fairly common for presenters to PDF and make both not have their
   presentations available for distribution at until just before the same time.

   **Requirement 03-42**: Presenters MUST be able WG
   meeting.  Because materials are uploaded by the WG chairs, this often
   causes the beginning of WG meetings to update be a dance involving
   presenters giving the chairs their slides, followed by chairs
   uploading the slides
   on to the IETF site up to just before their presentation, if such update
   is allowed site, followed by the chairs.

   **Requirement 03-43**: Chairs MUST 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 able 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 approve or disapprove
   of any slide submission or updates, with the default being that all
   submissions are allowed.

4.7.  Shared Document Editing

   In mics after the chair has closed
   the line, why some WG meetings, there is an attempt people ignore presenters' requests to edit hold
   questions to the end, and so on.  Mixing remote attendees into this
   social structure will be a document daunting task, but one that has been dealt
   with
   input from in many remote participation systems.

   In order for a remote attendee to speak at the mic, a local attendees.  This is typically done attendee
   must say it for proposed
   charter changes, but sometimes happens on a them.  In most WG document or the
   meeting's agenda.  This and BoF meetings, this is usually unsuccessful, given done by
   the amount of
   text remote attendee typing into the Jabber room for the meeting, and
   some local attendee going to the size of mic and repeating what can be displayed on was typed
   into the screen. 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 recent
   meetings, shared document editing has some WGs, there have been used for editing charters
   and for taking minutes experiments of meetings.

   An RPS tool for shared document editing would be equally useful for
   local and getting remote attendees watching
   voices into the edits happen in real-time.
   There is a good chance that this tool would be watched room either by local
   attendees on their laptops instead of being projected on hooking into the screen
   because of room's sound system
   or pointing a mic at the small size speaker of the the text.  This, in turn, means a laptop.  This sometimes works,
   but sometimes has bad feedback and delay issues that
   local attendees who aren't using make the remote
   participation worse than having a person reading their laptops comments at
   the moment would
   not be able to participate by watching.

   **Requirement 03-44**: mic.

   The "Jabber-to-mic" method of participation often works adequately,
   but there are many places where it fails.  It MUST be easy has issues similar to start
   most proxy approaches where a new shared document
   and to import existing text into human is in center of the loop.  The
   following is a shared document.

   **Requirement 03-45**: Shared real-time editing compendium of text-only
   documents MUST be supported.  This system must allow stories from recent IETF meetings and
   interim face-to-face meetings where remotely speaking at least three
   people the mic
   didn't work as well as it could have.  The list is given here to have write access both
   point out what some WGs are willing to put up with currently, and hundreds of people to have read
   access to any particular document.

   **Requirement 03-46**: Remote attendees MUST be able to be either the
   writers or the readers of shared documents.

   **Requirement 03-47**: Those with read access MUST be able to see the
   edits made by those with write access within less that five seconds
   after each edit.

   **Requirement 03-48**: It MUST be easy to change the permissions for
   who gets write access to a document during an editing session.

   [[[ TODO: Is this also needed for non-text documents?  If so, in
   show what
   formats?  For example, is drawing on a whiteboard needed? ]]]

4.8.  Archiving

   Archived recordings of needed if the events eventual RPS uses Jabber-to-mic as part of
   the meetings are valuable for
   remote solution.  The attendees who are not able to hear everything in real time.

   **Requirement 03-49**: The RPS MUST support storage Chris and distribution
   of recordings of the audio, video, 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 presentations for all WG
   meetings.

   **Requirement 03-50**: Transcripts of the instant messaging for all
   meetings MUST be kept for distribution after IETF meetings.

   **Requirement 03-51**: The recordings 5, but
      Sam doesn't get Pete's attention until Pete is already on slide 7
      and transcripts SHOULD be made
   available during 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 meetings, within a day of them being made.

   **Requirement 03-52**: Users MUST be able Jabber room knows why Sam isn't going to easily find
      the archives
   of mic.

   o  Robert wants to say something, but Sam is already at the recordings and instant messaging transcripts of a particular
   WG or BoF session at a particular meeting.

   **Requirement 03-53**: The RPS SHOULD support indexing of archived
   audio and video mic
      speaking for particular events in meetings such as when
   speakers change.

   **Requirement 03-54**: The RPS MUST support recording and storage of
   recordings Rachel so Sam doesn't see Robert's message until he
      has gotten out of the audio, video, mic line.

   o  Sam is speaking for Robert, and slide presentations of interim
   meetings as well Rachel wants to comment on what
      Robert said.  Unless Sam reads the message as regular IETF meetings.

   **Requirement 03-55**: Given that interim meetings are run without he is walking back
      to his seat, Rachel doesn't get to speak.

   o  Robert wants to say something at the help of mic, but Sam is having an
      important side discussion with the IETF Secretariat, making these recordings MUST be
   easy for WG chairs.

4.9.  Transcription

   **Requirement 03-56**: 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 AD.

   o  Sam is a straw poll,
   sometimes managed by audible humming, sometimes by raising hands.

   **Requirement 03-57**: A system for polling meeting participants,
   including remote attendees also the minutes taker, and is too busy at the same time, MUST be provided.  It
   MUST be easy to set moment
      catching up a simple poll, and it must be easy for all
   participants with the lively debate at the mic to find relay a question
      from Rachel.

   o  Chris thought Carl was watching the poll and participate.  Note Jabber room, but Carl was
      reading the draft that this would
   add a requirement that everyone in a is being discussed.

   o  Chris and Carl start the meeting be using their computer by asking for volunteers to participate in the poll. [[[ TODO: Should the RPS also provide take
      minutes and be Jabber scribe.  They couldn't find a
   tool that allows yes / no / abstain indications, which comes Jabber scribe,
      and it took a lot
   closer of begging to "voting" than currently get someone to take minutes, so
      they figured that was the best they could do.

   o  Sam is common? ]]]

4.11.  Plenaries

   At recent IETF meetings, there also a presenter, and Robert has been very little input from remote
   attendees even when there a question about Sam's
      presentation, but Sam is obviously not looking at the Jabber room
      at the time.

   o  Rachel asks a lot question through Sam, and Pete replies.  Len, who is
      next in line at the room, but that may be due mic, starts talking before Sam has a chance to the current setup,
      see whether or not lack Rachel has a follow-up question.

   o  Robert makes a point about one of interest.

   **Requirement 03-58**: Remote attendees SHOULD be able to make
   comments Pete's slides, and Pete responds
      "I don't think you're looking at the mic approximately as well as if they were local
   attendees.  This means that either remote audio right slide" and continues
      with his presentation.  Robert cannot reply in a timely fashion
      due to the plenary room
   speakers be available, or that IM-to-room relay be available.

   [[[ TODO: Are there other requirements that are special lag in the audio channel.

   o  Pete starts his presentation by asking for questions 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 be held
      until the IESG end.  Robert has a question about slide 5, and IAB to use is
      waiting until the RPS
   during regular IETF meetings are similar to those end of most WGs.  The
   main difference is that they need a way to limit who can participate
   remotely.

   **Requirement 03-59**: The IETF Secretariat MUST be able to easily
   limit remote access to meetings on a room-by-room basis.

   **Requirement 03-60**: 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 presentation to post the remote
   participation tools between IETF meetings question in a manner that is very
   similar to virtual interim meetings.

4.13.  Additional Requirements for Remote Participation

   **Requirement 03-61**: Remote attendees MUST be able to easily find
   all
      the material they need to effectively participate, including
   links Jabber room.  After slide 7, Len jumps to audio, video, instant messaging, slides, and so on.  This
   material MUST be available well before the time of the meeting.  The
   page mic and
      vehemently disagrees with the meeting material SHOULD allow the remote attendee something that Pete said.  Then Lee gets
      up to
   easily perform a time conversion respond to Len, and from the local time three of them go at the
   IETF meeting.

   **Requirement 03-62**: A remote attendee who comes to it for a meeting late
   MUST be able to tell what while,
      with Lee getting up again after slide 10.  The presentation ends
      and 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 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 silence 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 mics), mic to
      explain.  However, Len gets his explanation of what Rachel said
      wrong and if by the meeting time Pete answers Len's interpretation, Rachel
      gives up.

   o  This is over.

   **Requirement 03-63**: There MUST be a constantly-running testing
   service that covers all interactive tools (audio, video, slide
   display, and so on) for the first time Pete is presenting at least a week before an IETF meeting, and
      Robert has the meeting begins.
   Remote attendees need first question, which is relayed through Sam. Pete
      stays silent, not responding the question.  Robert can't see
      Pete's face to be able know if Pete is just not understanding what he
      asked, is too afraid to test answer, is just angry, or something else.

   o  Pete says something incorrect in his presentation, and Len asks
      the remote participation
   setup before a regular meeting, folks in the Jabber room about it.  Rachel figures out what
      Pete should have said, and even during others in the meeting.

   **Requirement 03-64**: The testing service MUST run throughout Jabber room agree.  No
      one goes to the
   meeting so mic because Pete has left the topic, but only the
      people watching Jabber know that last-minute joiners can test their systems.

   **Requirement 03-65**: 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 testing service SHOULD allow chairs try to repeat what the AD says,
      get it only approximately right, but the remote attendees to also test whether their outgoing audio, video, do not
      hear what really was said and slide
   control works.

   **Requirement 03-66**: Remote attendees SHOULD therefore cannot comment
      effectively.

   o  Sam only volunteered to be able scribe because no one else would do it,
      and isn't sitting close to easily
   contact the IETF Secretariat if they find problems with any mic, and gets tired of getting up
      and down all the
   RPS tools, 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 get fairly rapid response.

   **Requirement 03-67**: Similarly, local attendees SHOULD be able a client or server
      software issue.  She finally finds someone else on Jabber who is
      also in the meeting, and gets them to
   easily contact invite her into the room.

A.4.2.  Remotely Presenting

   Some WGs have experimented with remote presentations at regular IETF Secretariat if there are RPS problems in
   meetings, with quite mixed results.  For some, it works fine: the
   meeting rooms.

   **Requirement 03-68**: The RPS tools MUST be available for AD-
   sponsored lunch meetings scheduled by
   remote presenter speaks, the IETF Secretariat.  Regular
   IETF meetings are more than just a group of WG meetings.  Remote
   attendees may want to participate in chair moves the other parts of a regular
   meeting as well.

   **Requirement 03-69**: Any tools that are used by remote attendees
   MUST also slides forward, and
   questions can be available to heard easily.  For others, it is a mess: the local
   attendees as well. 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 many IETF
   meetings, some local attendees act as a recent meeting that had a remote attendees in presenter, a WG meetings
   that they are not sitting in, had a video
   camera set up at the chairs' desk pointed towards the audience so they can attend two WGs
   that the presenter could see who was at once.

5.  Requirements for Supporting Remote Participation in Interim Meetings

   One of the goals of mic; this document is was considered
   to increase be a great help and a lot friendlier because the effectiveness 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
   interim meetings.  Interim meetings are now uncommon, but might
   become more common (and more effective) if jokes
   and discussion of whether seeing the remote participation
   becomes presenter caused people
   to pay more useful.

   **Functional spec 03-09**: The RPS SHOULD attention.

   Remote presenters have a central location
   where the specifics about commented how remote participation difficult it 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 03-70**: There SHOULD be documentation and training for
   the RPS tools specifically targeted at WG chairs who will lead
   interim meetings.

   [[[ TODO: Determine how much or how little the IETF Secretariat
   should participate in setting set up their
   systems, particularly because they are not sure whether their setup
   is working until the RPS for interim meetings.  The
   IETF Secretariat currently offers some help to some WGs, but this
   might become more formalized in the future. ]]]

5.1.  Requirements for Supporting Remote Participation in Face-to-Face
      Interim Meetings

   Face-to-face interim meetings have many things in common with regular
   IETF meetings, but there moment they are also many significant differences.  For
   most WGs, fewer people attend interim meetings than IETF meetings,
   although those who travel supposed to a face-to-face interim meeting are often
   the more active WG participants.  There may be presenting.  Even
   then, the first few minutes of the presentation has 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 feeling of interim "is
   this really working?".

A.4.3.  Floor Control

   Although Appendix A.4.1 may seem like it is a bit harsh on WG
   meetings as less important than regular IETF meetings..

   Typically, chairs,
   the IETF Secretariat does current tools do not control give them the rooms in which
   face-to-face interims are held, so they have no kind of control over whether
   outgoing audio will be supported, or supported well enough to
   guarantee that remote
   attendees that they have over local attendees.  The chairs can hear. [[[ TODO: Should tell
   what is happening at the IETF
   Secretariat be tasked with helping set up face-to-face interims? ]]]

   **Requirement 03-71**: 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, mics, but at a minimum, the
   following MUST be supported for remote attendees:

   o  Room audio

   o  Instant messaging

   o  Slide distribution

   o  Slide presentation

   o  Shared document editing

   [[[ TODO: What have much less view into what is
   happening on Jabber, even if they are watching the requirements for registering?  Interim
   meetings are generally considered to have a very different feeling
   than regular IETF meetings; does this affect Jabber room.

   Without as much view, they cannot assist the idea flow of
   registration?  What if registration is cheap but not free? ]]]

5.2.  Requirements for Supporting All-Remote Interim Meetings

   The requirements for meetings the conversation
   as well.

   o  Carl sees 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 Jabber room has an active and face-to-face interim
   meeting.  This section highlights the differences from Section 4 useful back-
      channel discussion during Pete's provocative presentation.  Pete
      finishes and
   Section 5.1.

   Video for all-remote meetings may be more important than asks for face-to-
   face meetings in order questions.  Lee and Len rush to help the chair with floor control. [[[
   TODO: Determine if this is true and, if so, mic
      line, and it takes Robert a few seconds to get his question into
      the additional
   requirements Jabber room and for all Sam to go to the remote attendees. ]]]

   Attendance at virtual interim meetings is supposed mic.  Carl tries to be taken,
      prioritize Sam forward in the line, but
   this is sometimes ignored.  A system that is probably at least
   somewhat different than that in Section 4.13 may be needed for
   collecting attendance at virtual interim meetings. [[[ TODO: What are Len gets upset when he
      does.

   o  Rachel asks a question, but Sam is not going to the requirements for registering?  Virtual interim meetings are
   generally considered mic to have a very different feeling than regular
   IETF meetings; does this affect relay
      it.  In fact, Sam has pretty much stopped paying attention.  Chris
      cannot do something about the idea of registration? ]]]

   [[[ TODO: Are there different floor control issues for all-remote
   meetings? ]]]

6.  IANA Considerations

   None. [[ ...and thus this section can situation without making Sam look
      bad.

   o  Pete has run over time, Robert asks what is supposed to be removed before publication
   as an RFC... ]]

7.  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
      last question, and Pete doesn't understand what Sam said.  Carl
      cannot tell whether to be easier wait for Robert to know which WGs a remote attendee was following.
   When RPS tools are deployed, the IETF should describe rephrase the privacy
   implications of using such question or
      whether Robert even heard Pete's response.

   o  In a tool to the users so they virtual interim where remote attendees all participate by
      voice, someone can decide
   whether or not be heard typing / eating / talking loudly to use
      someone else.  Carl and Chris try to get that person's attention
      over the tools. audio and Jabber, but to no avail.  The eventual RPS tools will tool being used
      does not have some user authentication the ability to mute individual attendees, so the
      meeting is disrupted until that will
   associate people with actions. 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 user might need
   to authenticate to the system attendee can
   indicate in order to give a presentation the application or
   speak during through a session.  The credentials needed for this
   authentication will need web form that they want to be managed in a secure fashion, both by
   the system and by the people who are being identified.

8.  Acknowledgements

   Many of the ideas in this document were contributed by members of the
   speak.

A.5.  Remote Participation at IETF community based on their experiences during recent Interim WG Meetings

   Face-to-face interim meetings have many things in common with regular
   IETF
   meetings.  There meetings, but there are also many contributions from significant differences.  For
   most WGs, fewer people on attend interim meetings than IETF meetings,
   although those who travel to a face-to-face interim meeting are often
   the
   vmeet@ietf.org mailing list as well as more active WG chairs.

   Some 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 text in this document originated in the request for
   proposals that was issued by IETF Secretariat does not control the IAOC that led to this document.

9.  Informative References

   [BCP78]    Bradner, S. and J. Contreras, "Rights Contributors Provide 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 Trust", BCP 78, RFC 5378, November 2008.

   [RFC2119]  Bradner, S., "Key words for use (and, much less often, in RFCs
   commercial conference facilities such as hotels).  Because these
   facilities are not administered by the IETF Secretariat, the ability
   to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines 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
              Procedures", BCP 25, RFC 2418, September 1998.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging 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 Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

   [RFC6121]  Saint-Andre, P., "Extensible Messaging some WGs have used different tools for audio
   participation.  For example, some virtual interims are held using
   Skype, others with TeamSpeak, and Presence
              Protocol (XMPP): Instant Messaging so on.

   So far, the experience with virtual interim meetings has been
   reasonably good, and Presence",
              RFC 6121, March 2011.

   [RPS-RFP]  IAOC, "Request some people say that it is better than for Proposals
   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 Requirements Development
   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 Remote Participation Services", 2011, <http://
              iaoc.ietf.org/documents/
              RPS-Specifications-RFP-2011-10-19.pdf>. 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