Network Working Group                                         P. Hoffman
Internet-Draft                                            VPN Consortium
Intended status: Informational                           January 5, 2012
Expires: July 8, 2012


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

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 the quality of direct physical attendance for
   the various roles, including chair, presenter and simple attendee.
   Before deploying the new tools and services needed for this enhanced
   remote participation, the requirements for such tools and services
   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 July 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



Hoffman                   Expires July 8, 2012                  [Page 1]


Internet-Draft          Remote Participation Reqs           January 2012


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  About This Document  . . . . . . . . . . . . . . . . . . .  4
   2.  Scenarios Required to be Supported . . . . . . . . . . . . . .  5
   3.  Interactions with Current RPS Tools Used by the IETF . . . . .  6
     3.1.  Technologies Currently Used at Regular IETF Meetings . . .  6
     3.2.  Locating the Meeting Information . . . . . . . . . . . . .  7
       3.2.1.  Audio  . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.2.  Instant Messaging  . . . . . . . . . . . . . . . . . .  8
       3.2.3.  Slides . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Remotely Speaking at the Mic . . . . . . . . . . . . . . .  8
     3.4.  Chairs and Floor Control for Remote Attendees  . . . . . . 10
     3.5.  Remotely Presenting at Regular IETF Meetings . . . . . . . 11
     3.6.  Experiences with Remote Participation in Virtual
           Interim Meetings . . . . . . . . . . . . . . . . . . . . . 12
   4.  Requirements for Supporting Remote Participation in
       Face-to-Face Meetings  . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Technologies . . . . . . . . . . . . . . . . . . . . . . . 13
       4.1.1.  Audio  . . . . . . . . . . . . . . . . . . . . . . . . 13
       4.1.2.  Video  . . . . . . . . . . . . . . . . . . . . . . . . 14
       4.1.3.  Instant Messaging  . . . . . . . . . . . . . . . . . . 14
       4.1.4.  Slide Presentations  . . . . . . . . . . . . . . . . . 15
       4.1.5.  Shared Document Editing  . . . . . . . . . . . . . . . 16
     4.2.  Tools  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
       4.2.1.  Requirements for Remote Participation  . . . . . . . . 16
       4.2.2.  Floor Control for Chairs . . . . . . . . . . . . . . . 17
       4.2.3.  Transcription  . . . . . . . . . . . . . . . . . . . . 19
       4.2.4.  Polling  . . . . . . . . . . . . . . . . . . . . . . . 19
     4.3.  Use by IETF Leadership . . . . . . . . . . . . . . . . . . 19
     4.4.  Plenaries  . . . . . . . . . . . . . . . . . . . . . . . . 19
   5.  Requirements for Supporting All-Remote Meetings  . . . . . . . 19
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21








Hoffman                   Expires July 8, 2012                  [Page 2]


Internet-Draft          Remote Participation Reqs           January 2012


1.  Introduction

   There are two types of participants at the three-times-a-year IETF
   meetings: those who are at the meeting in person ("local attendees")
   and those who are not at the meeting in person but participate by
   following the meeting online ("remote attendees").  In the past
   decade, the IETF has tried to make it easier for remote attendees to
   participate in its face-to-face meetings a meaningful fashion by
   providing supported and experimental online services.

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

   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 over HTTP, textual
   instant messaging (IM) carried over Jabber, and ad-hoc tools that
   some WGs employ.  For interim WG meetings, the IETF also provides
   access to Cisco's WebEx RPS.  The IETF's leadership regularly uses
   telephone and Jabber and WebEx for the many meetings that happen
   between the IETF meetings.

   The IETF wants to improve the tools provided in the RPS for many
   reasons.

   o  A better RPS would allow more people 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 more discussion of changes needed
      to those documents during the WG process.  There are many people
      who are active in many WGs who rarely or never come to IETF
      meetings; good RPS tools could allow these people to contribute
      significantly during meetings like they do on the mailing lists.

   o  The improved RPS tools would also be used outside IETF meetings.
      They would be available to WGs for interim meetings, both to allow
      remote participation in face-to-face interims as well as to
      facilitate "virtual interims" where none of the participants 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



Hoffman                   Expires July 8, 2012                  [Page 3]


Internet-Draft          Remote Participation Reqs           January 2012


      speakers 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.  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 the experience of remote attendees to
   rival those of local attendees.

   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
   00-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 functions
   specification associated with that requirement might be "floor
   control can be done through a stand-alone application or web form".
   Functional specifications are not (currently) called out in this
   document.




Hoffman                   Expires July 8, 2012                  [Page 4]


