One document matched: draft-narten-ietf-remote-participation-00.txt
INTERNET-DRAFT Thomas Narten
Intended Status: Informational IBM
<draft-narten-ietf-remote-participation-00.txt> July 6, 2009
Improving Remote Participation in IETF WG Meetings
<draft-narten-ietf-remote-participation-00.txt>
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
draft-narten-ietf-remote-participation-00.txt [Page 1]
INTERNET-DRAFT July 6, 2009
Abstract
This document discusses some steps for improving the ability of
people to remotely participate in IETF meetings. This document makes
some recommendations of "best practice", that if adopted, could
improve the ability for people to participate in IETF meetings
without needing to physically attend meetings. Improving the ability
of participants to contribute and participate remotely would improve
the overall effectiveness of the IETF and improve the quality of the
work it produces.
Contents
Status of this Memo.......................................... 1
1. Introduction............................................. 2
2. Types of Remote Participation............................ 3
3. Participation Scenarios.................................. 5
3.1. Making the Most of Existing Capabilities............ 6
3.2. Meeting Preparation................................. 7
3.3. Participation via Remote Text....................... 7
3.4. Meeting Etiquette................................... 8
3.5. Meeting Playback.................................... 8
4. Summary and Conclusion................................... 9
5. Security Considerations.................................. 9
6. IANA Considerations...................................... 9
7. Acknowledgments.......................................... 10
8. Normative References..................................... 10
9. Informative References................................... 10
10. Author's Address........................................ 10
1. Introduction
It is not always possible for IETF participants to physically attend
IETF meetings. Moreover, limiting participation to those with the
resources to attend meetings can limit the effectiveness of the IETF
and reduce the overall quality of its documents.
draft-narten-ietf-remote-participation-00.txt [Page 2]
INTERNET-DRAFT July 6, 2009
The IETF has long made significant effort in making it possible to
participate in work remotely. Most work is done on mailing lists,
documents, presentations, audio recordings, etc. are archived and
generally available. However, more work needs to be done.
This document lays out a framework of for describing the requirements
needed for various forms of remote participation.
2. Types of Remote Participation
There are a number of different scenarios for how someone might wish
to participate remotely. For the purposes of this document, we focus
only on remote participation related to "face-to-face meetings,"
where a number of participants are expected to meet at the same place
and time for some type of interactive discussion. These types of
meetings are typified by the week-long IETF meetings and interim WG
meetings.
There is substantial range in the types of IETF meetings and the
requirements for participating in such meetings. Individual WGs may
have meetings with only a dozen or fewer participants; in contrast,
IETF plenary sessions can have a thousand attendees. The conduct and
style of meetings varies considerably as well. Some meetings are
highly interactive, where there is much back-and-forth discussion
between multiple participants. Other meetings are more structured,
where there may be a (mostly) one-way presentation (with charts),
followed by a question and answer session with participants lining up
at a microphone. Other styles are also possible as is a mix of styles
during different parts of a meeting.
The following describes some common scenarios for remote
participation. Using scenarios allows us to identify the key
requirements for specific types of meetings, so that individual
solutions to individual scenarios become possible, rather than
attempting to find a "one size fits all" solution that would apply to
every type of meeting.
When considering IETF meetings, it is useful to categorize meetings
along two separate axes. The size of the meeting is defined by the
number of participants. Clearly, approaches for participating
remotely in a small meeting (e.g., a dozen participants) varies
significantly from approaches appropriate for a meeting with hundreds
of participants. Adding remote participants to large meetings further
complicates interaction possibilities.
Separately, the style of a meeting influences the requirements for
remote participation. Many meetings consist of a "broadcast" portion,
draft-narten-ietf-remote-participation-00.txt [Page 3]
INTERNET-DRAFT July 6, 2009
where a single speaker presents a set of charts. Such presentations
are typically followed by a more open question and answer session or
even a general discussion. In such discussions, any participant may
potentially wish to speak. However, dialog is generally structured,
with a persons lining up at a (possibly virtual) microphone to speak
or ask questions.
Finally, one shouldn't forget the potential value of "lurking" in a
meeting, where one (effectively) hears and sees all presentations and
discussions, but does not speak up during the meeting itself. Such
lurking can happen in real time, or after the fact via meeting
archive materials.
The current general IETF practice for WG meetings includes:
1. Having presentations available electronically prior to the start
of the presentation presentation.
2. Recording and archiving audio of WG meetings.
3. Producing official minutes (which may be summaries) [RFC2418].
4. Maintaining a jabber room. The jabber room serves multiple
purposes. First, someone (if there is a volunteer) attempts to
transcribe (in real time) summaries of the conversations that are
taking place at the meeting. Second, questions from remote
participants entered into the jabber room can be relayed into the
meeting by someone at the meeting. Third, the jabber session
serves as a side channel for asking questions or otherwise
discussing the topic of hand. Finally, the jabber log can serve as
an additional log of some of the discussion that took place during
the meeting.
5. Streaming a real-time audio feed of live sessions across the
Internet.
The above describes the existing practice of current IETF meetings.
Recently, there has been experimentation with additional technologies
such as WebEx, or bridging in a remote presenter either via VoIP, a
voice line, or even via cell phone. Results have been mixed. While
there have been successes, there have also been failures.
Some recent examples:
- IPSecME held an interim meeting on May 5, 2009 involving about 20
participants, all participating remotely. The meeting was
considered a success by its participants. The tool TeamSpeak was
draft-narten-ietf-remote-participation-00.txt [Page 4]
INTERNET-DRAFT July 6, 2009
used [IPSECME].
- VMEET [VMEET] is an effort created after IETF 74 in San Francisco
to look at improving the IETF remote participation capabilities.
VMEET has tested a number of technologies to better understand
whether they could be used for IETF meeting. Technologies include
WebEx [VMEET-W] and Elluminate [VMEET-E].
[ additional pointers needed... see
http://www.ietf.org/meetings/interim.html]
Small meetings of roughly 20 or fewer participants, where all
participants are remote (i.e., everyone is "equal") can be made to
work well. Likewise, large "broadcast" style meetings, where a single
(or small number) of individuals give presentations, with only
limited ability to ask questions, can be made to work. Many of us
have experience with both such types of meetings outside of the IETF.
The trickier scenarios are those involving a larger number of
participants, and a less structured interaction style, or one where
potentially anyone can speak at anytime.
3. Participation Scenarios
There have been discussions in VMEET (and elsewhere) about what kind
of tools and facilities are needed for effective remote
participation. Some have focused on an "ideal" environment in a
"worst-case" scenario, i.e, an IETF plenary with a thousand
participants and many wishing to speak.
Some have also argued that whiteboard collaboration tools are
desirable, even though most WG meetings make use of such
collaboration tools today only occasionally.
The IETF already has some experience with small interim WG meetings
handled via traditional conference bridges. In the following, we
focus on more traditional IETF meetings where most participants
physically get together in the same room. We attempt to describe
various participation scenarios in approximate increasing order of
complexity.
1) The simplest form of remote participation is "lurking", where one
listens in on a meeting, follows presentations and discussions,
but does not actually provide any input. Indeed, one can
effectively lurk by replaying a meeting recording (with associated
materials) at a later time. One can also listen to a live audio
stream, leaving open the the option of interjecting into the
draft-narten-ietf-remote-participation-00.txt [Page 5]
INTERNET-DRAFT July 6, 2009
discussion should the need arise.
2) One step up from lurking is participating by asking questions or
otherwise providing input via jabber. This works best when the
questions are short (i.e., can easily be typed) and some delay can
be tolerated between when a question is asked and when it is
answered. It works less well as a question turns into a dialog or
discussion. One limitation with meeting discussions via jabber is
the delay between the poster and the responder is usually
significantly longer than in an voice conversation (what a remote
participant hears may be delayed by several seconds). Thus, use of
jabber for the usual WG meeting discussion, while helpful, is not
a substitute for direct participation in many cases.
3) Another step in increasing capabilities involves having a
presenter present from a remote location. This can be done with a
traditional audio bridge, so long as it is hooked into the meeting
room's PA system, something that is not done at current IETF
meetings. In the remote presenter scenario, only a limited number
of remote participants need speaking capabilities, and the timing
of their participation usually follows a known schedule.
4) A next step involves having a remote participant ask a voice
question in real time. This requires either a conference bridge,
possibly in conjunction with some sort of VoIP tool. When an audio
bridge is used, the cost of participation increases (there is
generally a per-line meeting charge), and there may be a limit to
the number of "speaker lines" that can be supported effectively.
Conference bridges based on VoIP may also have scaling limits in
terms with disruptions stemming from significant delays (i.e, >
150ms) in "turning the line around" when switching from one
speaker to another.
Overall, as the number of remote participants increases, it becomes
increasingly necessary to have tools to facilitate discussion. For
example, beyond roughly 20 speakers, managing the speaking order can
easily become unwieldy and unworkable.
3.1. Making the Most of Existing Capabilities
In the following, we describe some common meeting scenarios that take
place within the IETF today and attempt to make recommendations for
best practices on how to maximize the effectiveness of meetings and
remote participation.
draft-narten-ietf-remote-participation-00.txt [Page 6]
INTERNET-DRAFT July 6, 2009
3.2. Meeting Preparation
Like with all meetings, a productive meeting usually involves
adequate advance preparation, including preparation by participants
(i.e., reading the drafts). That includes having a formal agenda,
providing advance access to background documents, etc. Unlike a face-
to-face meeting, however, any charts used by presenters must also be
made available in advance. It is extremely frustrating to try and
follow a presentation for which one cannot see the charts.
Additional checks should also me made to ensure that remote
participants are able to participate adequately. Steps include:
1. Testing that all microphones are working and that remote
participants can hear those speaking clearly. (This also helps
ensure that audio archives are usable.)
2. If possible, verify that the audio stream is being recorded.
Recommendation: Require that all presentations be available in
advance, with enforcement by the WG chairs. In addition,
develop simple checks to verify that remote participants can
hear prior to starting.
3.3. Participation via Remote Text
Through Jabber, it has been possible for some time now for remote
participants to post questions into the jabber room and have them
read aloud during meetings. This supports simple interactions, but
does not work well with discourse involving a lot of back-and-forth.
Difficulties with the use of jabber for remote participation,
include:
- it is not always clear when a question for the meeting is asked
(since there are often multiple conversations going on within a
jabber room), or who's job (if anyone's) it is to relay the
question.
- Remote participates (connected only via jabber) are not able to
participate in "sense of the room" hums
Recommendations:
1. Develop clear instructions/protocols for how a remote participant
can formally "get in the queue" and provide input. Educate remote
participants as to the process, and ensure that mechanisms are in
place (even it if is just someone monitoring the chat room) to
draft-narten-ietf-remote-participation-00.txt [Page 7]
INTERNET-DRAFT July 6, 2009
ensure that formal questions are processed during the meeting in a
timely fashion.
2. Explore ways for including remote participants in hums. It should
be noted that ARIN's remote participation facilities include a
separate jabber room that is only for asking formal questions and
for hums; a separate jabber room is available for more general
session-related use [ARIN].
3.4. Meeting Etiquette
It is always important that meeting participants follow good
etiquette, but it is especially important when remote participants
are present as they do not have the numerous other social cues
available to someone physically present at a meeting. Steps include:
1) Speakers should always use a microphone when speaking and always
state there names prior to speaking.
2) Speakers should speak slowly, starting with when they give there
names. (This author has observed that many people speak their
names so quickly that only those who already know the speaker can
understand the name!)
3) Presenters should always explicitly say when they are moving to
another slide. To aid remote participants, presenters should
specifically say to which chart they are moving to, either by
giving the chart number or by mentioning the heading at the top of
the slide.
Recommendation: Take steps to ensure that speaker etiquette becomes
part of the normal IETF culture. This may take the help of WG chairs
to enforce.
3.5. Meeting Playback
The value of being able to review and revisit meetings (and the
discussions that took place in them) cannot be underestimated. Given
the global nature of IETF participants, it is not generally possible
to schedule meetings that satisfy everyone's timezone needs. Thus,
some participants may find it better to review a meeting after the
fact at a more convenient time, following up on the mailing list with
any specific questions or concerns. This is doable in the IETF, so
long as the longstanding rule and practice continues to be that all
decisions made in a meeting must subsequently be confirmed on the
mailing list. In addition, late comments, those made after a meeting
draft-narten-ietf-remote-participation-00.txt [Page 8]
INTERNET-DRAFT July 6, 2009
has ended, can still be extremely valuable, provided they are made in
a timely fashion. Thus, it is important that all meeting materials
(including recordings) be made available quickly, preferably within
hours of the meeting. This refers in particular to any audio
recording, since other materials will need to have been available
prior to the meeting.
Although the IETF maintains audio archives of its sessions, their
management could be improved. They are overly hard to find, and it
can take significant effort to locate specific portions related to a
particular meeting or topic. Recordings are presently archived in a
flat directory, named by the time and location of the meeting; and
appear to be unedited raw recordings. There is no automatic way of
going from a particular WG meeting to the specific audio segment for
that meeting [AUDIO].
Recommendation: Make the archiving of audio recordings a formal
requirement of IETF meeting management. Develop a better indexing
system for audio archives of IETF meetings. Recordings should be
readily findable as part of the proceedings, the "tools" agenda at
tools.ietf.org, etc. This may be achievable (at least partly) via a
WIKI and volunteers to edit the audio files. Establish a timeline for
posting audio recordings after meetings.
4. Summary and Conclusion
This document has introduced some of the issues related to remote
participation in the IETF. We have focused on current facilities and
make some recommendations that can easily be done today, without
major changes in existing work practices. Expanding remote facilities
to more complicated environments (e.g., a large WG meeting with many
active, remote participants) needs further study.
5. Security Considerations
This document has no known security implications.
6. IANA Considerations
This document makes no requests to IANA.
draft-narten-ietf-remote-participation-00.txt [Page 9]
INTERNET-DRAFT July 6, 2009
7. Acknowledgments
TBD
8. Normative References
9. Informative References
[ARIN] ARIN's remote participation web page.
https://www.arin.net/participate/meetings/ARIN-XXIII/remote.html
[AUDIO] Audio archives of IETF WG meetings.
ftp://videolab.uoregon.edu/pub/videolab/media/
[RFC2418] "IETF Working Group Guidelines and Procedures," S. Bradner,
September 1998.
[IPSECME] IPSecME Interim Meeting, May, 2009.
http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090505,
http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls
[VMEET] VMEET mailing list:
https://www.ietf.org/mailman/listinfo/vmeet.
[VMEET-E] Archive of VMEET session that evaluated the Elluminate
tool, May, 2009. http://www.samrg.org/vmeet/elluminate/
[VMEET-W] Archive of VMEET session that evaluated the WebEx tool,
April, 2009. http://www.ietf.org/mail-
archive/web/vmeet/current/msg00154.html.
10. Author's Address
Thomas Narten
IBM Corporation
3039 Cornwallis Ave.
PO Box 12195 - BRQA/502
Research Triangle Park, NC 27709-2195
Phone: 919-254-7798
EMail: narten@us.ibm.com
draft-narten-ietf-remote-participation-00.txt [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 15:20:09 |