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]