Internet-Draft          Remote Participation Reqs           January 2012


   The requirements covered in this document apply almost exclusively to
   tools and services that are used for remote participation in real-
   time meetings.  The document does not cover the many other tools used
   by WGs for non-real-time communication such as mailing lists, issue
   trackers, document flow control systems, and so on.  Many of the non-
   real-time tools are also being improved over time, but they are not
   the subject of this document.

   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 in which the RPS described in
   this document is expected to be used are:

   o  WG sessions at regular IETF meetings -- A typical regular IETF
      meeting has about 150 sessions, with up to 8 of those sessions
      happening at the same time.  A session might have between 20 and
      200 local attendees in the room, and might have only a few or many
      dozens of remote attendees.  WG sessions typically have one to
      three co-chairs at the front of the room and a series of
      individuals who come to the front to present; some presentations
      are made by small panels.

   o  Plenaries at regular IETF meetings -- There are usually two
      plenaries at a regular IETF meeting, with on-site attendance of
      about 700 local attendees and dozens of remote attendees.  There
      are from 1 to 20 presenters; presentations may be made by multiple
      people.

   o  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 sometimes a meeting
      room rented at a hotel).  At such meetings, there are between a
      handful and a few dozen local attendees and a similar number of
      remote attendees.  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.





Hoffman                   Expires July 8, 2012                  [Page 5]


Internet-Draft          Remote Participation Reqs           January 2012


   o  IETF leadership meetings -- The IETF leadership (the IESG, IAOC,
      IAB, and probably others) have periodic virtual meetings, usually
      with presentations.  These groups also meet at the regular IETF
      meetings, and sometimes have remote attendees at those meetings
      (such as members who cannot attend the IETF meeting or presenters
      who are not part of the leadership group).

   [[[ TODO: Count the number of f2f and virtual interims from the past
   few years. ]]]

   [[[ TODO: Bar BoFs at regular IETF meetings are not listed above
   because they mostly happen in places where remote participation can't
   be scheduled.  However, some of them do in fact happen in regular
   meeting rooms that might be able to use the RPS tools.  Should they
   be included in this document? ]]]


3.  Interactions with Current RPS Tools Used by the IETF

   Users' experience with the current IETF tools vary widely.  Some
   participants think the tools are fine and are grateful that they
   exist.  Other participants find them barely acceptable because they
   have used better tools in other environments.  Often, local attendees
   mostly forget that the remote attendees are participating until one
   gets something said at the mic.  Local attendees don't have a feeling
   for how many remote attendees are just listening like most of the
   local attendees.

   The variety of current experiences can help inform the discussion of
   how to improve the tools.  The requirements here are derived from the
   current tools; later sections derive requirements from needs that are
   not at all met by the current tools.

   The IETF has years of experience with the two primary tools used at
   its regular meetings (Jabber for IM and streaming audio).  This
   section discusses some of the reactions of users -- those in the
   meetings and those who have participated remotely -- to the current
   tools.

3.1.  Technologies Currently Used at Regular IETF Meetings

   There are three tools that are used by remote attendees for WG
   participation at regular IETF meetings: real-time audio, instant
   messaging, and slides.

   For the past few years, the IETF has used audio streamed over HTTP
   over TCP.  TCP is often buffered at many places between (and in) the
   origination in the IETF meeting venue and the users' computer.  At



Hoffman                   Expires July 8, 2012                  [Page 6]


Internet-Draft          Remote Participation Reqs           January 2012


   recent meetings, delays of around 30 seconds have been recorded, with
   minimum delays typically being five seconds.  This delay is caused by
   buffering at the hop-by-hop ISPs and in the remote attendee's
   computer.  At recent IETF meetings, remote attendance is almost
   always less than 10% of local attendance, and is often less than 5%.
   (There are more remote attendees when the IETF meeting is in the
   U.S.) Each stream is represented by an MP3 playlist (sometimes called
   an "m3u file").

   The IETF long ago standardized on Jabber / XMPP ([RFC3920],
   [RFC3921], and others) for instant messaging used within the IETF.
   Jabber rooms (formally called "multi-user conferences" or "MUCs")
   exist for every WG, and those rooms are live all the time, not just
   during regular IETF meetings.  There are also stable Jabber rooms for
   the plenaries and certain other activities.  BoFs are usually
   assigned Jabber rooms before a regular meeting.

   Presentation slides normally are stored either as PDFs or in one of
   Microsoft's formats for PowerPoint.  They are projected on a local
   screen from someone's laptop computer.

