idnits 2.17.1 draft-ietf-genarea-rps-reqs-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 30, 2012) is 4250 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Informational August 30, 2012 5 Expires: March 3, 2013 7 Requirements for Remote Participation Services for the IETF 8 draft-ietf-genarea-rps-reqs-07 10 Abstract 12 The IETF has provided some tools for remote participation in its 13 activities for many years, and some IETF participants have also used 14 their own tools when they felt the need arise. The IETF now wishes 15 to support enhanced remote participation that is as seamless as 16 possible, improving the experience for the remote attendee at the 17 IETF regular meetings and interim meetings without degrading the 18 experience for the people that are physically present. Before 19 deploying the new tools and services needed for this enhanced remote 20 participation, the requirements for such tools and services, and the 21 impacts they will make on the current procedures and infrastructure, 22 must be defined. This document is meant to be that definition. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 3, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Goals for an Improved RPS . . . . . . . . . . . . . . . . 4 60 1.2. About This Document . . . . . . . . . . . . . . . . . . . 5 61 2. Requirements for Supporting Remote Participation in 62 Regular IETF Meetings . . . . . . . . . . . . . . . . . . . . 7 63 2.1. Registration for Remote Participation . . . . . . . . . . 8 64 2.2. Instant Messaging . . . . . . . . . . . . . . . . . . . . 9 65 2.3. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 2.3.1. Audio to Remote Attendees . . . . . . . . . . . . . . 10 67 2.3.2. IM-to-Mic Relay of Comments from Remote Attendees . . 10 68 2.3.3. Audio for Presentations from Remote Attendees . . . . 11 69 2.3.4. Audio from Remote Attendees to the Room for 70 Comments . . . . . . . . . . . . . . . . . . . . . . . 11 71 2.4. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 2.4.1. Video from the Room to Remote Attendees . . . . . . . 13 73 2.4.2. Video from Remote Attendees to the Room . . . . . . . 14 74 2.5. Slide Presentations and Distribution . . . . . . . . . . . 14 75 2.6. Shared Text Document Editing . . . . . . . . . . . . . . . 15 76 2.7. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 16 77 2.8. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 2.9. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 17 79 2.10. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 17 80 2.11. Preparation . . . . . . . . . . . . . . . . . . . . . . . 17 81 2.11.1. Preparation for WG Chairs . . . . . . . . . . . . . . 18 82 2.11.2. Preparation for Remote Attendees . . . . . . . . . . . 18 83 3. Requirements for Supporting Remote Participation in 84 Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 19 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 88 7. Informative References . . . . . . . . . . . . . . . . . . . . 21 89 Appendix A. Background on IETF Remote Participation . . . . . . . 21 90 A.1. How the IETF Meets . . . . . . . . . . . . . . . . . . . . 22 91 A.2. Technologies Currently Used at Regular IETF Meetings . . . 23 92 A.3. Locating the Meeting Information . . . . . . . . . . . . . 24 93 A.3.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 24 94 A.3.2. Instant Messaging . . . . . . . . . . . . . . . . . . 25 95 A.3.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 25 96 A.4. Remote Participation at IETF Meetings . . . . . . . . . . 25 97 A.4.1. Remotely Speaking at the Mic . . . . . . . . . . . . . 26 98 A.4.2. Remotely Presenting . . . . . . . . . . . . . . . . . 28 99 A.4.3. Floor Control . . . . . . . . . . . . . . . . . . . . 29 100 A.5. Remote Participation at IETF Interim WG Meetings . . . . . 30 101 A.5.1. Face-to-Face Interim Meetings . . . . . . . . . . . . 30 102 A.5.2. Virtual Interim Meetings . . . . . . . . . . . . . . . 30 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 1. Introduction 107 There are two types of participants at the three-times-a-year IETF 108 meetings: the people who are physically at the meeting ("local 109 attendees") and people that are not physically at the meeting but are 110 following the meeting online ("remote attendees"). For more than a 111 decade, the IETF has tried to make it easier for remote attendees to 112 participate in its face-to-face meetings in a meaningful fashion by 113 employing various tools. 115 At the same time, many IETF Working Groups (WGs) have started to have 116 interim meetings that are scheduled between the regular IETF 117 meetings; these are briefly described in [RFC2418]. Some of these 118 interim meetings are face-to-face meetings with remote attendees, 119 while other interim meetings only take place over the Internet or on 120 the phone; the latter type of meeting is often called a "virtual 121 interim". There are also interim meetings that do not support remote 122 participation. 124 The IETF's current remote participation system ("RPS") for the 125 official three-times-a-year meetings ("regular IETF meetings") 126 consists of a real-time audio stream carried to remote attendees over 127 HTTP, textual instant messaging (IM) carried over Jabber, and slides 128 distributed on the IETF web site. Two tools that are experimentally 129 supported, WebEx and Meetecho, are used to sync the audio and slides 130 during the meeting, and also replay them in the proceedings. Some 131 WGs also employ ad-hoc tools such as Skype. For interim WG meetings, 132 the IETF provides access to WebEx. The IETF's leadership regularly 133 uses telephone, Jabber, and WebEx for the many meetings that happen 134 between the IETF meetings. Many meetings use a mixture of tools, 135 with each tool providing only part of the overall desired 136 functionality. A more detailed description of the current IETF RPS 137 can be found in Appendix A. 139 1.1. Goals for an Improved RPS 141 The IETF wants to improve the tools provided in the RPS for many 142 reasons. 144 o A better RPS would allow current remote IETF attendees to 145 participate in regular IETF meetings more effectively, and would 146 also allow more people to become remote IETF attendees. This in 147 turn would hopefully lead to better WG outcomes. There are many 148 people who are active in many WGs who rarely or never come to IETF 149 meetings; good RPS tools could allow some of these people to 150 contribute better during meetings. 152 o The improved RPS tools would also be used outside IETF meetings. 153 They would be available to WGs for interim meetings, both to allow 154 remote participation in face-to-face interims as well as to 155 facilitate virtual interims where none of the attendees are in the 156 same location. 158 o The plenary sessions of IETF meetings currently only allow remote 159 attendees to hear the speakers and read a real-time transcript. 160 Improved RPS tools would allow remote attendees to see the 161 speakers, to see the slides synchronized with the audio, and be 162 able to comment at the mics like people in the room. 164 o The IETF leadership (the IAB, IESG, IAOC, and probably others) 165 could use the new tools to help make their own meetings more 166 effective. 168 o There is a desire to better capture the contributions to the IETF 169 (as defined in [BCP78]) of remote attendees in the official record 170 of regular IETF and interim meetings. 172 The are many IETF-related activities that can be aided by remote 173 participation tools. The scenarios in which the RPS described in 174 this document is expected to be used are WG sessions at regular IETF 175 meetings, plenaries at regular IETF meetings, AD-sponsored lunch 176 meetings at regular IETF meetings, face-to-face interim WG meetings, 177 and IETF leadership meetings. 179 1.2. About This Document 181 The purpose of this document is to develop the requirements for the 182 IETF's RPS that enables enhanced remote participation in meeting 183 sessions. The RPS described in this document might augment and/or 184 replace the current set of IETF RPS tools. The intention is to 185 improve as much as possible of the experience of remote attendees in 186 meetings while not having a significant negative effect on the 187 experiences of local attendees and WG chairs. 189 This document specifies a set of requirements based on the community 190 desires at the time that this document is written. It is expected 191 that the desires of the community will shift after the RPS described 192 here is deployed and as remote participation tools evolve. The 193 requirements here are for the RPS to be deployed in the near term; 194 later, as the requirements change, additions and changes will 195 certainly be made to the RPS. This document is definitely not meant 196 to limit experimentation with participation ideas after deployment of 197 the RPS described here. 199 This document differentiates between requirements that have higher 200 and lower priorities. Higher-priority requirements are intended to 201 be delivered as soon as possible, but lower-priority requirements 202 might be delivered later. For example, a high-priority requirement 203 might be "remote attendees must be able to know which slide is being 204 discussed" and a related, lower-priority requirement might be "remote 205 attendees must be able to see the speaker pointing to the slide with 206 a laser pointer". The eventual tools will be rolled out based on the 207 priorities, making it likely that the community will learn more about 208 additional requirements for lower priority items before they are 209 deployed. 211 Note that some of the requirements in this document for particular 212 functionality may not be desired by all WG chairs. Different WG 213 chairs prefer to use different tools, and that will be true when the 214 additional tools described in this document are deployed. The use of 215 some tools is currently required by the IETF procedures, such as the 216 audio recordings that are put in the proceedings. This document does 217 not mandate the use of any particular tool by a WG, but such a 218 requirement might be made by others, such as an Area Director 219 requiring the use of a particular tool by one or more WGs in their 220 area. 222 This document is being produced at the request of the IAOC. The 223 request for proposals that led to this document can be found at 224 [RPS-RFP]. This document does not specify specific technologies or 225 instantiations of tools. Instead, it is meant to be used as a guide 226 for the IAOC to later contract the development and deployment of the 227 tools described here. It is expected that the IAOC will consider 228 changes and additions to the RPS periodically after the RPS described 229 here is deployed. 231 Requirements in this document are numbered, such as "**Requirement 232 07-00**". 234 The requirements covered in this document apply almost exclusively to 235 tools and services that are used for remote participation in real- 236 time meetings. The document does not cover the many other tools used 237 by WGs for non-real-time communication such as mailing lists, issue 238 trackers, document flow control systems, and so on. Many of the non- 239 real-time tools are also being improved over time, but they are not 240 the subject of this document. 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 244 document are to be interpreted as described in RFC 2119 [RFC2119]. 246 This document is being discussed on the vmeet@ietf.org mailing list. 247 See for more 248 information. 250 2. Requirements for Supporting Remote Participation in Regular IETF 251 Meetings 253 This section covers the requirements for effective remote 254 participation in meetings where most members are in regular IETF 255 face-to-face meetings. Some of the requirements in this section 256 overlap with those in Section 3, but many are unique to meetings that 257 have a large number of attendees physically present. 259 **Requirement 07-01**: The specifications in the RPS SHOULD rely upon 260 IETF and other open standards for all communications and interactions 261 wherever possible. The RPS might not rely on IETF or other open 262 standards if there is an identified gap that cannot be met by those 263 standards. 265 **Requirement 07-02**: All tools in the RPS MUST be able to use both 266 IPv4 and IPv6 addresses natively. 268 **Requirement 07-03**: All tools in the RPS SHOULD be able to be run 269 on the widest possible array of computers. The tools may be stand- 270 alone applications, may be run from a modern web browser, or from the 271 command line. The highest priority is that the tool need to be 272 available on all of (at least) MacOS version 10.6 or later, Windows 7 273 or later, and any common Linux distribution produced in 2010 or 274 later. A lower priority is that the tools be able to run on IOS and 275 Android platforms. The tools MUST NOT rely on Adobe Flash to work 276 correctly. 278 **Requirement 07-04**: Audio, video, instant messaging, and slide 279 streams going to and from remote attendees SHOULD be delivered in as 280 close to real-time as is practically possible. The system MUST 281 minimize internal latency, should avoid unnecessary architectural 282 latency, and be designed with a goal of having less than 200 283 milliseconds of delay to registered remote attendees who are on fast 284 Internet connections. A common complaint with the current RPS is 285 that the streaming audio can take more than 10 seconds (and sometimes 286 as much as 30 seconds) to reach the remote attendee. This causes 287 many of the problems listed in Appendix A.4.1. 289 **Requirement 07-05**: The outgoing audio, video, and slide streams 290 MUST by synchronized so the remote attendee does not get confused 291 during slide presentations. 293 **Requirement 07-06**: Many attendees will be in places with limited 294 bandwidth. Remote attendees on 56Kbps Internet connections SHOULD be 295 able to receive useable versions of streaming information. The 296 system SHOULD take advantage of higher bandwidth audio and video 297 encodings for participants on higher bandwidth connections. The 298 system MUST NOT architecturally prevent other users from selecting 299 higher bandwidth encodings. 301 **Requirement 07-07**: Both local and remote attendees SHOULD be able 302 to easily contact a single entity who is available throughout the 303 meeting if they find problems with any of the RPS tools, and to get 304 fairly rapid response. This entity needs to be able to handle as RPS 305 tool problems in the meeting rooms, or be able to quickly contact 306 someone who can address those problems. 308 **Requirement 07-08**: Any tools that are used by remote attendees 309 MUST also be available to local attendees as well. At many IETF 310 meetings, some local attendees act as remote attendees in WG meetings 311 that they are not sitting in, so they can attend two WGs at once. 313 **Requirement 07-09**: The deployment of the tools here MUST take 314 into account making the tools accessible to as many IETF attendees as 315 possible. Such deployment is likely to include technical 316 accommodations for those with visual and hearing disabilities. 318 2.1. Registration for Remote Participation 320 Remote attendees who make contributions to the IETF (as defined in 321 [BCP78]) are bound by the "Note Well" text. By allowing registration 322 before participating remotely, remote attendees can be better alerted 323 to, and thus bound to, the requirements of contributors. This is 324 particularly important because it is easy in the IETF process to 325 change from being an observer to being a contributor. For example, 326 many people who say things in a WG's IM room do not realize that they 327 are bound by the "Note Well" text. 329 **Requirement 07-10**: All remote attendees at regular IETF meetings 330 and interim meetings who make contributions MUST register with the 331 IETF Secretariat before contributing using any of the RPS tools. 333 **Requirement 07-11**: Remote attendees who will only be listening 334 and/or watching, but not making contributions, MUST NOT be required 335 to register. 337 **Requirement 07-12**: The RPS MUST be able to tell which 338 participants are registered and which are not. This is to allow 339 different levels of service to registered users. 341 **Requirement 07-13**: Registration for remote attendees SHOULD be no 342 more onerous than joining a WG mailing list. Basically, the 343 registrant should acknowledge the Note Well, prove that they are at 344 the given email address, and receive confirmation that they are 345 registered. The confirmation will also include any passwords needed 346 for the RPS tools. 348 **Requirement 07-14**: The RPS tools (particularly the registration 349 tool) MUST gracefully handle multiple attendees who have the same 350 name. 352 Note that some unregistered remote attendees might expect to be able 353 to participate but be prevented from doing so by the RPS. The IETF 354 page for each meeting (particularly the agenda pages) can make this 355 clearer to help remote attendees plan better for participation. 357 Registration might happen in the IETF's Datatracker. This would 358 allow the RPS to reuse the Datatracker's identifiers, passwords, 359 identifications (such as who is and is not a WG chair), and so on. 361 The cost for remote attendees to register, if any, is not covered in 362 this document but will instead be determined by the IETF at a later 363 time. There are many ideas on the subject (tiered costs for 364 different services, no cost at all for the first year, and others), 365 but the effects of different cost structures is beyond the scope of 366 this document. 368 2.2. Instant Messaging 370 Instant messaging (IM) is used both as a remote participation tool 371 and as a communication tool for local attendees at a regular meeting. 372 Although the current tool's Jabber room is a good way to get 373 questions to the mic, it also becomes a second communications channel 374 that only a few people in the room are participating in. The instant 375 messaging system is also useful for remote users to ask about the 376 status of the room ("is anyone there?"). 378 **Requirement 07-15**: The IM system MUST allow anyone to see all 379 messages in the WG's or BoF's room. 381 **Requirement 07-16**: The IM system MUST allow any registered user 382 to post messages in the WG's or BoF's room. 384 **Requirement 07-17**: The date and time that a message appears in an 385 IM stream MUST be retained. IM clients MUST be able to show an 386 indication of the date and time for all messages. Someone coming 387 into a meeting late requires context for which messages in an instant 388 messaging room are recent and which are old. 390 2.3. Audio 392 Audio from face-to-face meetings travels in two directions: from the 393 room to remote attendees, and (potentially) from remote attendees to 394 the room. Comments on early drafts of this document indicated that 395 the latter may not really be a requirement for all attendees if IM- 396 to-mic is made predictable. Given this, reliable IM-to-mic relay for 397 comments to speakers is highest priority, audio from remote attendees 398 giving presentations is a second priority, and audio from remote 399 attendees giving comments to the room is a third priority. 401 2.3.1. Audio to Remote Attendees 403 **Requirement 07-18**: Remote attendees MUST be able to hear what is 404 said by local attendees and chairs at any mic in the meeting. 406 **Requirement 07-19**: Remote attendees SHOULD be able to hear the 407 audio stream over the PSTN. 409 2.3.2. IM-to-Mic Relay of Comments from Remote Attendees 411 As described in Appendix A.4.1, the current tools support an informal 412 method for remote attendees to speak at the mic: in the Jabber room, 413 they enter the string "mic:" before their comment and hope that the 414 designated scribe or someone else goes to the mic to relay the 415 comment. This method works, but the current implementation has 416 significant flaws described in that section. 418 **Requirement 07-20**: The RPS MUST enable relay of messages from IM 419 to the mic to be able to happen as quickly as if the remote attendee 420 was local. 422 **Requirement 07-21**: The person relaying from IM to the mic must be 423 available throughout the WG meeting. To date, this has been done by 424 WG volunteers in the room. In the future, it could be done the same 425 way, or maybe could be facilitated by hiring people to attend 426 meetings for the specific purpose of being IM-to-mic scribes, or 427 maybe could be done with tools that allow copy-and-paste of text from 428 IM to a speech synthesizer that reads it to the room. 430 **Requirement 07-22**: If multiple remote attendees want to comment 431 at the same time, the person relaying from IM to the mic MUST be able 432 to relay for all of them. 434 Note: during the development of this document, there have been many 435 suggestions for how WG chairs can better manage the IM-to-mic 436 relaying (for example, with planned pauses, better tracking of the IM 437 room, and so on). Because these are actually about improving WG 438 chairs, not the RPS tools, they are out of scope for this document. 440 2.3.3. Audio for Presentations from Remote Attendees 442 In order for a remote attendee to be a presenter, their voice needs 443 to be heard in the meeting room. This functionality is different 444 than allowing remote attendees from giving comments (covered in 445 Section 2.3.4) in that the the WG chair needs much less floor control 446 for one speaker than for many. 448 **Requirement 07-23**: A remote attendee giving a presentation MUST 449 be able to have their speaking be heard by all local and remote 450 attendees. 452 **Requirement 07-24**: A WG chair MUST be able to control the sound 453 coming from any particular remote attendee. This control MUST allow 454 reduction in volume, all the way to complete muting, of the remote 455 speaker. 457 **Requirement 07-25**: Audible echo in the audio stream MUST be 458 damped and/or eliminated by the tools. The RPS MUST recognize 459 audible echo and automatically take measures to reduce it to a level 460 which won't distract listeners. 462 **Requirement 07-26**: The audio system used by the RPS MUST be able 463 to integrate with systems commonly used in the venues used for IETF 464 meetings. These venue systems typically include line-level audio 465 outputs from mixers that combine all the mic inputs into a single 466 stream. Some venue systems also allow for headphone level inputs 467 from PCs to be mixed into the audio stream. 469 2.3.4. Audio from Remote Attendees to the Room for Comments 471 Note that the requirements here assume a very large change in the way 472 that remote participation will happen. Instead of a remote attendee 473 typing something into the Jabber room that someone will repeat at a 474 mic in the room, remote attendees will use their own mics to speak to 475 the meeting. Some of the requirements from Section 2.3.3 will apply 476 here as well. 478 Further note that, as per above, audio from remote attendees is a 479 secondary priority. That means that the "MUST" requirements in this 480 section are for when the priority is being met, not for when the RPS 481 is initially rolled out. 483 **Requirement 07-27**: Remote attendees MUST be able to speak 484 directly to a meeting without going through a local attendee, and 485 have their speaking be heard by local attendees. (Note that the 486 ability to speak is controlled by the chair; see Section 2.3.4.1.) 488 **Requirement 07-28**: Local attendees MUST be able to determine 489 which remote attendee is speaking. 491 **Requirement 07-29**: When a remote attendee connects to the audio 492 stream to the room, their mic SHOULD start off muted. This will 493 prevent problems such as those common with WebEx where a remote 494 attendee doesn't realize that they can be heard. 496 **Requirement 07-30**: A lower-priority requirement is for remote 497 attendees to be able to speak to the room by originating from the 498 PSTN. 500 2.3.4.1. Floor Control for Chairs for Audio from Remote Attendees 502 It is not yet clear how the set of remote attendees would be treated 503 for queueing. Some tools have each remote attendee being considered 504 separately, while others pool all remote attendees into one group. 505 This affects the chair knowing and being able to act on the order 506 that remote attendees ask to speak. 508 Note that, if the remote video to room requirements from 509 Section 2.4.2 need to be met, it is very likely that a related 510 requirement to those below is that "the audio and video floor 511 controls must be in the same tool". 513 **Requirement 07-31**: Remote attendees MUST have an easy and 514 standardized way of requesting the attention of the chair when the 515 remote attendee wants to speak. The remote attendee MUST also be 516 able to easily cancel an attention request. 518 **Requirement 07-32**: The RPS MUST allow a remote attendee's request 519 for attention to include an optional short (20 characters or less) 520 arbitrary text string. A remote attendee might want to indicate that 521 they are asking a question of the presenter, or answering a question 522 that someone else asked at the mic, or want to bring up a new topic. 523 It is not acceptable to simply rely on humans reading instant 524 messages to allow remote participants to make the request for 525 attention. 527 **Requirement 07-33**: The floor control portion of the RPS MUST give 528 a remote attendee who is allowed to speak a clear signal when they 529 should and should not speak. 531 **Requirement 07-34**: The chair MUST be able to see all requests 532 from remote attendees to speak at any time during the entire meeting 533 (not just during presentations) in the floor control system. 535 **Requirement 07-35**: The floor control system MUST allow a chair to 536 easily mute all remote attendees. 538 **Requirement 07-36**: The floor control system MUST allow a chair to 539 easily allow all remote attendees to speak without requesting 540 permission; that is, the chair SHOULD be able to easily turn on all 541 remote attendees mics at once. 543 **Requirement 07-37**: The floor control system for the chair MUST be 544 able to be run by at least two users at the same time. It is common 545 for a chair to leave the room, to have a side discussion with an AD, 546 or to become a presenter. They should be able to do so without 547 having to do a handoff of the floor control capability. 549 **Requirement 07-38**: The RPS MUST authenticate users who can use 550 the floor control system in a particular meeting using simple 551 passwords; other forms of authentication may be used as well. 553 **Requirement 07-39**: The IETF Secretariat MUST be able to easily 554 set up the individuals allowed to use the floor control system for a 555 particular meeting and to change the settings at any time, including 556 during the meeting. 558 **Requirement 07-40**: The chair SHOULD be able to monitor the sound 559 levels of the audio being delivered to remote attendees to be sure 560 that they can hear what is going on in the room. 562 2.4. Video 564 The IETF has experimented with one-way and two-way video at some 565 meetings in the past few years. Remote attendees have said that 566 seeing people in the meetings gave them a better understanding of the 567 meeting; at a recent meeting, a remote presenter was able to see the 568 people in line at the mic and was better able to interact with them. 569 The requirements for video from remote attendees to meeting rooms 570 parallel the requirements for audio from remote attendees to meeting 571 rooms. The IETF video may need to integrate with the video systems 572 at some meeting venues. 574 2.4.1. Video from the Room to Remote Attendees 576 **Requirement 07-41**: Remote attendees MUST be able to see the 577 presenter at a meeting. 579 **Requirement 07-42**: A lower-priority requirement than Requirement 580 07-41 is that remote attendees SHOULD be able to see who is speaking 581 at the mics in the room. 583 2.4.2. Video from Remote Attendees to the Room 585 Note that the requirements in this section have the same priorities 586 as for audio for remote presentations (Section 2.3.3) and audio from 587 remote attendees to the room for comments (Section 2.3.4). 589 **Requirement 07-43**: When video is allowed for remote attendees to 590 give presentations (as described in Section 2.3.3), the audience in 591 the room SHOULD be able to see the presenter speaking. 593 **Requirement 07-44**: When video is allowed for remote attendees for 594 comments, the floor management tool for audio (as described in 595 Section 2.3.4.1) MUST also control video as well. 597 **Requirement 07-45**: The RPS MUST have the capability of showing 598 video of the remote attendee who is speaking over the audio to the 599 local attendees. 601 **Requirement 07-46**: A remote attendee who is speaking MUST be able 602 to choose what is shown to local attendees: video of them speaking, a 603 still picture of their face or avatar, or just their name. 605 **Requirement 07-47**: The RPS MUST give a remote attendee a clear 606 indication when their video image or selected image is being shown to 607 the local attendees. 609 2.5. Slide Presentations and Distribution 611 This section discusses slide presentations, which are the primary 612 form of presentations made in WG meetings. It should be noted that 613 are occasionally other types of presentations, such as videos; these 614 are not dealt with in the tools proposed below. 616 In this section, "distribute" means slides that are downloaded from 617 the IETF site, while "transmit" means the slide stream seen in near- 618 real-time as the presenter is speaking. 620 **Requirement 07-48**: The RPS MUST be able to handle both PDF and 621 PowerPoint formats (".ppt" and ".pptx") for distributed slides. 623 **Requirement 07-49**: The RPS MUST automatically convert PowerPoint 624 presentations to PDF and make both available for distribution at the 625 same time. 627 **Requirement 07-50**: Presenters MUST be able to update their slides 628 on the IETF site up to just before their presentation, if such update 629 is allowed by the WG chairs. 631 **Requirement 07-51**: Chairs MUST be able to approve or disapprove 632 of any slide submission or updates, with the default being that all 633 submissions are allowed. 635 In many current remote participation systems, slide presentations and 636 the video coming from in-meeting cameras are sent as two separate 637 streams (called the "slide stream" and the "camera stream"). The 638 slide stream is usually much lower bandwidth than the camera stream, 639 so remote attendees with limited bandwidth can choose to watch just 640 the slide stream. Separating the streams allows remote attendees to 641 see the slide stream and the camera streams in separate windows that 642 can be independently sized. 644 **Requirement 07-52**: The RPS MUST transmit the slide stream 645 separately from the camera stream. 647 **Requirement 07-53**: The slide stream MUST represent the slides as 648 they are projected in the room, allowing the presenter to go back and 649 forth, as well as to edit slides in real time. This makes it clear 650 to the remote attendees which set of slides, and which slide number, 651 is being currently shown. 653 **Requirement 07-54**: When remote presentations are supported (see 654 Section 2.3.3), the remote presenter SHOULD be able to control the 655 slides. This is a lower-priority requirement because this could be 656 easily done by a local attendee listening to the remote presenter. 658 2.6. Shared Text Document Editing 660 In some WG meetings, there is an attempt to edit a text document with 661 input from the local attendees. This is typically done for proposed 662 charter changes, but sometimes happens on a WG document or the 663 meeting's agenda. This is usually unsuccessful, given the amount of 664 text and the size of what can be displayed on the screen. In recent 665 meetings, shared text document editing has been used for editing 666 charters and for taking minutes of meetings. 668 An RPS tool for shared text document editing would be equally useful 669 for local and remote attendees watching the edits happen in real- 670 time. There is a good chance that this tool would be watched by 671 local attendees on their laptops instead of being projected on the 672 screen because of the small size of the the text. This, in turn, 673 means that local attendees who aren't using their laptops at the 674 moment would not be able to participate by watching. 676 **Requirement 07-55**: Shared real-time editing of text documents 677 MUST be supported. This system must allow at least three people to 678 have write access and hundreds of people to have read access to any 679 particular document. 681 **Requirement 07-56**: It MUST be easy to start a new text shared 682 document and to import existing text into a shared document. 684 **Requirement 07-57**: Remote attendees MUST be able to be either the 685 writers or the readers of shared documents. 687 **Requirement 07-58**: The edits MUST be reasonably synchronized with 688 the sound and video so that those with read access can see the edits 689 made by those with write access as they are listing to the meeting. 691 **Requirement 07-59**: It MUST be easy to change the permissions for 692 who gets write access to a document during an editing session. 694 **Requirement 07-60**: A much-lower priority requirement is the 695 ability for group-editing of graphics. 697 2.7. Archiving 699 Archived recordings of the events of the meetings are valuable for 700 remote attendees who are not able to hear everything in real time. 702 **Requirement 07-61**: The RPS MUST support storage and distribution 703 of recordings of the audio, video, and slide presentations for all WG 704 meetings. 706 **Requirement 07-62**: Transcripts of the instant messaging for all 707 meetings MUST be kept for distribution after IETF meetings. 709 **Requirement 07-63**: The recordings and transcripts SHOULD be made 710 available during the meetings, within a day of them being made. 712 **Requirement 07-64**: Users MUST be able to easily find the archives 713 of the recordings and instant messaging transcripts of a particular 714 WG or BoF session at a particular meeting. 716 **Requirement 07-65**: The RPS SHOULD support indexing of archived 717 audio and video for particular events in meetings such as when 718 speakers change. This is a frequently-requested feature, although 719 there is not yet widespread agreement on standards to do so. 721 **Requirement 07-66**: The RPS MUST support recording and storage of 722 recordings of the audio, video, and slide presentations of interim 723 meetings as well as regular IETF meetings. 725 **Requirement 07-67**: Given that interim meetings are often run 726 without the help of the IETF Secretariat, making these recordings 727 MUST be easy for WG chairs. 729 2.8. Polling 731 The common IETF method of assessing support is a straw poll, 732 sometimes managed by audible humming, sometimes by raising hands. 734 **Requirement 07-68**: A system for yes/no/abstain polling meeting 735 attendees, including remote attendees at the same time, MUST be 736 provided. It MUST be easy to set up a simple poll, and it must be 737 easy for all local and remote attendees to find the poll and 738 participate. Note that this would add a requirement that everyone in 739 a meeting be using their computer to participate in the poll. 741 2.9. Plenaries 743 **Requirement 07-69**: Remote attendees SHOULD be able to make 744 comments at the mic approximately as well as if they were local 745 attendees. This means that either remote audio to the plenary room 746 speakers be available, or that IM-to-room relay be available. 748 **Requirement 07-70**: Transmitting real-time transcription of 749 plenary speakers to remote attendees MUST be supported. The lag in 750 transmission MUST be less than five seconds. 752 2.10. Use by IETF Leadership 754 The requirements for bodies like the IESG and IAB to use the RPS 755 during regular IETF meetings are similar to those of most WGs. The 756 main difference is that they need a way to limit who can participate 757 remotely. 759 **Requirement 07-71**: The chair or meeting facilitator MUST be able 760 to easily limit remote access of all tools (both for listening/ 761 observing and contributing) to meetings on a room-by-room basis. 763 **Requirement 07-72**: The IETF Secretariat must be able to limit 764 attendees in restricted meetings using a simple authentication 765 mechanism. 767 Note that the IETF leadership will also heavily use the remote 768 participation tools between IETF meetings in a manner that is very 769 similar to virtual interim meetings. 771 2.11. Preparation 773 Both WG chairs and attendees need to be able to prepare for an IETF 774 meeting and individual WG meetings. The more tools that might be 775 used in a meeting, the more important it is that the chairs and 776 attendees be able to prepare easily. 778 2.11.1. Preparation for WG Chairs 780 **Requirement 07-73**: Sessions MUST NOT be associated with physical 781 rooms until just before session starts. This allows a previous 782 session to run over its time into the break period without 783 inconveniencing remote users or the archives. 785 **Requirement 07-74**: The RPS MUST allow a session to be moved from 786 one room to another during the session This is needed because the 787 Secretariat sometimes need to swap the rooms for WGs when it becomes 788 clear that one is too full and another room has excess space. 790 **Requirement 07-75**: WG chairs MUST be able to test whether or not 791 the tools for their session are working at least 30 minutes before 792 the meeting begins (unless, of course, there is already another 793 meeting occurring in the room during that time). Session testing is 794 done before session is associated with a physical room. 796 **Requirement 07-76**: There MUST be written operational 797 documentation for each RPS tool that is accessible at all times. 798 This will help reduce problems where a WG chair is having problems 799 during a meeting that is affecting the meeting as a whole. 801 **Requirement 07-77**: There SHOULD be training materials for WG 802 chairs in how to use the RPS tools. 804 **Requirement 07-78**: There SHOULD be a custom checklist for each WG 805 that helps the chair prepare for their meeting. The checklist would 806 enumerate the steps needed before the meeting begins, to start the 807 meeting, during the meeting, to close the meeting, and after a 808 meeting. 810 2.11.2. Preparation for Remote Attendees 812 **Requirement 07-79**: Remote attendees MUST be able to easily find 813 all the material they need to effectively participate, including 814 links to audio, video, instant messaging, slides, and so on. This 815 material MUST be available well before the time of the meeting. The 816 page with the meeting material SHOULD allow the remote attendee to 817 easily perform a time conversion to and from the local time at the 818 IETF meeting. 820 **Requirement 07-80**: There MUST be a constantly-running testing 821 service that covers all interactive tools (audio, video, slide 822 display, and so on) for at least a week before the meeting begins. 824 This would be similar to the "call here to ensure your voice and 825 video are set up correctly" test available for other services. 826 Remote attendees need to be able to test the remote participation 827 setup before a regular meeting, and even during the meeting. 829 **Requirement 07-81**: The testing service MUST run throughout the 830 meeting so that last-minute joiners can test their systems. 832 **Requirement 07-82**: The testing service SHOULD allow remote 833 attendees to also test whether their outgoing audio, video, and slide 834 control works. 836 **Requirement 07-83**: A remote attendee who starts using one or more 837 tools after a meeting has begun MUST be able to tell what is 838 happening in the meeting. In specific, there MUST be an indication 839 if the meeting has not started, if the meeting is happening (even if 840 there is silence on the mics), and if the meeting is over. 842 3. Requirements for Supporting Remote Participation in Interim Meetings 844 One of the goals of this document is to increase the effectiveness of 845 interim meetings. Interim meetings are now uncommon, but might 846 become more common (and more effective) if the remote participation 847 becomes more useful. 849 The requirements for meetings that are all remote (that is, with no 850 local attendees) are mostly a subset of the requirements for remote 851 participation in a regular IETF meetings and face-to-face interim 852 meeting. 854 **Requirement 07-84**: The RPS SHOULD have a central location where 855 the specifics about how remote participation is supported for every 856 WG interim meeting. This will reduce the problems often seen where 857 messages about how to participate in an interim meeting get buried in 858 the WG mailing list. 860 **Requirement 07-85**: There SHOULD be documentation and training for 861 the RPS tools specifically targeted at WG chairs who will lead 862 interim meetings. 864 **Requirement 07-86**: The RPS tools MUST be at least partially 865 usable at face-to-face meetings other than regular IETF meetings. 866 The number of the tools that might be available will be different for 867 different venues for the virtual interims, but at a minimum, the 868 following MUST be supported for remote attendees: 870 o Registration 872 o Room audio 874 o Instant messaging 876 o Slide distribution 878 o Slide presentation 880 o Shared document editing 882 4. IANA Considerations 884 None. [[ ...and thus this section can be removed before publication 885 as an RFC... ]] 887 5. Security Considerations 889 People who participate remotely in face-to-face IETF meetings might 890 expect the same level of privacy as they have when they participate 891 directly in those meetings. Some of the proposed tools might cause 892 it to be easier to know which WGs a remote attendee was following. 893 When RPS tools are deployed, the IETF should describe the privacy 894 implications of using such a tool to the users so they can decide 895 whether or not to use the tools. 897 The eventual RPS tools will have some user authentication that will 898 associate people with actions. For example, a remote user might need 899 to authenticate to the system in order to give a presentation or 900 speak during a session. The credentials needed for this 901 authentication will need to be managed in a secure fashion, both by 902 the system and by the people who are being identified. 904 6. Acknowledgements 906 Many of the ideas in this document were contributed by members of the 907 IETF community based on their experiences during recent IETF 908 meetings. There are also many contributions from people on the 909 vmeet@ietf.org mailing list, WG chairs, and attendees in the RPSREQS 910 BoF at IETF 83 in Paris. 912 Some of the text in this document originated in the request for 913 proposals that was issued by the IAOC that led to this document. 915 7. Informative References 917 [BCP78] Bradner, S. and J. Contreras, "Rights Contributors Provide 918 to the IETF Trust", BCP 78, RFC 5378, November 2008. 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, March 1997. 923 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 924 Procedures", BCP 25, RFC 2418, September 1998. 926 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 927 Protocol (XMPP): Core", RFC 6120, March 2011. 929 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 930 Protocol (XMPP): Instant Messaging and Presence", 931 RFC 6121, March 2011. 933 [RPS-RFP] IAOC, "Request for Proposals for Requirements Development 934 for Remote Participation Services", 2011, . 938 Appendix A. Background on IETF Remote Participation 940 The IETF has a long history of using remote participation tools. 941 This history causes many IETF participants to have strong opinions 942 about what future tools should provide and who should benefit from 943 those tools. The purpose of this section is to describe many of the 944 common perceptions of the current tools so that the reader 945 understands what might be expected of future tools. 947 Users' experience with the current IETF tools vary widely. Some 948 participants think the tools are fine and are grateful that they 949 exist. Other participants find them barely acceptable because they 950 have used better tools in other environments. Often, local attendees 951 mostly forget that the remote attendees are participating until one 952 gets gets reminded, such as by something said at the mic. Local 953 attendees don't have a feeling for how many remote attendees are just 954 listening like most of the local attendees. 956 The variety of current experiences can help inform the discussion of 957 how to improve the tools. The experiences described in this appendix 958 are derived from the current tools. It is important to note that 959 people who attend IETF meetings often experience the tools quite 960 differently than those who participate remotely. 962 The IETF has years of experience with the three primary tools used at 963 its regular meetings: prepared slides that are distributed before and 964 during the meeting, Jabber for IM, and streaming audio. This section 965 discusses some of the reactions of users -- those in the meetings and 966 those who have participated remotely -- to the current tools. 968 Remote attendees typically participate by asking questions or making 969 statements during or after presentations, and they also participate 970 in discussions in the instant messaging channel. Local attendees who 971 are using the RPS typically don't participate "remotely": they are 972 using the tools to be able to see what is happening in different 973 rooms when they need to be two or more places at once. 975 A.1. How the IETF Meets 977 o WG sessions at regular IETF meetings -- A typical regular IETF 978 meeting has about 150 sessions lasting one to two and one half 979 hours each, with up to 8 of those sessions happening at the same 980 time. A session might have between 20 and 200 local attendees in 981 the room, and might have only a few or many dozens of remote 982 attendees. WG sessions typically have one to three co-chairs at 983 the front of the room and a series of individuals who come to the 984 front to present; some presentations are made by small panels. 986 o Plenaries at regular IETF meetings -- There are usually two 987 plenaries at a regular IETF meeting, with on-site attendance of 988 about 700 local attendees and dozens of remote attendees. There 989 are from 1 to 20 presenters; presentations may be made by multiple 990 people. 992 o AD-sponsored lunch meetings at regular IETF meetings -- These 993 meetings are scheduled by the IETF Secretariat. Regular IETF 994 meetings are more than just a group of WG meetings. Remote 995 attendees may want to participate in the other parts of a regular 996 meeting as well. 998 o Face-to-face interim WG meetings -- Between regular IETF meetings, 999 some WGs hold interim meetings where attendees get together at a 1000 site (often a company's meeting room, but sometimes a meeting room 1001 rented at a hotel). At such meetings, there are between a handful 1002 and a few dozen local attendees and a similar number of remote 1003 attendees, if remote participation is supported. Presentations 1004 are common. There are typically fewer than 15 face-to-fact 1005 interim meetings a year. 1007 o Virtual interim WG meetings -- Between regular IETF meetings, some 1008 WGs hold virtual interim meetings where there are no local 1009 attendees because there is no central meeting location. There are 1010 between a handful and a few dozen attendees. Presentations are 1011 common. There are typically fewer than 25 face-to-fact interim 1012 meetings a year. 1014 o IETF leadership meetings -- The IETF leadership (the IESG, IAOC, 1015 IAB, and probably others) have periodic virtual meetings, usually 1016 with presentations. These groups also meet at the regular IETF 1017 meetings, and sometimes have remote attendees at those meetings 1018 (such as members who cannot attend the IETF meeting or presenters 1019 who are not part of the leadership group). 1021 The form of "presentations" changes from meeting to meeting, but 1022 almost always includes prepared static slides and audio of the 1023 speaker. Presentations sometimes also includes non-static slides 1024 (usually animations within a slide) and sometimes video. 1026 A.2. Technologies Currently Used at Regular IETF Meetings 1028 There are three tools that are used by remote attendees for WG 1029 participation at regular IETF meetings: real-time audio, instant 1030 messaging, and slides. 1032 For the past few years, the IETF has used audio streamed over HTTP 1033 over TCP. TCP is often buffered at many places between (and in) the 1034 origination in the IETF meeting venue and the users' computer. At 1035 recent meetings, delays of around 30 seconds have been recorded, with 1036 minimum delays typically being five seconds. This delay is caused by 1037 buffering at the hop-by-hop ISPs and in the remote attendee's 1038 computer. At recent IETF meetings, remote attendance is almost 1039 always less than 10% of local attendance, and is often less than 5%. 1040 (There are more remote attendees when the IETF meeting is in the 1041 U.S.) Each stream is represented by an MP3 playlist (sometimes called 1042 an "m3u file"). 1044 The IETF long ago standardized on Jabber / XMPP ([RFC6120], 1045 [RFC6121], and others) for instant messaging used within the IETF. 1046 Jabber rooms (formally called "multi-user conferences" or "MUCs") 1047 exist for every WG, and those rooms are live all the time, not just 1048 during regular IETF meetings. BoFs have jabber rooms that are 1049 available during IETF meetings. There are also stable Jabber rooms 1050 for the plenaries and certain other activities. BoFs are usually 1051 assigned Jabber rooms before a regular meeting. 1053 Presentation slides normally are stored either as PDFs or in one of 1054 Microsoft's formats for PowerPoint. They are projected on a local 1055 screen from someone's laptop computer. Proceedings are currently 1056 stored as PDF of the slides, although they used to be stored as HTML. 1058 There has been experience at recent meetings with two tools, WebEx 1059 and Meetecho, which are supported experimentally by the IETF. Each 1060 tool was used by a handful of WGs with mixed success. The tools 1061 require remote attendees to use specific clients, and installation of 1062 those clients caused problems for some people. On the other hand, 1063 the tools have much more robust meeting control features, and 1064 attendees appreciated the real-time showing of slides during 1065 presentations. 1067 A.3. Locating the Meeting Information 1069 Finding information for the real-time audio, instant messaging, and 1070 slides for an upcoming or current regular meeting is complicated by 1071 that information being in many different locations on the IETF web 1072 site, and the fact that the relevant URLs can change before and even 1073 during the meeting. Further, a WG chair might copy the latest 1074 information and send it to the WG mailing list, but there can be 1075 later changes. Experienced remote attendees have gotten used to 1076 checking just before the meeting itself, but even that does not 1077 always guarantee the correct information. 1079 Currently, the meeting information appears in two different agendas: 1081 o The official agenda on the IETF Datatracker includes links to 1082 venue maps, WG charters, agendas, and Internet-Drafts. For 1083 example, see 1084 . 1086 o The unofficial "tools-style agenda" includes the same links as the 1087 official agenda plus links to the presentations, audio, minutes, 1088 Jabber room, and Jabber logs 9represnted as small icons). For 1089 example, see . 1091 A.3.1. Audio 1093 The URL for the audio stream for a WG or BoF meeting is based on the 1094 room that the meeting is in. The audio streams are announced on the 1095 general IETF mailing list (ietf@ietf.org) before each meeting. 1097 A common complaint is that when a WG meeting moves to a different 1098 room, remote users need to know about the move so that they can use 1099 the proper URL to hear the audio stream. The room changes are often, 1100 but not always, announced on WG mailing lists; when they are not 1101 announced, there is no easy way for a remote attendee to find out 1102 which audio stream they should be listening to. Sometimes, room 1103 changes happen just as a WG meeting is starting, making it nearly 1104 impossible for a remote attendee to know about the change in streams. 1106 IETF meetings happen in venues such as hotels and conference centers, 1107 most of which have their own audio setups. The IETF Secretariat 1108 contracts with those venues for the use of some or all of their audio 1109 system. Without such integration, audio from remote attendees might 1110 not be reliably heard by local attendees. 1112 A.3.2. Instant Messaging 1114 The Jabber rooms used by WGs and BoFs do not change between IETF 1115 meetings, so finding the right Jabber room is relatively easy. Some 1116 Jabber clients have odd interfaces for joining Jabber rooms, and this 1117 can cause some problems; even though attendees can test their Jabber 1118 clients before a meeting, there still seems to be some who need help 1119 just before a WG meeting. There are sometimes problems with people 1120 joining Jabber rooms; in these cases, the attendee needs to find 1121 someone already in the Jabber room to invite them to the discussion. 1123 A.3.3. Slides 1125 Slides are presented in regular IETF meetings with projectors on a 1126 screen at the front of the room from the video output of one or more 1127 local attendees' computers. The same slides are available online for 1128 remote attendees. 1130 Slides are available to local and remote attendees on the IETF 1131 servers before and during regular IETF meetings. This service is 1132 useful to all attendees who want to be prepared for WG meetings. The 1133 slides are not only used by remote attendees listening to the WG 1134 meeting; it is common for local attendees to download the slides and 1135 view them on their laptops during meetings instead of having to read 1136 them from the front of the room. 1138 Slides are available from the meeting materials page. Many, but 1139 certainly not all, local and remote attendees know how to find the 1140 meeting materials page. 1142 It has become fairly common for presenters to not have their 1143 presentations available for distribution until just before the WG 1144 meeting. Because materials are uploaded by the WG chairs, this often 1145 causes the beginning of WG meetings to be a dance involving 1146 presenters giving the chairs their slides, followed by chairs 1147 uploading the slides to the IETF site, followed by the chairs saying 1148 "the slides are there now". 1150 A.4. Remote Participation at IETF Meetings 1151 A.4.1. Remotely Speaking at the Mic 1153 Newcomers to regular IETF meetings often expect the floor control in 1154 WG meetings to be fairly straight-forward. By Tuesday, they might be 1155 shaking their heads, wondering why some people cut into the mic 1156 lines, why some people get up to the mics after the chair has closed 1157 the line, why some people ignore presenters' requests to hold 1158 questions to the end, and so on. Mixing remote attendees into this 1159 social structure will be a daunting task, but one that has been dealt 1160 with in many remote participation systems. 1162 In order for a remote attendee to speak at the mic, a local attendee 1163 must say it for them. In most WG and BoF meetings, this is done by 1164 the remote attendee typing into the Jabber room for the meeting, and 1165 some local attendee going to the mic and repeating what was typed 1166 into the Jabber room. Remote attendees often precede what they want 1167 said at the mic with the string "mic:" to differentiate that from the 1168 rest of the discussion in the Jabber room. 1170 In some WGs, there have been experiments of getting remote attendees 1171 voices into the room either by hooking into the room's sound system 1172 or pointing a mic at the speaker of a laptop. This sometimes works, 1173 but sometimes has bad feedback and delay issues that make the remote 1174 participation worse than having a person reading their comments at 1175 the mic. 1177 The "Jabber-to-mic" method of participation often works adequately, 1178 but there are many places where it fails. It has issues similar to 1179 most proxy approaches where a human is in center of the loop. The 1180 following is a compendium of stories from recent IETF meetings and 1181 interim face-to-face meetings where remotely speaking at the mic 1182 didn't work as well as it could have. The list is given here to both 1183 point out what some WGs are willing to put up with currently, and to 1184 show what is needed if the eventual RPS uses Jabber-to-mic as part of 1185 the solution. The attendees are Chris and Carl (WG co-chairs), Sam 1186 (volunteer Jabber scribe), Rachel and Robert (remote attendees), Pete 1187 (presenter), and Len and Lee (local attendees). 1189 o Robert cannot understand what Pete is saying about slide 5, but 1190 Sam doesn't get Pete's attention until Pete is already on slide 7 1191 and Pete doesn't want to go back. 1193 o Rachel wants to say something, but Sam's Jabber client has crashed 1194 and no one else in the Jabber room knows why Sam isn't going to 1195 the mic. 1197 o Robert wants to say something, but Sam is already at the mic 1198 speaking for Rachel so Sam doesn't see Robert's message until he 1199 has gotten out of the mic line. 1201 o Sam is speaking for Robert, and Rachel wants to comment on what 1202 Robert said. Unless Sam reads the message as he is walking back 1203 to his seat, Rachel doesn't get to speak. 1205 o Robert wants to say something at the mic, but Sam is having an 1206 important side discussion with the AD. 1208 o Sam is also the minutes taker, and is too busy at the moment 1209 catching up with the lively debate at the mic to relay a question 1210 from Rachel. 1212 o Chris thought Carl was watching the Jabber room, but Carl was 1213 reading the draft that is being discussed. 1215 o Chris and Carl start the meeting by asking for volunteers to take 1216 minutes and be Jabber scribe. They couldn't find a Jabber scribe, 1217 and it took a lot of begging to get someone to take minutes, so 1218 they figured that was the best they could do. 1220 o Sam is also a presenter, and Robert has a question about Sam's 1221 presentation, but Sam is obviously not looking at the Jabber room 1222 at the time. 1224 o Rachel asks a question through Sam, and Pete replies. Len, who is 1225 next in line at the mic, starts talking before Sam has a chance to 1226 see whether or not Rachel has a follow-up question. 1228 o Robert makes a point about one of Pete's slides, and Pete responds 1229 "I don't think you're looking at the right slide" and continues 1230 with his presentation. Robert cannot reply in a timely fashion 1231 due to the lag in the audio channel. 1233 o Pete starts his presentation by asking for questions to be held 1234 until the end. Robert has a question about slide 5, and is 1235 waiting until the end of the presentation to post the question in 1236 the Jabber room. After slide 7, Len jumps to the mic and 1237 vehemently disagrees with something that Pete said. Then Lee gets 1238 up to respond to Len, and the three of them go at it for a while, 1239 with Lee getting up again after slide 10. The presentation ends 1240 and is over time, so Carl says "we need to move on", so Robert 1241 never gets to ask his question. 1243 o Chris asks "are there any more questions" while Rachel is typing 1244 furiously, but she doesn't finish before Chris says "I don't see 1245 anyone, thanks Pete, the next speaker is...". 1247 o Rachel comments on Pete's presentation though Sam. Sam doesn't 1248 understand what Rachel is asking, and Len goes to the mic to 1249 explain. However, Len gets his explanation of what Rachel said 1250 wrong and by the time Pete answers Len's interpretation, Rachel 1251 gives up. 1253 o This is the first time Pete is presenting at an IETF meeting, and 1254 Robert has the first question, which is relayed through Sam. Pete 1255 stays silent, not responding the question. Robert can't see 1256 Pete's face to know if Pete is just not understanding what he 1257 asked, is too afraid to answer, is just angry, or something else. 1259 o Pete says something incorrect in his presentation, and Len asks 1260 the folks in the Jabber room about it. Rachel figures out what 1261 Pete should have said, and others in the Jabber room agree. No 1262 one goes to the mic because Pete has left the topic, but only the 1263 people watching Jabber know that the presentation was wrong. 1265 o Pete says something that the AD sitting at the front of the room 1266 (not near a mic) doesn't like, and the AD says a few sentences but 1267 doesn't go to the mic. The chairs try to repeat what the AD says, 1268 get it only approximately right, but the remote attendees do not 1269 hear what really was said and therefore cannot comment 1270 effectively. 1272 o Sam only volunteered to be scribe because no one else would do it, 1273 and isn't sitting close to the mic, and gets tired of getting up 1274 and down all the time, and doesn't really agree with Robert on a 1275 particular issue, so Sam doesn't relay a request from Robert. 1277 o Rachel cannot join the Jabber room due to a client or server 1278 software issue. She finally finds someone else on Jabber who is 1279 also in the meeting, and gets them to invite her into the room. 1281 A.4.2. Remotely Presenting 1283 Some WGs have experimented with remote presentations at regular IETF 1284 meetings, with quite mixed results. For some, it works fine: the 1285 remote presenter speaks, the chair moves the slides forward, and 1286 questions can be heard easily. For others, it is a mess: the local 1287 attendees can't hear the presenter very well, the presenter can't 1288 hear questions or there is a long delay, and it was not clear when 1289 the presenter was waiting for input or there was a lag in the sound. 1291 At a recent meeting that had a remote presenter, a WG had a video 1292 camera set up at the chairs' desk pointed towards the audience so 1293 that the presenter could see who was at the mic; this was considered 1294 to be a great help and a lot friendlier because the presenter could 1295 address the people at the mic by name. They also had the presenter's 1296 head projected on the screen in the room, which led to a lot of jokes 1297 and discussion of whether seeing the remote presenter caused people 1298 to pay more attention. 1300 Remote presenters have commented how difficult it is to set up their 1301 systems, particularly because they are not sure whether their setup 1302 is working until the moment they are supposed to be presenting. Even 1303 then, the first few minutes of the presentation has a feeling of "is 1304 this really working?". 1306 A.4.3. Floor Control 1308 Although Appendix A.4.1 may seem like it is a bit harsh on WG chairs, 1309 the current tools do not give them the kind of control over remote 1310 attendees that they have over local attendees. The chairs can tell 1311 what is happening at the mics, but have much less view into what is 1312 happening on Jabber, even if they are watching the Jabber room. 1313 Without as much view, they cannot assist the flow of the conversation 1314 as well. 1316 o Carl sees that the Jabber room has an active and useful back- 1317 channel discussion during Pete's provocative presentation. Pete 1318 finishes and asks for questions. Lee and Len rush to the mic 1319 line, and it takes Robert a few seconds to get his question into 1320 the Jabber room and for Sam to go to the mic. Carl tries to 1321 prioritize Sam forward in the line, but Len gets upset when he 1322 does. 1324 o Rachel asks a question, but Sam is not going to the mic to relay 1325 it. In fact, Sam has pretty much stopped paying attention. Chris 1326 cannot do something about the situation without making Sam look 1327 bad. 1329 o Pete has run over time, Robert asks what is supposed to be the 1330 last question, and Pete doesn't understand what Sam said. Carl 1331 cannot tell whether to wait for Robert to rephrase the question or 1332 whether Robert even heard Pete's response. 1334 o In a virtual interim where remote attendees all participate by 1335 voice, someone can be heard typing / eating / talking loudly to 1336 someone else. Carl and Chris try to get that person's attention 1337 over the audio and Jabber, but to no avail. The tool being used 1338 does not have the ability to mute individual attendees, so the 1339 meeting is disrupted until that person finally realizes that he or 1340 she is not muted. 1342 Some of these problems are alleviated by some of the proprietary 1343 solutions that have been experimented with. For example, WebEx and 1344 other systems have a "raise hand" feature where a remote attendee can 1345 indicate in the application or through a web form that they want to 1346 speak. 1348 A.5. Remote Participation at IETF Interim WG Meetings 1350 Face-to-face interim meetings have many things in common with regular 1351 IETF meetings, but there are also many significant differences. For 1352 most WGs, fewer people attend interim meetings than IETF meetings, 1353 although those who travel to a face-to-face interim meeting are often 1354 the more active WG participants. There may be a larger demand for 1355 remote participation because people have a harder time justifying 1356 travel for a single WG meeting than for an IETF meeting, but there 1357 may also be less demand because people tend to think of interim WG 1358 meetings as less important than regular IETF meetings.. 1360 Typically, the IETF Secretariat does not control the rooms in which 1361 face-to-face interims are held, so they have no control over whether 1362 outgoing audio will be supported, or supported well enough to 1363 guarantee that remote attendees can hear. 1365 A.5.1. Face-to-Face Interim Meetings 1367 Many interim meetings are held face-to-face in conference rooms 1368 supplied by companies active in the IETF (and, much less often, in 1369 commercial conference facilities such as hotels). Because these 1370 facilities are not administered by the IETF Secretariat, the ability 1371 to include remote attendees varies widely. Some facilities can 1372 distribute the in-room audio over the Internet just fine, while 1373 others have no or limited abilities to do so. 1375 For example, a recent face-to-face interim meeting was supposed to be 1376 open to remote attendees through WebEx, but the sound coming from the 1377 room was too soft to hear reliably. Even if a face-to-face interim 1378 meeting has good facilities for audio and slide presenting, it will 1379 probably have an experience similar to regular IETF meetings. 1381 A.5.2. Virtual Interim Meetings 1383 Because few WGs have virtual interim meetings (those with no face-to- 1384 face attendees), there is less experience with the tools that are 1385 commonly used for them. The IETF has had free use of WebEx for a few 1386 years, and some WGs have used different tools for audio 1387 participation. For example, some virtual interims are held using 1388 Skype, others with TeamSpeak, and so on. 1390 So far, the experience with virtual interim meetings has been 1391 reasonably good, and some people say that it is better than for 1392 remote attendees at regular IETF meetings and face-to-face interims 1393 because everyone has the same problems with getting the group's 1394 attention. Also, there are no problems getting the in-room audio 1395 into the RPS because all attendees are using their own computers for 1396 speaking to the group. 1398 One of the often-debated aspects of virtual interim meetings is what 1399 time to have them in order to make them available to all attendees. 1400 Such scheduling of virtual interim meetings is out of scope for this 1401 document. However, it is noted that because many attendees will be 1402 attending at different times of day and night, no assumption can be 1403 made that attendees will be at an "office". This debate also affects 1404 face-to-face interim meetings because the meeting hosts normally will 1405 schedule the meeting during business hours at the host company, but 1406 that might be terribly inconvenient for some WG members. 1408 Author's Address 1410 Paul Hoffman 1411 VPN Consortium 1413 Email: paul.hoffman@vpnc.org