3.2.  Locating the Meeting Information

   Finding information for the real-time audio, instant messaging, and
   slides for an upcoming or current regular meeting is complicated by
   that information being in many different locations on the IETF web
   site, and the fact that the relevant URLs can change before and even
   during the meeting.  Further, a WG chair might copy the latest
   information and send it to the WG mailing list, but there can be
   later changes.  Experienced remote attendees have gotten used to
   checking just before the meeting itself, but even that does not
   alway.

3.2.1.  Audio

   The URL for the audio stream for a WG or BoF meeting is based on the
   room that the meeting is in.  The URLs are listed on "tools-style
   agenda" provided by the IETF Tools Team; for example, see the
   speaker-like icons at <http://tools.ietf.org/agenda/82/>.  The audio
   streams are also announced on the general IETF mailing list
   (ietf@ietf.org) before each meeting.

   A common complaint is that when a WG meeting moves to a different
   room, remote users need to know about the move so that they can use
   the proper URL to hear the audio stream.  The room changes are often,
   but not always, announced on WG mailing lists; when they are not
   announced, there is no easy way for a remote attendee to find out
   which audio stream they should be listening to.  Sometimes, room



Hoffman                   Expires July 8, 2012                  [Page 7]


Internet-Draft          Remote Participation Reqs           January 2012


   changes happen just as a WG meeting is starting, making it nearly
   impossible for a remote attendee to know about the change in streams.

3.2.2.  Instant Messaging

   The Jabber rooms used by WGs and BoFs do not change between IETF
   meetings, so finding the right Jabber room is relatively easy.  Some
   Jabber clients have odd interfaces for joining Jabber rooms, and this
   can cause some problems; even though participants can test their
   Jabber clients before a meeting, there still seems to be some who
   need help just before a WG meeting.

3.2.3.  Slides

   Slides are available from the meeting materials page.  Many, but
   certainly not all, local and remote attendees know how to find the
   meeting materials page.

   It has become fairly common for presenters to not have their
   presentations available for distribution until just before the WG
   meeting.  Because materials are uploaded by the WG chairs, this often
   causes the beginning of WG meetings to be a dance involving
   presenters giving the chairs their slides, followed by chairs
   uploading the slides to the IETF site, followed by the chairs saying
   "the slides are there now".

3.3.  Remotely Speaking at the Mic

   In order for a remote attendee to speak at the mic, a local attendee
   must say it for them.  In most WG and BoF meetings, this done by the
   remote attendee typing into the Jabber room for the meeting, and some
   local attendee going to the mic and repeating what was typed into the
   Jabber room.

   This method of participation often works adequately, but there are
   many places where it fails.  The following is a compendium of stories
   from recent IETF meetings where remotely speaking at the mic didn't
   work as well 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 doesn't get Pete's attention until Pete is already on slide 7
      and Pete doesn't want to go back.

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



Hoffman                   Expires July 8, 2012                  [Page 8]


Internet-Draft          Remote Participation Reqs           January 2012


      the mic.

   o  Robert wants to say something, but Sam is already at the mic
      speaking for Rachel so Sam doesn't see Robert's message until he
      has gotten out of the mic line.

   o  Sam is speaking for Robert, and Rachel wants to comment on what
      Robert said.  Unless Sam reads the message as he is walking back
      to his seat, Rachel doesn't get to speak.

   o  Robert wants to say something at the mic, but Sam is having an
      important side discussion with the AD.

   o  Sam is also the minutes taker, and is too busy at the moment
      catching up with the lively debate at the mic to relay a question
      from Rachel.

   o  Robert cannot understand what Pete is saying about slide 5, but
      Sam doesn't get Pete's attention until Pete is already on slide 7
      and Pete doesn't want to go back.

   o  Chris thought Carl was watching the Jabber room, but Carl was
      reading the draft that is being discussed.

   o  Chris and Carl start the meeting by asking for volunteers to take
      minutes and be Jabber scribe.  They couldn't find a Jabber scribe,
      and it took a lot of begging to get someone to take minutes, so
      they figured that was the best they could do.

   o  Sam is also a presenter, and Robert has a question about Sam's
      presentation, but Sam is obviously not looking at the Jabber room
      at the time.

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

   o  Robert makes a point about one of Pete's slides, and Pete responds
      "I don't think you're looking at the right slide" and continues
      with his presentation.  Robert cannot reply in a timely fashion
      due to the lag in the audio channel.

   o  Pete starts his presentation by asking for questions to be held
      until the end.  Robert has a question about slide 5, and is
      waiting until the end of the presentation to post the question in
      the Jabber room.  After slide 7, Len jumps to the mic and
      vehemently disagrees with something that Pete said.  Then Lee gets
      up to respond to Len, and the three of them go at it for a while,



Hoffman                   Expires July 8, 2012                  [Page 9]


Internet-Draft          Remote Participation Reqs           January 2012


      with Lee getting up again after slide 10.  The presentation ends
      and is over time, so Carl says "we need to move on", so Robert
      never gets to ask his question.

   o  Chris asks "are there any more questions" while Rachel is typing
      furiously, but she doesn't finish before Chris says "I don't see
      anyone, thanks Pete, the next speaker is...".

   o  Rachel comments on Pete's presentation though Sam. Sam doesn't
      understand what Rachel is asking, and Len goes to the mic to
      explain.  However, Len gets his explanation of what Rachel said
      wrong and by the time Pete answers Len's interpretation, Rachel
      gives up.

   o  This is the first time Pete is presenting at an IETF meeting, and
      Robert has the first question, which is relayed through Sam. Pete
      stays silent, not responding the question.  Robert can't see
      Pete's face to know if Pete is just not understanding what he
      asked, is too afraid to answer, is just angry, or something else.

   o  Pete says something incorrect in his presentation, and Len asks
      the folks in the Jabber room about it.  Rachel figures out what
      Pete should have said, and others in the Jabber room agree.  No
      one goes to the mic because Pete has left the topic, but only the
      people watching Jabber know that the presentation was wrong.

   o  Pete says something that the AD sitting at the front of the room
      (not near a mic) doesn't like, and the AD says a few sentences but
      doesn't go to the mic.  The chairs try to repeat what the AD says,
      get it only approximately right, but the remote attendees do not
      hear what really was said and therefore cannot comment
      effectively.

   o  Sam only volunteered to be scribe because no one else would do it,
      and isn't sitting close to the mic, and gets tired of getting up
      and down all the time, and doesn't really agree with Robert on a
      particular issue, so Sam doesn't relay a request from Robert.

   o  [[[ TODO: More here, of course. ]]]

3.4.  Chairs and Floor Control for Remote Attendees

   Although the previous section may seem like it is a bit harsh on WG
   chairs, the current tools do not give them the kind of control over
   remote attendees that they have over local attendees.  The chairs can
   tell what is happening at the mics, but have much less view into what
   is happening on Jabber, even if they are watching the Jabber room.
   Without as much view, they cannot assist the flow of the conversation



Hoffman                   Expires July 8, 2012                 [Page 10]


Internet-Draft          Remote Participation Reqs           January 2012


   as well.

   o  Carl sees that the Jabber room has an active and useful back-
      channel discussion during Pete's provocative presentation.  Pete
      finishes and asks for questions.  Lee and Len and Lou and Lars
      rush to the mic line, and it takes Robert a few seconds to get his
      question into the Jabber room and for Sam to go to the mic.  Carl
      tries to prioritize Sam forward in the line, but Len gets upset
      when he does.

   o  Rachel asks a question, but Sam is not going to the mic to relay
      it.  In fact, Sam has pretty much stopped paying attention.  Chris
      cannot do something about the situation without making Sam look
      bad.

   o  Pete has run over time, Robert asks what is supposed to be the
      last question, and Pete doesn't understand what Sam said.  Carl
      cannot tell whether to wait for Robert to rephrase the question or
      whether Robert even heard Pete's response.

   o  [[[ TODO: More here, of course. ]]]

3.5.  Remotely Presenting at Regular IETF Meetings

   Some WGs have experimented with remote presented in recent years with
   quite mixed results.  For some, it works fine: the remote presenter
   speaks, the chair moves the slides forward, and questions can be
   heard easily.  For others, it is a mess: the local attendees can't
   hear the presenter very well, the presenter can't hear questions or
   there is a long delay, and it was not clear when the presenter was
   waiting for input or there was a lag in the sound.

   At a recent meeting that had a remote presenter, a WG had a video
   camera set up at the chairs' desk pointed towards the audience so
   that the presenter could see who was a the mic; this was considered
   to be a great help and a lot friendlier because the presenter could
   address the people at the mic by name.  They also had the presenter's
   head projected on the screen in the room, which led to a lot of jokes
   and discussion of whether seeing the remote presenter caused people
   to pay more attention.

   Remote presenters have commented how difficult it is to set up their
   systems, particularly because they are not sure whether their setup
   is working until the moment they are supposed to be presenting.  Even
   then, the first few minutes of the presentation has a feeling of "is
   this really working?".

   [[[ TODO: More discussion about experiences with remote presenters.



Hoffman                   Expires July 8, 2012                 [Page 11]


Internet-Draft          Remote Participation Reqs           January 2012


   Include more discussion of where it went well. ]]]

3.6.  Experiences with Remote Participation in Virtual Interim Meetings

   Because few WGs have virtual interim meetings, there is less
   experience with the tools that are commonly used for them.  The IETF
   has had free use of WebEx for a few years, and some WGs have used
   different tools for audio participation.  For example, some virtual
   interims are held using Skype, others with TeamSpeak, and so on.

   So far, the experience with virtual interim meetings has been
   reasonably good, and some people say that it is better than for
   remote attendees at regular IETF meetings because everyone has the
   same problems with getting the group's attention.

   One of the often-debated aspects of virtual interim meetings is what
   time to have them in order to make them available to all
   participants.  That topic is (thankfully) not covered in this
   document.

   [[[ TODO: More discussion about experiences with virtual interims.
   Focus on differences between the all-in-one systems like WebEx and
   the cobble-together systems where there is an audio feed with no
   floor control plus pre-distributed slideware. ]]]


4.  Requirements for Supporting Remote Participation in Face-to-Face
    Meetings

   This section covers the functional specification for effective remote
   participation in meetings where some members are in a face-to-face
   meeting, such as the regular IETF meetings an interim WG meetings
   that are held in a meeting room.  Some of the requirements in this
   section overlap with those in Section 5, but many are unique to
   meetings that have a significant physical presence.

   There is an assumption in this section that the meeting chairs will
   continue to control the flow of the discussion.  That is, if a
   presenter is speaking and a remote attendee wants to ask a question,
   the request to do so goes to the chair, not to the presenter.

   Recordings of the events of the meetings are valuable for remote
   attendees who are not able to hear everything in real time.  This is
   reflected in many requirements below.

   **Requirement 00-01**: The specifications shall rely solely upon IETF
   and other open standards for all communications and interactions.
   (This requirement comes from [RPS-RFP].)



Hoffman                   Expires July 8, 2012                 [Page 12]


Internet-Draft          Remote Participation Reqs           January 2012


   **Requirement 00-02**: All tools in the RPS must be able to be run on
   the widest possible array of computers.  This means that they must be
   able to be run as an application, from any modern web browser, or
   from the command line of all of (at least) MacOS version 10.6 or
   later, Windows 7 or later, and any common Linux distribution produced
   in 2010 or later.

   [[[ TODO: Do we need to include IOS and Android platforms in that
   list? ]]]

4.1.  Technologies

4.1.1.  Audio

   A few requirements come from the IETF's current use of audio in
   meetings.  Meeting rooms have many mics: one or two for the chairs,
   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.

   Note that the requirements here assume a very large change in the way
   that remote participation will happen.  Instead of a remote attendee
   typing something into the Jabber room that someone will repeat at a
   mic in the room, remote attendees will use their own mics to speak to
   the meeting.

   **Requirement 00-03**: Remote attendees need to be able to hear what
   is said by local attendees and chairs at any mic in the meeting.

   **Requirement 00-04**: Remote attendees must be able to speak
   directly to a meeting without going through a local attendee, and
   have their speaking be heard by local attendees.  (Note that the
   ability to speak is controlled by the chair; see Section 4.2.2.) [[[
   TODO: is there a requirement that remote attendees who speak be
   registered as in Requirement 00-30 and Requirement 00-31? ]]]

   A common complaint with the current RPS is that the streaming audio
   can take more than 10 seconds (and sometimes as much as 30 seconds)
   to reach the remote attendee.  This causes many of the problems
   listed in Section 3.3. **Requirement 00-05**: Audio going to and from
   remote attendees must be delivered in as close to real-time as is
   practically possible. **Requirement 00-06**: Audible echo must be
   damped or eliminated by the tools.

   IETF meetings happen in venues such as hotels and conference centers,
   most of which have their own audio setups.  The IETF Secretariat
   contracts with those venues for the use of some or all of their audio
   system. **Requirement 00-07**: The audio system used by the RPS must



Hoffman                   Expires July 8, 2012                 [Page 13]


Internet-Draft          Remote Participation Reqs           January 2012


   be able to integrate with systems commonly used in the venues used
   for IETF meetings.

   **Requirement 00-08**: Recordings of the audio for all meetings must
   be kept for distribution after IETF meetings. **Requirement 00-09**:
   Users must be able to easily find the audio recording of a particular
   WG or BoF session at a particular meeting.

4.1.2.  Video

   The RFP that preceded the current document, [RPS-RFP], discusses
   video as a requirement.  The IETF has experimented with one-way and
   two-way video at some meetings in the past few years.  Remote
   attendees have said that seeing people in the meetings gave them
   better understanding of the meeting; at a recent meeting, a remote
   presenter was able to see the people in line at the mic and was
   better able to interact with them. [[[ TODO: determine how much of
   this is needed for effective participation. ]]]

   **Requirement 00-10**: Remote attendees need to be able to see the
   presenter at a meeting. **Requirement 00-11**: Remote attendees need
   to be able to see local attendees at any mic in the meeting. [[[
   TODO: Is there a requirement that the remote attendees see the slides
   over video? ]]]

   **Requirement 00-12**: Remote attendees who are speaking over the
   audio must be visible to the local attendees.

   **Requirement 00-13**: Video going to and from remote attendees must
   be delivered in as close to real-time as is practically possible.

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

   [[[ TODO: If video is provided, is there a requirement that it be
   archived and accessible? ]]]

4.1.3.  Instant Messaging

   As noted earlier, while the current tool's Jabber room is a good way
   to get questions to the mic, it also becomes a second communications
   channel that only a few people in the room are participating in.
   This document does not address how to prevent that problem (or
   whether it really is much of a problem).

   **Requirement 00-14**: The instant messaging system must allow anyone
   to see all messages in the WG's or BoF's room. **Requirement 00-15**:
   The instant messaging system must allow any registered user (even



Hoffman                   Expires July 8, 2012                 [Page 14]


Internet-Draft          Remote Participation Reqs           January 2012


   those registered anonymously) to post messages in the WG's or BoF's
   room.

   **Requirement 00-16**: Transcripts of the instant messaging for all
   meetings must be kept for distribution after IETF meetings.
   **Requirement 00-17**: Users must be able to easily find the instant
   messaging transcripts of a particular WG or BoF session at a
   particular meeting.

   **Requirement 00-18**: The instant messaging channel needs to be
   useful for humming, which is the common IETF method of assessing
   support.

   [[[ TODO: Should there be multiple rooms for a meeting?  There were
   many requests for a separate "speak into the mic" room, but that is
   not needed if the requirements in Section 4.1.1 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?
   ]]]

4.1.4.  Slide Presentations

   **Requirement 00-19**: The input format for slide presentations must
   be either PDF or PowerPoint. [[[ TODO: Is there a requirement to
   support other formats? ]]]

   **Requirement 00-20**: Presenters must be able to update their slides
   up to just before their presentation, if such update is allowed by
   the chairs. **Requirement 00-21**: Chairs must be able to approve or
   disapprove of any slide submission or updates, with the default being
   that all submissions are allowed.

   **Requirement 00-22**: It needs to be clear to the remote attendees
   which set of slides is being currently shown.

   [[[ TODO: Is there are requirement that remote attendees see the
   slides as the people in the room?  Or, is it sufficient to keep it as
   it is now where remote attendees must download them and speakers must
   say which slide they are on?  If the slides will be visible to remote
   attendees as they are presented, there will be a requirement that the
   presenter can go back and forth in the slide deck. ]]]

   [[[ TODO: If the slides will be visible to remote attendees as they
   are presented, is there a requirement that presenters be able to use
   the equivalent of a laser pointer? ]]]



Hoffman                   Expires July 8, 2012                 [Page 15]


Internet-Draft          Remote Participation Reqs           January 2012


   [[[ TODO: Is there a requirement that animation in PowerPoint be
   supported, or just static slides? ]]]

4.1.5.  Shared Document Editing

   In some WG meetings, there is an attempt to edit a document with
   input from the local attendees.  This is typically done for proposed
   charter changes, but can also be for a WG document as well.  This is
   usually unsuccessful, given the amount of text and the size of what
   can be displayed on the screen.  In recent meetings, shared document
   editing has been used for editing charters and for taking minutes of
   meetings.

   **Requirement 00-23**: It must be easy to start a new shared document
   and to import existing text into a shared document.

   **Requirement 00-24**: Shared real-time editing of text-only
   documents must be supported.  This system must allow at least three
   people to have write access and hundreds of people to have read
   access to any particular document.

   **Requirement 00-25**: Remote attendees can be either the writers or
   the readers.

   **Requirement 00-26**: Those with read access need to see the edits
   made by those with write access within less that five seconds after
   each edit.

   **Requirement 00-27**: 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 what
   formats? ]]]

4.2.  Tools

4.2.1.  Requirements for Remote Participation

   **Requirement 00-28**: Remote attendees must be able to easily find
   all the material they need to effectively participate, including
   links to audio, video, instant messaging, slides, and so on.  This
   material must be available well before the time of the meeting.

   **Requirement 00-29**: A remote attendee who comes to a meeting late
   needs to be able to tell what is happening in the meeting.  In
   specific, there needs to be an indication that the meeting has not
   started, when the meeting is happening (even if there is silence on
   the mics), and when the meeting is over.



Hoffman                   Expires July 8, 2012                 [Page 16]


Internet-Draft          Remote Participation Reqs           January 2012


   With the current tools, it is common in the current IETF RPS for
   people reading from the Jabber room to not know who is requesting
   that something be said at the mic.  There is no such confusion in the
   room of local attendees because everyone has a name badge.  The
   current tools also do not let remote attendees do the equivalent of
   "signing the blue sheets".

   **Requirement 00-30**: The RPS must have a system where a remote
   attendee can register their name and have that name be used in the
   instant messaging system.  This must be able to be done once for an
   entire regular IETF meeting, but the attendee needs to be able to
   indicate which WG sessions they are participating in. **Requirement
   00-31**: A remote attendee who doesn't want to identified should be
   able to register with an anonymized name.

   **Requirement 00-32**: Remote attendees must be able to test the
   remote participation setup before a regular meeting.  There must be a
   constantly-running audio (and possibly video) stream for at least a
   week before the meeting begins that users can connect to.  This test
   setup must also run throughout the meeting so that last-minute
   joiners can test their systems.

   **Requirement 00-33**: Remote attendees must be able to easily
   contact the IETF Secretariat if they find problems with any of the
   RPS tools, and to get fairly rapid response. **Requirement 00-34**:
   Similarly, local attendees must be able to easily contact the IETF
   Secretariat if there are RPS problems in the meeting rooms.

   Regular IETF meetings are more than just a group of WG meetings.
   Remote attendees may want to participate in the other parts of a
   regular meeting as well. **Requirement 00-35**: The RPS tools must be
   available for lunch meetings scheduled by the IETF Secretariat, such
   as for the Security Directorate and Working Group Chairs lunches.
   **Requirement 00-36**: The IETF Secretariat should attempt to make
   the RPS tools available outside of the regular meeting rooms during a
   meeting.  For example, if a "bar BoF" is "scheduled" to be in the
   same venue as the IETF meeting, the IETF Secretariat should attempt
   to have some or all of the RPS tools available for that meeting.

4.2.2.  Floor Control for Chairs

   Newcomers to regular IETF meetings often expect the floor control in
   WG meetings to be fairly straight-forward.  By Tuesday, they might be
   shaking their heads, wondering why some people cut into the mic
   lines, why some people get up to the mics after the chair has closed
   the line, why some people ignore presenters' requests to hold
   questions to the end, and so on.  Mixing remote attendees into this
   social structure will be a daunting task, but one that has been dealt



Hoffman                   Expires July 8, 2012                 [Page 17]


Internet-Draft          Remote Participation Reqs           January 2012


   with in many remote participation systems.

   It is not yet clear how the set of remote attendees would be treated.
   Some tools have each remote attendee being considered separately,
   while others pool all remote attendees into one group.  This affects
   the chair knowing and being able to act on the order that remote
   attendees ask to speak.

   **Requirement 00-37**: Remote attendees must have an easy and
   standardized way of requesting the attention of the chair when the
   remote attendee wants to speak.  The remote attendee must also be
   able to easily cancel an attention request.  (Note that Requirement
   00-29 implies that someone is watching the request queue, something
   that does not happen consistently with the current tools.)

   **Requirement 00-38**: A remote attendee's request for attention must
   be able to include an optional short text string.  This allows, for
   example, a remote attendee to indicate that they are asking a
   question of the presenter or answering a question that someone else
   asked at the mic.

   **Requirement 00-39**: Remote attendee's requests must be part of the
   floor control tool, not in the instant messaging system.

   **Requirement 00-40**: The chair must be able to see all requests
   from remote attendees to speak at any time during the entire meeting
   (not just during presentations) in the floor control system.

   **Requirement 00-41**: The floor control system must allow a chair to
   easily turn off and on an individual's ability to speak over the
   audio at any time.

   **Requirement 00-42**: The floor control system must allow a chair to
   easily mute all remote attendees.

   **Requirement 00-43**: The floor control system must allow a chair to
   easily allow all remote attendees to speak without requesting
   permission; that is, the chair must be easily able to turn on all
   remote attendees mics at once.

   **Requirement 00-44**: The floor control system for the chair must be
   able to be run by at least two users at the same time.  This allows,
   for example, a chair to leave the room or to become a presenter
   without having to do a handoff of the floor control capability.

   **Requirement 00-45**: The users who can use the floor control system
   in a particular meeting must be authenticated using simple passwords.




Hoffman                   Expires July 8, 2012                 [Page 18]


Internet-Draft          Remote Participation Reqs           January 2012


   **Requirement 00-46**: The IETF Secretariat must be easily able to
   set up the individuals allowed to use the floor control system for a
   particular meeting and to change the settings at any time, including
   during the meeting.

4.2.3.  Transcription

   **Requirement 00-47**: Transmitting real-time transcription to remote
   attendees must be supported.  The lag in transmission must be less
   than five seconds.

4.2.4.  Polling

   **Requirement 00-48**: A system for polling meeting participants,
   including remote attendees at the same time, must be provided.  It
   must be easy to set up a simple poll, and it must be easy for all
   participants to find the poll and participate.

4.3.  Use by IETF Leadership

   The requirements for bodies like the IESG and IAB to use the RPS
   during regular IETF meetings are similar to those of most WGs.  The
   main difference is that they need a way to limit who can participate
   remotely. **Requirement 00-49**: Remote access to meetings must be
   able to be set on a room-by-room basis. **Requirement 00-50**: The
   IETF Secretariat must be able to limit participants in restricted
   meetings using a simple authentication mechanism.

4.4.  Plenaries

   At recent IETF meetings, there has been very little input from remote
   attendees even when there is a lot in the room, but that may be due
   to the current setup, not lack of interest.

   [[[ TODO: Are there any requirements that are special to plenaries
   that are not covered above?  Are there requirements not listed above
   that mostly come from plenaries that would also apply to very large
   WGs? ]]]


5.  Requirements for Supporting All-Remote Meetings

   The requirements for meetings that are all remote (that is, with no
   local attendees) are mostly a subset of the requirements for remote
   participation in a face-to-face meeting.  This section highlights the
   differences from Section 4.

   All-remote meetings will not use the IETF's current streaming audio;



Hoffman                   Expires July 8, 2012                 [Page 19]


Internet-Draft          Remote Participation Reqs           January 2012


   instead, they use systems such as WebEx, gtalk, TeamSpeak, and so on.
   They will most likely use the same audio system that is used to
   transmit and receive remote attendees' voice in face-to-face
   meetings.

   Video for all-remote meetings may be more important that for face-to-
   face meetings. [[[ TODO: Determine if this is true and, if so, the
   additional requirements for all the remote attendees. ]]]

   Nearly all current remote participation systems have some way for
   changing slides to be presented to all remote attendees. [[[ TODO: Is
   this a requirement for the IETF RPS? ]]]

   Attendance at virtual interim meetings is supposed to be taken, but
   this is sometimes ignored.  A system that is probably at least
   somewhat different than that in Section 4.2.1 may be needed for
   collecting attendance at virtual interim meetings.

   [[[ TODO: What are the requirements for registering?  Virtual interim
   meetings are generally considered to have a very different feeling
   than regular IETF meetings; does this affect the idea of
   registration? ]]]

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


6.  IANA Considerations

   None. [[ ...and thus this section can 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 to be easier to know which WGs a remote attendee was following.
   When RPS tools are deployed, the IETF should describe the privacy
   implications of using such a tool to the users so they can decide
   whether or not to use the tools.

   The eventual RPS tools will have some user authentication that will
   associate people with actions.  For example, a remote user might need
   to authenticate to the system in order to give a presentation or
   speak during a session.  The credentials needed for this
   authentication will need to be managed in a secure fashion, both by



Hoffman                   Expires July 8, 2012                 [Page 20]


Internet-Draft          Remote Participation Reqs           January 2012


   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
   IETF community based on their experiences during recent IETF
   meetings.

   Some of the text in this document originated in the request for
   proposals that was issued by the IAOC that led to this document.


9.  Informative References

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

   [RFC3920]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 3920, October 2004.

   [RFC3921]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 3921, October 2004.

   [RPS-RFP]  IAOC, "Request for Proposals for Requirements Development
              for Remote Participation Services", 2011, <http://
              iaoc.ietf.org/documents/
              RPS-Specifications-RFP-2011-10-19.pdf>.


Author's Address

   Paul Hoffman
   VPN Consortium

   Email: paul.hoffman@vpnc.org














Hoffman                   Expires July 8, 2012                 [Page 21]