idnits 2.17.1 draft-ietf-genarea-rps-reqs-02.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 (February 20, 2012) is 4448 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 February 20, 2012 5 Expires: August 23, 2012 7 Requirements for Remote Participation Services for the IETF 8 draft-ietf-genarea-rps-reqs-02 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, approaching the quality of direct physical attendance for 17 the various roles, including chair, presenter and simple attendee. 18 Before deploying the new tools and services needed for this enhanced 19 remote participation, the requirements for such tools and services 20 must be defined. This document is meant to be that definition. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 23, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. About This Document . . . . . . . . . . . . . . . . . . . 5 58 2. Scenarios Required to be Supported . . . . . . . . . . . . . . 7 59 3. Interactions with Current RPS Tools Used by the IETF . . . . . 8 60 3.1. Technologies Currently Used at Regular IETF Meetings . . . 8 61 3.2. Locating the Meeting Information . . . . . . . . . . . . . 9 62 3.2.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.2.2. Instant Messaging . . . . . . . . . . . . . . . . . . 10 64 3.2.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.3. Remote Participation at IETF Meetings . . . . . . . . . . 10 66 3.3.1. Remotely Speaking at the Mic . . . . . . . . . . . . . 10 67 3.3.2. Remotely Presenting . . . . . . . . . . . . . . . . . 13 68 3.3.3. Floor Control . . . . . . . . . . . . . . . . . . . . 13 69 3.4. Remote Participation at IETF Interim WG Meetings . . . . . 14 70 3.4.1. Face-to-Face Interim Meetings . . . . . . . . . . . . 14 71 3.4.2. Virtual Interim Meetings . . . . . . . . . . . . . . . 14 72 4. Requirements for Supporting Remote Participation in 73 Regular IETF Meetings . . . . . . . . . . . . . . . . . . . . 15 74 4.1. Registration for Remote Participation . . . . . . . . . . 17 75 4.2. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 4.2.1. IM-to-Mic Relay of Comments from Remote 77 Participants . . . . . . . . . . . . . . . . . . . . . 18 78 4.2.2. Audio from Remote Participants to the Room . . . . . . 19 79 4.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 4.3.1. Video from the Room to Remote Participants . . . . . . 21 81 4.3.2. Video from Remote Participants to the Room . . . . . . 22 82 4.4. Instant Messaging . . . . . . . . . . . . . . . . . . . . 22 83 4.5. Slide Presentations . . . . . . . . . . . . . . . . . . . 23 84 4.6. Slide Distribution . . . . . . . . . . . . . . . . . . . . 23 85 4.7. Shared Document Editing . . . . . . . . . . . . . . . . . 24 86 4.8. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 25 87 4.9. Transcription . . . . . . . . . . . . . . . . . . . . . . 25 88 4.10. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 4.11. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 26 90 4.12. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 26 91 4.13. Additional Requirements for Remote Participation . . . . . 26 92 5. Requirements for Supporting Remote Participation in 93 Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 27 94 5.1. Requirements for Supporting Remote Participation in 95 Face-to-Face Interim Meetings . . . . . . . . . . . . . . 28 96 5.2. Requirements for Supporting All-Remote Interim Meetings . 29 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 100 9. Informative References . . . . . . . . . . . . . . . . . . . . 30 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 103 1. Introduction 105 There are two types of participants at the three-times-a-year IETF 106 meetings: the people who are physically at the meeting ("local 107 attendees") and people that are not physically at the meeting but are 108 following the meeting online ("remote attendees"). For more than a 109 decade, the IETF has tried to make it easier for remote attendees to 110 participate in its face-to-face meetings in a meaningful fashion by 111 providing supported and experimental online services. 113 At the same time, many IETF Working Groups (WGs) have started to have 114 interim meetings that are scheduled between the regular IETF 115 meetings; these are described (briefly) in [RFC2418]. Some of these 116 interim meetings are face-to-face meetings with remote attendees, 117 while other interim meetings only take place over the Internet or on 118 the phone; the latter type of meeting is often called a "virtual 119 interim". There are also interim meetings that do not support remote 120 participation. 122 The IETF's current remote participation system ("RPS") for the 123 official three-times-a-year meetings ("regular IETF meetings") 124 consists of a real-time audio stream carried over HTTP, textual 125 instant messaging (IM) carried over Jabber, as well as experimental 126 support for two integrated tools, WebEx and Meetecho. Some WGs 127 employ ad-hoc tools such as Skype. For interim WG meetings, the IETF 128 provides access to WebEx. The IETF's leadership regularly uses 129 telephone, Jabber, and WebEx for the many meetings that happen 130 between the IETF meetings. 132 The IETF wants to improve the tools provided in the RPS for many 133 reasons. 135 o A better RPS would allow more people to participate in regular 136 IETF meetings more effectively, hopefully leading to better WG 137 outcomes such as faster progression of WG documents, more 138 reviewers of WG documents, and more discussion of changes needed 139 to those documents during the WG process. There are many people 140 who are active in many WGs who rarely or never come to IETF 141 meetings; good RPS tools could allow these people to contribute 142 significantly during meetings like they do on the mailing lists. 144 o The improved RPS tools would also be used outside IETF meetings. 145 They would be available to WGs for interim meetings, both to allow 146 remote participation in face-to-face interims as well as to 147 facilitate "virtual interims" where none of the participants are 148 in the same location. 150 o The plenary sessions of IETF meetings currently only allow remote 151 attendees to hear the speakers and read a real-time transcript. 152 Improved RPS tools would allow remote attendees to see the 153 speakers and be able to comment at the mics like people in the 154 room. 156 o The IETF leadership (the IAB, IESG, IAOC, and probably others) 157 could use the new tools to help make their own meetings more 158 effective. 160 1.1. About This Document 162 The purpose of this document is to develop the requirements and 163 functional specifications for the IETF's RPS that enables enhanced 164 remote participation in meeting sessions. The RPS described in this 165 document might augment and/or replace the current set of IETF RPS 166 tools. The intention is for the experience of remote attendees to 167 rival those of local attendees. 169 After the tools that meet the requirements in this document are 170 deployed, there will probably be a change in the participation in 171 regular IETF meetings. 173 o Some people who would make an effort to come to a particular IETF 174 meeting might be more likely to attend remotely. Such a change 175 will reduce the number of local attendees, which will both reduce 176 the amount that the IETF makes from registration fees and makes 177 the informal gatherings during the IETF meeting less valuable 178 because of the reduced networking effects. 180 o People who are active on WG mailing lists but not in the regular 181 meetings are more likely to participate in the meetings remotely. 182 Such a change might cause more effective meetings for WGs that are 183 lagging in energy because more people will participate. WG 184 meetings that already have lots of participants will probably 185 become busier. Presentations on documents where none of the 186 authors come to regular IETF meetings will be much more likely to 187 be given by the authors instead of by their proxies. 189 o If the tools make regular IETF meetings and interim meetings much 190 more effective, the IETF might be able to reduce the number of 191 regular meetings each year from three to two. This would 192 significantly reduce the impact of travel on regular IETF 193 participants and make meeting planning much easier, but could 194 significantly change the finances for the IETF and also reduce the 195 amount of side-meeting value per year for participants. 197 Note that some of the requirements in this document for particular 198 functionality may not be desired by all WG chairs. The tools 199 proposed will not force a particular WG to use all the features 200 proposed. 202 This document is being produced at the request of the IAOC. The 203 request for proposals that led to this document can be found at 204 [RPS-RFP]. This document does not specify specific technologies or 205 instantiations of tools. Instead, it is meant to be used as a guide 206 for the IAOC to later contract the development and deployment of the 207 tools described here. 209 Requirements in this document are numbered, such as "**Requirement 210 02-00**". In the IETF, there is an active (and never-ending) debate 211 about what is a "requirement". In the context of this document, a 212 requirement is something that must appear in one of the iterations of 213 the eventual RPS in order to support the mission of enabling useful 214 remote participation in meeting sessions. 216 Later versions of this document will differentiate between 217 requirements that must be met by the first version of the RPS and 218 requirements that must be met by future versions of the RPS. For 219 example, a requirement for the first version of the RPS might be 220 "chairs must be able to specify which remote attendee can speak 221 next", whereas a requirement for a later version of the RPS might be 222 "chairs must be able to perform many or all chair duties at a regular 223 IETF meeting while participating remotely". [[[ TODO: come up with a 224 way to differentiate these two and start marking them as such. ]]] 226 A functional specification is an approach to meeting one or more 227 requirement. For example, a requirement might be "chairs must be 228 able to specify which remote attendee can speak next" and a 229 function's specification associated with that requirement might be 230 "floor control can be done through a stand-alone application or web 231 form". Functional specifications are not (currently) called out in 232 this document. 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. Scenarios Required to be Supported 252 The are many IETF-related activities that can be aided by remote 253 participation tools. The scenarios in which the RPS described in 254 this document is expected to be used are: 256 o WG sessions at regular IETF meetings -- A typical regular IETF 257 meeting has about 150 sessions, with up to 8 of those sessions 258 happening at the same time. A session might have between 20 and 259 200 local attendees in the room, and might have only a few or many 260 dozens of remote attendees. WG sessions typically have one to 261 three co-chairs at the front of the room and a series of 262 individuals who come to the front to present; some presentations 263 are made by small panels. 265 o Plenaries at regular IETF meetings -- There are usually two 266 plenaries at a regular IETF meeting, with on-site attendance of 267 about 700 local attendees and dozens of remote attendees. There 268 are from 1 to 20 presenters; presentations may be made by multiple 269 people. 271 o Face-to-face interim WG meetings -- Between regular IETF meetings, 272 some WGs hold interim meetings where participants get together at 273 a site (often a company's meeting room, but sometimes a meeting 274 room rented at a hotel). At such meetings, there are between a 275 handful and a few dozen local attendees and a similar number of 276 remote attendees. Presentations are common. 278 o Virtual interim WG meetings -- Between regular IETF meetings, some 279 WGs hold virtual interim meetings where there are no local 280 attendees because there is no central meeting location. There are 281 between a handful and a few dozen attendees. Presentations are 282 common. 284 o IETF leadership meetings -- The IETF leadership (the IESG, IAOC, 285 IAB, and probably others) have periodic virtual meetings, usually 286 with presentations. These groups also meet at the regular IETF 287 meetings, and sometimes have remote attendees at those meetings 288 (such as members who cannot attend the IETF meeting or presenters 289 who are not part of the leadership group). 291 [[[ TODO: Count the number of f2f and virtual interims from the past 292 few years. ]]] 294 3. Interactions with Current RPS Tools Used by the IETF 296 Users' experience with the current IETF tools vary widely. Some 297 participants think the tools are fine and are grateful that they 298 exist. Other participants find them barely acceptable because they 299 have used better tools in other environments. Often, local attendees 300 mostly forget that the remote attendees are participating until one 301 gets something said at the mic. Local attendees don't have a feeling 302 for how many remote attendees are just listening like most of the 303 local attendees. 305 The variety of current experiences can help inform the discussion of 306 how to improve the tools. The requirements here are derived from the 307 current tools; later sections derive requirements from needs that are 308 not at all met by the current tools. 310 The IETF has years of experience with the two primary tools used at 311 its regular meetings (Jabber for IM and streaming audio). This 312 section discusses some of the reactions of users -- those in the 313 meetings and those who have participated remotely -- to the current 314 tools. 316 3.1. Technologies Currently Used at Regular IETF Meetings 318 There are three tools that are used by remote attendees for WG 319 participation at regular IETF meetings: real-time audio, instant 320 messaging, and slides. 322 For the past few years, the IETF has used audio streamed over HTTP 323 over TCP. TCP is often buffered at many places between (and in) the 324 origination in the IETF meeting venue and the users' computer. At 325 recent meetings, delays of around 30 seconds have been recorded, with 326 minimum delays typically being five seconds. This delay is caused by 327 buffering at the hop-by-hop ISPs and in the remote attendee's 328 computer. At recent IETF meetings, remote attendance is almost 329 always less than 10% of local attendance, and is often less than 5%. 330 (There are more remote attendees when the IETF meeting is in the 331 U.S.) Each stream is represented by an MP3 playlist (sometimes called 332 an "m3u file"). 334 The IETF long ago standardized on Jabber / XMPP ([RFC6120], 335 [RFC6121], and others) for instant messaging used within the IETF. 336 Jabber rooms (formally called "multi-user conferences" or "MUCs") 337 exist for every WG, and those rooms are live all the time, not just 338 during regular IETF meetings. There are also stable Jabber rooms for 339 the plenaries and certain other activities. BoFs are usually 340 assigned Jabber rooms before a regular meeting. 342 Presentation slides normally are stored either as PDFs or in one of 343 Microsoft's formats for PowerPoint. They are projected on a local 344 screen from someone's laptop computer. 346 There has been experience at recent meetings with two tools, WebEx 347 and Meetecho, which are supported experimentally by the IETF. Each 348 tool was used by a handful of WGs with mixed success. The tools 349 require remote attendees to use specific clients, and installation of 350 those clients caused problems for some people. On the other hand, 351 the tools have much more robust meeting control features, and 352 participants appreciated the real-time showing of slides during 353 presentations. 355 3.2. Locating the Meeting Information 357 Finding information for the real-time audio, instant messaging, and 358 slides for an upcoming or current regular meeting is complicated by 359 that information being in many different locations on the IETF web 360 site, and the fact that the relevant URLs can change before and even 361 during the meeting. Further, a WG chair might copy the latest 362 information and send it to the WG mailing list, but there can be 363 later changes. Experienced remote attendees have gotten used to 364 checking just before the meeting itself, but even that does not 365 always guarantee the correct information. 367 Currently, the meeting information appears in two different agendas: 369 o The official agenda on the IETF Datatracker includes links to 370 venue maps, WG charters, agendas, and Internet-Drafts. For 371 example, see 372 . 374 o The unofficial "tools-style agenda" includes the same links as the 375 official agenda plus links to the presentations, audio, minutes, 376 Jabber room, and Jabber logs 9represnted as small icons). For 377 example, see . 379 3.2.1. Audio 381 The URL for the audio stream for a WG or BoF meeting is based on the 382 room that the meeting is in. The audio streams are announced on the 383 general IETF mailing list (ietf@ietf.org) before each meeting. 385 A common complaint is that when a WG meeting moves to a different 386 room, remote users need to know about the move so that they can use 387 the proper URL to hear the audio stream. The room changes are often, 388 but not always, announced on WG mailing lists; when they are not 389 announced, there is no easy way for a remote attendee to find out 390 which audio stream they should be listening to. Sometimes, room 391 changes happen just as a WG meeting is starting, making it nearly 392 impossible for a remote attendee to know about the change in streams. 394 3.2.2. Instant Messaging 396 The Jabber rooms used by WGs and BoFs do not change between IETF 397 meetings, so finding the right Jabber room is relatively easy. Some 398 Jabber clients have odd interfaces for joining Jabber rooms, and this 399 can cause some problems; even though participants can test their 400 Jabber clients before a meeting, there still seems to be some who 401 need help just before a WG meeting. There are sometimes problems 402 with people joining Jabber rooms; in these cases, the participant 403 needs to find someone already in the Jabber room to invite them to 404 the discussion. 406 3.2.3. Slides 408 Slides are available from the meeting materials page. Many, but 409 certainly not all, local and remote attendees know how to find the 410 meeting materials page. 412 It has become fairly common for presenters to not have their 413 presentations available for distribution until just before the WG 414 meeting. Because materials are uploaded by the WG chairs, this often 415 causes the beginning of WG meetings to be a dance involving 416 presenters giving the chairs their slides, followed by chairs 417 uploading the slides to the IETF site, followed by the chairs saying 418 "the slides are there now". 420 3.3. Remote Participation at IETF Meetings 422 3.3.1. Remotely Speaking at the Mic 424 In order for a remote attendee to speak at the mic, a local attendee 425 must say it for them. In most WG and BoF meetings, this is done by 426 the remote attendee typing into the Jabber room for the meeting, and 427 some local attendee going to the mic and repeating what was typed 428 into the Jabber room. Remote attendees often precede what they want 429 said at the mic with the string "mic:" to differentiate that from the 430 rest of the discussion in the Jabber room. 432 This method of participation often works adequately, but there are 433 many places where it fails. The following is a compendium of stories 434 from recent IETF meetings and interim face-to-face meetings where 435 remotely speaking at the mic didn't work as well as it could have. 436 The participants are Chris and Carl (WG co-chairs), Sam (volunteer 437 Jabber scribe), Rachel and Robert (remote attendees), Pete 438 (presenter), and Len and Lee (local attendees). 440 o Robert cannot understand what Pete is saying about slide 5, but 441 Sam doesn't get Pete's attention until Pete is already on slide 7 442 and Pete doesn't want to go back. 444 o Rachel wants to say something, but Sam's Jabber client has crashed 445 and no one else in the Jabber room knows why Sam isn't going to 446 the mic. 448 o Robert wants to say something, but Sam is already at the mic 449 speaking for Rachel so Sam doesn't see Robert's message until he 450 has gotten out of the mic line. 452 o Sam is speaking for Robert, and Rachel wants to comment on what 453 Robert said. Unless Sam reads the message as he is walking back 454 to his seat, Rachel doesn't get to speak. 456 o Robert wants to say something at the mic, but Sam is having an 457 important side discussion with the AD. 459 o Sam is also the minutes taker, and is too busy at the moment 460 catching up with the lively debate at the mic to relay a question 461 from Rachel. 463 o Chris thought Carl was watching the Jabber room, but Carl was 464 reading the draft that is being discussed. 466 o Chris and Carl start the meeting by asking for volunteers to take 467 minutes and be Jabber scribe. They couldn't find a Jabber scribe, 468 and it took a lot of begging to get someone to take minutes, so 469 they figured that was the best they could do. 471 o Sam is also a presenter, and Robert has a question about Sam's 472 presentation, but Sam is obviously not looking at the Jabber room 473 at the time. 475 o Rachel asks a question through Sam, and Pete replies. Len, who is 476 next in line at the mic, starts talking before Sam has a chance to 477 see whether or not Rachel has a follow-up question. 479 o Robert makes a point about one of Pete's slides, and Pete responds 480 "I don't think you're looking at the right slide" and continues 481 with his presentation. Robert cannot reply in a timely fashion 482 due to the lag in the audio channel. 484 o Pete starts his presentation by asking for questions to be held 485 until the end. Robert has a question about slide 5, and is 486 waiting until the end of the presentation to post the question in 487 the Jabber room. After slide 7, Len jumps to the mic and 488 vehemently disagrees with something that Pete said. Then Lee gets 489 up to respond to Len, and the three of them go at it for a while, 490 with Lee getting up again after slide 10. The presentation ends 491 and is over time, so Carl says "we need to move on", so Robert 492 never gets to ask his question. 494 o Chris asks "are there any more questions" while Rachel is typing 495 furiously, but she doesn't finish before Chris says "I don't see 496 anyone, thanks Pete, the next speaker is...". 498 o Rachel comments on Pete's presentation though Sam. Sam doesn't 499 understand what Rachel is asking, and Len goes to the mic to 500 explain. However, Len gets his explanation of what Rachel said 501 wrong and by the time Pete answers Len's interpretation, Rachel 502 gives up. 504 o This is the first time Pete is presenting at an IETF meeting, and 505 Robert has the first question, which is relayed through Sam. Pete 506 stays silent, not responding the question. Robert can't see 507 Pete's face to know if Pete is just not understanding what he 508 asked, is too afraid to answer, is just angry, or something else. 510 o Pete says something incorrect in his presentation, and Len asks 511 the folks in the Jabber room about it. Rachel figures out what 512 Pete should have said, and others in the Jabber room agree. No 513 one goes to the mic because Pete has left the topic, but only the 514 people watching Jabber know that the presentation was wrong. 516 o Pete says something that the AD sitting at the front of the room 517 (not near a mic) doesn't like, and the AD says a few sentences but 518 doesn't go to the mic. The chairs try to repeat what the AD says, 519 get it only approximately right, but the remote attendees do not 520 hear what really was said and therefore cannot comment 521 effectively. 523 o Sam only volunteered to be scribe because no one else would do it, 524 and isn't sitting close to the mic, and gets tired of getting up 525 and down all the time, and doesn't really agree with Robert on a 526 particular issue, so Sam doesn't relay a request from Robert. 528 o Rachel cannot join the Jabber room due to a client or server 529 software issue. She finally finds someone else on Jabber who is 530 also in the meeting, and gets them to invite her into the room. 532 3.3.2. Remotely Presenting 534 Some WGs have experimented with remote presentations at regular IETF 535 meetings, with quite mixed results. For some, it works fine: the 536 remote presenter speaks, the chair moves the slides forward, and 537 questions can be heard easily. For others, it is a mess: the local 538 attendees can't hear the presenter very well, the presenter can't 539 hear questions or there is a long delay, and it was not clear when 540 the presenter was waiting for input or there was a lag in the sound. 542 At a recent meeting that had a remote presenter, a WG had a video 543 camera set up at the chairs' desk pointed towards the audience so 544 that the presenter could see who was at the mic; this was considered 545 to be a great help and a lot friendlier because the presenter could 546 address the people at the mic by name. They also had the presenter's 547 head projected on the screen in the room, which led to a lot of jokes 548 and discussion of whether seeing the remote presenter caused people 549 to pay more attention. 551 Remote presenters have commented how difficult it is to set up their 552 systems, particularly because they are not sure whether their setup 553 is working until the moment they are supposed to be presenting. Even 554 then, the first few minutes of the presentation has a feeling of "is 555 this really working?". 557 [[[ TODO: More discussion about experiences with remote presenters. 558 Include more discussion of where it went well. ]]] 560 3.3.3. Floor Control 562 Although Section 3.3.1 may seem like it is a bit harsh on WG chairs, 563 the current tools do not give them the kind of control over remote 564 attendees that they have over local attendees. The chairs can tell 565 what is happening at the mics, but have much less view into what is 566 happening on Jabber, even if they are watching the Jabber room. 567 Without as much view, they cannot assist the flow of the conversation 568 as well. 570 o Carl sees that the Jabber room has an active and useful back- 571 channel discussion during Pete's provocative presentation. Pete 572 finishes and asks for questions. Lee and Len rush to the mic 573 line, and it takes Robert a few seconds to get his question into 574 the Jabber room and for Sam to go to the mic. Carl tries to 575 prioritize Sam forward in the line, but Len gets upset when he 576 does. 578 o Rachel asks a question, but Sam is not going to the mic to relay 579 it. In fact, Sam has pretty much stopped paying attention. Chris 580 cannot do something about the situation without making Sam look 581 bad. 583 o Pete has run over time, Robert asks what is supposed to be the 584 last question, and Pete doesn't understand what Sam said. Carl 585 cannot tell whether to wait for Robert to rephrase the question or 586 whether Robert even heard Pete's response. 588 o In a virtual interim where remote attendees all participate by 589 voice, someone can be heard typing / eating / talking loudly to 590 someone else. Carl and Chris try to get that person's attention 591 over the audio and Jabber, but to no avail. The tool being used 592 does not have the ability to mute individual participants, so the 593 meeting is disrupted until that person finally realizes that he or 594 she is not muted. 596 3.4. Remote Participation at IETF Interim WG Meetings 598 3.4.1. Face-to-Face Interim Meetings 600 Many interim meetings are held face-to-face in conference rooms 601 supplied by companies active in the IETF (and, much less often, in 602 commercial conference facilities such as hotels). Because these 603 facilities are not controlled by the IETF Secretariat, the ability to 604 include remote attendees varies widely. Some facilities can 605 distribute the in-room audio over the Internet just fine, while 606 others have no or limited abilities to do so. 608 For example, a recent face-to-face interim meeting was supposed to be 609 open to remote attendees through WebEx, but the sound coming from the 610 room was too soft to hear reliably. Even if a face-to-face interim 611 meeting has good facilities for audio and slide presenting, it will 612 probably have similar to regular IETF meetings. 614 3.4.2. Virtual Interim Meetings 616 Because few WGs have virtual interim meetings (those with no face-to- 617 face attendees), there is less experience with the tools that are 618 commonly used for them. The IETF has had free use of WebEx for a few 619 years, and some WGs have used different tools for audio 620 participation. For example, some virtual interims are held using 621 Skype, others with TeamSpeak, and so on. 623 So far, the experience with virtual interim meetings has been 624 reasonably good, and some people say that it is better than for 625 remote attendees at regular IETF meetings and face-to-face interims 626 because everyone has the same problems with getting the group's 627 attention. Also, there are no problems getting the in-room audio 628 into the RPS because all attendees are using their own computers for 629 speaking to the group. 631 One of the often-debated aspects of virtual interim meetings is what 632 time to have them in order to make them available to all 633 participants. Such scheduling of virtual interim meetings is out of 634 scope for this document. However, it is noted that because many 635 participants will be attending at different times of day and night, 636 no assumption can be made that participants will be at an "office". 637 This debate also affects face-to-face interim meetings because the 638 meeting hosts normally will schedule the meeting during business 639 hours at the host company, but that might be terribly inconvenient 640 for some WG members. 642 [[[ TODO: More discussion about experiences with virtual interims. 643 Focus on differences between the all-in-one systems like WebEx and 644 the cobble-together systems where there is an audio feed with no 645 floor control plus pre-distributed slideware. ]]] 647 4. Requirements for Supporting Remote Participation in Regular IETF 648 Meetings 650 This section covers the functional specification for effective remote 651 participation in meetings where some members are in regular IETF 652 face-to-face meetings. Some of the requirements in this section 653 overlap with those in Section 5, but many are unique to meetings that 654 have a large number of attendees physically present. 656 There is an assumption in this section that the meeting chairs will 657 continue to control the flow of the discussion. That is, if a 658 presenter is speaking and a remote attendee wants to ask a question, 659 the request to do so goes to the chair, not to the presenter. This 660 is covered in more detail in Section 4.2.2.1. 662 **Requirement 02-01**: The specifications SHOULD rely upon IETF and 663 other open standards for all communications and interactions wherever 664 possible. 666 **Requirement 02-02**: All tools in the RPS SHOULD be able to be run 667 on the widest possible array of computers. The tool may be a stand- 668 alone application, from any modern web browser, or from the command 669 line, but needs to be available on all of (at least) MacOS version 670 10.6 or later, Windows 7 or later, and any common Linux distribution 671 produced in 2010 or later. This also means that the tools MUST NOT 672 rely on Adobe Flash to work correctly. [[[ TODO: Do we need to 673 include IOS and Android platforms in that list? ]]] 674 **Requirement 02-03**: Audio, video, instant messaging, and slide 675 streams going to and from remote attendees SHOULD be delivered in as 676 close to real-time as is practically possible. A common complaint 677 with the current RPS is that the streaming audio can take more than 678 10 seconds (and sometimes as much as 30 seconds) to reach the remote 679 attendee. This causes many of the problems listed in Section 3.3.1. 681 [[[ TODO: Proposed replacement for this requirement is "Delays MUST 682 be less than X milliseconds greater than the network delay to the 683 remote attendee." Two values for X have been proposed: 200 and 500. 684 ]]] 686 [[[ TODO: A possibly different way to set the requirement is "The 687 audio MUST achieve a MOS (Mean Opinion Score) of 3.5 or better." And 688 there should probably be a discussion of a possible equivalent for 689 video. A proposal was "320x240 @ 15fps". ]]] 691 **Requirement 02-04**: The outgoing audio, video, and slide streams 692 MUST have the same delays so the remote participant does not get 693 confused during slide presentations. 695 **Requirement 02-05**: All streaming information from the RPS MUST be 696 usable over slow Internet connections. Many remote attendees will be 697 in places with limited bandwidth. [[[ TODO: We need to define "slow" 698 here, or drop the requirement.]]] 700 **Requirement 02-06**: All proposed tools MUST detail the bandwidth 701 required for each participant for various levels of participation 702 (audio-only, audio and video, and so on). 704 [[[ TODO: Is there a requirement for PSTN for audio-only? ]]] 706 **Requirement 02-07**: Audible echo in the audio stream MUST be 707 damped and/or eliminated by the tools. [[[ TOOD: Proposed 708 replacement: the RPS MUST recognize audible echo and automatically 709 take measures to reduce it to a level which won't distract listeners. 710 ]]] 712 **Requirement 02-08**: WG chairs MUST be able to test whether or not 713 the tools for their session are working at least 30 minutes before 714 the meeting begins (unless, of course, there is already another 715 meeting occurring in the room during that time). 717 **Requirement 02-09**: There MUST be written operational 718 documentation for each RPS tool that is accessible at all times. 719 This will help reduce problems where a WG chair is having problems 720 during a meeting that is affecting the meeting as a whole. 722 **Requirement 02-10**: There SHOULD be training materials for WG 723 chairs in how to use the RPS tools. 725 4.1. Registration for Remote Participation 727 There has been periodic discussion of whether or not remote attendees 728 are bound by the "Note Well" text that local attendees are bound to. 729 The core question is which local and remote attendees are 730 "contributors" based on the definitions in [BCP78]. By requiring 731 registration before participating, remote attendees can be better 732 alerted to, and thus hopefully bound to, the requirements of 733 contributors. 735 The cost for remote attendees to register, if any, is not covered in 736 this document but will instead be determined by the IETF at a later 737 time. There are many ideas on the subject (tiered costs for 738 different services, no cost at all for the first year, and others), 739 but the effects of different cost structures is beyond the scope of 740 this document. 742 **Requirement 02-11**: All remote attendees MUST register with the 743 IETF Secretariat before using any of the RPS tools described here. 744 Note that this would be a significant change to the current RPS tools 745 in that an unregistered person would not be able to use the IM 746 system. [[[ TODO: Should this be split into "unregistered people can 747 listen and read, but not contribute"? ]]] 749 **Requirement 02-12**: The RPS MUST have a system where a remote 750 attendee can register their name and have that name be used in the 751 instant messaging and video systems. Registration must only need to 752 be done once for an entire regular IETF meeting. 754 **Requirement 02-13**: A remote attendee may register a nickname that 755 will be shown to other attendees during the meeting. A remote 756 attendee must register with a "verified" name with the IETF 757 Secretariat. The nickname will appear in video and instant 758 messaging. [[[TODO: Is this anonymity appropriate in light of the 759 "note well" and floor control requirements? ]]] 761 **Requirement 02-14**: The RPS tools (particularly the registration 762 tool) MUST gracefully handle multiple attendees who have the same 763 name. 765 **Requirement 02-15**: To support the "blue sheet" functionality for 766 remote attendees, the registration tool SHOULD allow a registered 767 user to indicate which sessions he or she attended. This notations 768 SHOULD be allowed for all WG meetings throughout the meeting period. 769 The registration system SHOULD remind all registered remote attendees 770 at the end of the week to update their notations. 772 4.2. Audio 774 Audio from face-to-face meetings travels in two directions: from the 775 room to remote attendees, and from remote attendees to the room. 777 A few requirements come from the IETF's current use of audio in 778 meetings. Meeting rooms have many mics: one or two for the chairs, 779 one for the presenter, and at least one for other local attendees to 780 ask questions. Plenaries have many more mics, both at the front of 781 the room and in the audience. 783 **Requirement 02-16**: Remote attendees MUST be able to hear what is 784 said by local attendees and chairs at any mic in the meeting. 786 Comments on early drafts of this document indicated that the latter 787 may not really be a requirement for all participants if IM-to-mic is 788 made predictable. The two options are split below to make the 789 discussion clearer. Note that even if the consensus is towards IM- 790 to-mic, remote-to-room might still be required to enable remote 791 presenters; in this case, there would probably be little need for 792 floor control. The requirements for audio are expected to be 793 important discussion points in future versions of this document. 795 [[[ TODO: Should the ability to dial into a meeting stream via POTS 796 be a requirement? ]]] 798 4.2.1. IM-to-Mic Relay of Comments from Remote Participants 800 As described in Section 3.3.1, the current tools support an informal 801 method for remote attendees to speak at the mic: in the Jabber room, 802 they enter "mic:" before their comment and hope that the designated 803 scribe or someone else goes to the mic to relay the comment. This 804 method works, but has significant flaws described in that section. 806 **Requirement 02-17**: Relay of messages from IM to the mic MUST 807 happen as quickly as if the remote attendee was local. 809 **Requirement 02-18**: The person relaying from IM to the mic must be 810 available throughout the WG meeting. This could be facilitated by 811 hiring people to attend meetings for the specific purpose of being 812 IM-to-mic scribes. 814 **Requirement 02-19**: If multiple remote attendees want to comment 815 at the same time, the person relaying from IM to the mic MUST be able 816 to relay for all of them. 818 Note: during the development of this document, there have been many 819 suggestions for how WG chairs can better manage the IM-to-mic 820 relaying (for example, with planned pauses, better tracking of the IM 821 room, and so on). Some of those suggestions might turn into 822 requirements to be included in this document, but so far most of them 823 seem to be really about improving WG chairs, not the RPS tools. 825 4.2.2. Audio from Remote Participants to the Room 827 Note that the requirements here assume a very large change in the way 828 that remote participation will happen. Instead of a remote attendee 829 typing something into the Jabber room that someone will repeat at a 830 mic in the room, remote attendees will use their own mics to speak to 831 the meeting. 833 **Requirement 02-20**: Remote attendees MUST be able to speak 834 directly to a meeting without going through a local attendee, and 835 have their speaking be heard by local attendees. (Note that the 836 ability to speak is controlled by the chair; see Section 4.2.2.1.) 838 **Requirement 02-21**: Local attendees MUST be able to determine 839 which remote attendee is speaking. If the remote attendee is using a 840 nickname (see Requirement 02-13), that nickname can be used by the 841 remote speaker. 843 **Requirement 02-22**: The floor control portion of the RPS MUST give 844 a remote attendee who is allowed to speak a clear signal when they 845 should and should not speak. 847 **Requirement 02-23**: The audio system used by the RPS MUST be able 848 to integrate with systems commonly used in the venues used for IETF 849 meetings. IETF meetings happen in venues such as hotels and 850 conference centers, most of which have their own audio setups. The 851 IETF Secretariat contracts with those venues for the use of some or 852 all of their audio system. Without such integration, audio from 853 remote attendees might not be reliably heard by local participants. 855 **Requirement 02-24**: When a remote attendee connects to the audio 856 stream to the room, their mic SHOULD start off muted. This will 857 prevent problems such as those common with WebEx where a remote 858 attendee doesn't realize that they can be heard. 860 **Requirement 02-25**: Remote participants MUST be able to unmute 861 themselves; unmuting MUST NOT require interaction from the chair. 863 4.2.2.1. Floor Control for Chairs for Audio from Remote Attendees 865 Newcomers to regular IETF meetings often expect the floor control in 866 WG meetings to be fairly straight-forward. By Tuesday, they might be 867 shaking their heads, wondering why some people cut into the mic 868 lines, why some people get up to the mics after the chair has closed 869 the line, why some people ignore presenters' requests to hold 870 questions to the end, and so on. Mixing remote attendees into this 871 social structure will be a daunting task, but one that has been dealt 872 with in many remote participation systems. 874 It is not yet clear how the set of remote attendees would be treated 875 for queueing. Some tools have each remote attendee being considered 876 separately, while others pool all remote attendees into one group. 877 This affects the chair knowing and being able to act on the order 878 that remote attendees ask to speak. 880 Note that, if the remote video to room requirements from 881 Section 4.3.2 need to be met, it is very likely that a related 882 requirement to those below is that "the audio and video floor 883 controls must be in the same tool". 885 **Requirement 02-26**: Remote attendees MUST have an easy and 886 standardized way of requesting the attention of the chair when the 887 remote attendee wants to speak. The remote attendee MUST also be 888 able to easily cancel an attention request. (Note that Requirement 889 02-69 implies that someone is watching the request queue, something 890 that does not happen consistently with the current tools.) 892 A remote attendee might want to indicate that they are asking a 893 question of the presenter, or answering a question that someone else 894 asked at the mic, or want to bring up a new topic. **Requirement 895 02-27**: The RPS MUST allow a remote attendee's request for attention 896 to include an optional short text string. 898 **Requirement 02-28**: Remote attendee's requests MUST be part of the 899 floor control tool, not in the instant messaging system. 901 **Requirement 02-29**: The chair MUST be able to see all requests 902 from remote attendees to speak at any time during the entire meeting 903 (not just during presentations) in the floor control system. 905 **Requirement 02-30**: The floor control system MUST allow a chair to 906 easily turn off and on an individual's ability to speak over the 907 audio at any time. 909 **Requirement 02-31**: The floor control system MUST allow a chair to 910 easily mute all remote attendees. 912 **Requirement 02-32**: The floor control system MUST allow a chair to 913 easily allow all remote attendees to speak without requesting 914 permission; that is, the chair MUST be able to easily turn on all 915 remote attendees mics at once. 917 It is common for a chair to leave the room, to have a side discussion 918 with an AD, or to become a presenter. They should be able to do so 919 without having to do a handoff of the floor control capability. 920 **Requirement 02-33**: The floor control system for the chair MUST be 921 able to be run by at least two users at the same time. 923 **Requirement 02-34**: The RPS MUST authenticate users who can use 924 the floor control system in a particular meeting using simple 925 passwords. 927 **Requirement 02-35**: The IETF Secretariat MUST be able to easily 928 set up the individuals allowed to use the floor control system for a 929 particular meeting and to change the settings at any time, including 930 during the meeting. [[[ TODO: Should those who are given floor 931 control be allowed to augment that list to meet changing needs 932 without going back to the Secretariat? ]]] 934 [[[ TODO: Is it possible to tell if a remote attendee who is speaking 935 loses network connectivity? If so, maybe this can be shown to the 936 chair. ]]] 938 **Requirement 02-36**: The chair SHOULD be able to monitor the sound 939 levels of the audio being delivered to remote attendees to be sure 940 that they can hear what is going on in the room. 942 4.3. Video 944 The RFP that preceded the current document, [RPS-RFP], discusses 945 video as a requirement. The IETF has experimented with one-way and 946 two-way video at some meetings in the past few years. Remote 947 attendees have said that seeing people in the meetings gave them a 948 better understanding of the meeting; at a recent meeting, a remote 949 presenter was able to see the people in line at the mic and was 950 better able to interact with them. [[[ TODO: determine how much of 951 this is needed for effective participation. ]]] 953 4.3.1. Video from the Room to Remote Participants 955 **Requirement 02-37**: Remote attendees MUST be able to see the 956 presenter at a meeting. 958 **Requirement 02-38**: Remote attendees MUST be able to see local 959 attendees at any mic in the meeting. 961 [[[ TODO: Is there a requirement that IETF video integrate with the 962 venue video, if any? ]]] 964 4.3.2. Video from Remote Participants to the Room 966 Note that the requirements in this section probably only apply if 967 there is consensus that audio from remote participants to the room is 968 required. If so, there will probably also be requirements for video 969 floor control as well. 971 **Requirement 02-39**: The RPS MUST have the capability of showing 972 video of the remote attendee who is speaking over the audio to the 973 local attendees. 975 **Requirement 02-40**: A remote attendee who is speaking MUST be able 976 to choose what is shown to local attendees: video of them speaking, a 977 still picture of their face, or just their name. 979 **Requirement 02-41**: The RPS MUST give a remote attendee a clear 980 indication when their video image is being shown to the local 981 attendees. 983 [[[ TODO: The way to fulfill these might be that the IETF provide a 984 laptop for the chair that has the right tools on it, and that laptop 985 is the one connected to the projector. ]]] 987 4.4. Instant Messaging 989 Instant messaging (IM) is used both as a remote participation tool 990 and as a communication tool for local attendees at a regular meeting. 991 As noted earlier, while the current tool's Jabber room is a good way 992 to get questions to the mic, it also becomes a second communications 993 channel that only a few people in the room are participating in. 994 This document does not address how to prevent that problem (or 995 whether it really is much of a problem). The instant messaging 996 system is also useful for remote users to ask about the status of the 997 room ("is anyone there?"). 999 **Requirement 02-42**: The IM system MUST allow anyone to see all 1000 messages in the WG's or BoF's room. **Requirement 02-43**: The IM 1001 system MUST allow any registered user (even those registered to use 1002 anonymous names) to post messages in the WG's or BoF's room. 1004 Someone coming into a meeting late requires context for which 1005 messages in an instant messaging room are recent and which are old. 1006 **Requirement 02-44**: The date and time that a message appears in an 1007 IM stream MUST be retained. IM clients MUST be able to show an 1008 indication of the date and time for all messages. 1010 [[[ TODO: Should there be multiple rooms for a meeting? There were 1011 many requests for a separate "speak into the mic" room, but that is 1012 not needed if the requirements in Section 4.2.2 are met. Is there a 1013 need for other rooms? ]]] 1015 [[[ TODO: Should non-registered people be allowed to read the IM 1016 traffic in real time, given that anyone can register anonymously? 1017 Should people registered anonymously be allowed to post in IM rooms? 1018 Should non-registered attendees be able to post to the IM rooms? ]]] 1020 4.5. Slide Presentations 1022 Slides are presented in regular IETF meetings with projectors on a 1023 screen at the front of the room from the video output of one or more 1024 local attendees' computers. If slides are to be presented to remote 1025 attendees, the slides being projecte need to also be sent as a stream 1026 to the remote attendees. 1028 In many current remote participation systems, slide presentations and 1029 the video coming from in-meeting cameras are sent as two separate 1030 streams (called the "slide stream" and the "camera stream"). The 1031 slide stream is usually much lower bandwidth than the camera stream, 1032 so remote attendees with limited bandwidth can choose to watch just 1033 the slides but not the local attendees. Further, separating the 1034 streams allows remote attendees to see the slide stream and the 1035 camera streams in separate windows that can be independently sized. 1037 **Requirement 02-45**: The RPS MUST transmit the slide stream 1038 separately from the camera stream. **Requirement 02-46**: The slide 1039 stream MUST represent the slides as they are projected in the room, 1040 allowing the presenter to go back and forth, as well as to edit 1041 slides in real time. 1043 **Requirement 02-47**: It MUST be made clear to the remote attendees 1044 which set of slides, and which slide number, is being currently 1045 shown. 1047 [[[ TODO: If the slides will be visible to remote attendees as they 1048 are presented, is there a requirement that presenters be able to use 1049 the equivalent of a laser pointer? ]]] 1051 4.6. Slide Distribution 1053 Slides are available to local and remote attendees on the IETF 1054 servers before and during regular IETF meetings. This service is 1055 useful to all attendees who want to be prepared for WG meetings. The 1056 slides are not only used by remote attendees listening to the WG 1057 meeting; it is common for local attendees to download the slides and 1058 view them on their laptops during meetings instead of having to read 1059 them at the front of the room. 1061 **Requirement 02-48**: The RPS MUST be able to handle both PDF and 1062 PowerPoint formats (".ppt" and ".pptx") for distributed slides. [[[ 1063 TODO: Is there a requirement to support other formats? ]]] [[[ TODO: 1064 For the distributed slides, is there a requirement that animation in 1065 PowerPoint be supported, or just static slides? ]]] 1067 **Requirement 02-49**: The RPS MUST automatically convert PowerPoint 1068 presentations to PDF and make both available for distribution at the 1069 same time. 1071 **Requirement 02-50**: Presenters MUST be able to update their slides 1072 on the IETF site up to just before their presentation, if such update 1073 is allowed by the chairs. 1075 **Requirement 02-51**: Chairs MUST be able to approve or disapprove 1076 of any slide submission or updates, with the default being that all 1077 submissions are allowed. 1079 4.7. Shared Document Editing 1081 In some WG meetings, there is an attempt to edit a document with 1082 input from the local attendees. This is typically done for proposed 1083 charter changes, but sometimes happens on a WG document or the 1084 meeting's agenda. This is usually unsuccessful, given the amount of 1085 text and the size of what can be displayed on the screen. In recent 1086 meetings, shared document editing has been used for editing charters 1087 and for taking minutes of meetings. 1089 An RPS tool for shared document editing would be equally useful for 1090 local and remote attendees watching the edits happen in real-time. 1091 There is a good chance that this tool would be watched by local 1092 attendees on their laptops instead of being projected on the screen 1093 because of the small size of the the text. This, in turn, means that 1094 local attendees who aren't using their laptops at the moment would 1095 not be able to participate by watching. 1097 **Requirement 02-52**: It MUST be easy to start a new shared document 1098 and to import existing text into a shared document. 1100 **Requirement 02-53**: Shared real-time editing of text-only 1101 documents MUST be supported. This system must allow at least three 1102 people to have write access and hundreds of people to have read 1103 access to any particular document. 1105 **Requirement 02-54**: Remote attendees MUST be able to be either the 1106 writers or the readers of shared documents. 1108 **Requirement 02-55**: Those with read access MUST be able to see the 1109 edits made by those with write access within less that five seconds 1110 after each edit. 1112 **Requirement 02-56**: It MUST be easy to change the permissions for 1113 who gets write access to a document during an editing session. 1115 [[[ TODO: Is this also needed for non-text documents? If so, in what 1116 formats? For example, is drawing on a whiteboard needed? ]]] 1118 4.8. Archiving 1120 Archived recordings of the events of the meetings are valuable for 1121 remote attendees who are not able to hear everything in real time. 1123 **Requirement 02-57**: The RPS MUST support storage and distribution 1124 of recordings of the audio, video, and slide presentations for all 1125 sessions after IETF meetings. **Requirement 02-58**: Transcripts of 1126 the instant messaging for all meetings MUST be kept for distribution 1127 after IETF meetings. **Requirement 02-59**: The recordings and 1128 transcripts SHOULD be made available during the meetings, within a 1129 day of them being made. 1131 **Requirement 02-60**: Users MUST be able to easily find the archives 1132 of the recordings and instant messaging transcripts of a particular 1133 WG or BoF session at a particular meeting. 1135 **Requirement 02-61**: The RPS SHOULD support indexing of archived 1136 audio and video for particular events in meetings such as when 1137 speakers change. 1139 **Requirement 02-62**: The RPS MUST support recording and storage of 1140 recordings of the audio, video, and slide presentations of interim 1141 meetings as well as regular IETF meetings. 1143 4.9. Transcription 1145 **Requirement 02-63**: Transmitting real-time transcription to remote 1146 attendees MUST be supported. The lag in transmission MUST be less 1147 than five seconds. 1149 4.10. Polling 1151 The common IETF method of assessing support is a straw poll, 1152 sometimes managed by audible humming, sometimes by raising hands. 1154 **Requirement 02-64**: A system for polling meeting participants, 1155 including remote attendees at the same time, MUST be provided. It 1156 MUST be easy to set up a simple poll, and it must be easy for all 1157 participants to find the poll and participate. Note that this would 1158 add a requirement that everyone in a meeting be using their computer 1159 to participate in the poll. [[[ TODO: Should the RPS also provide a 1160 tool that allows yes / no / abstain indications, which comes a lot 1161 closer to "voting" than currently is common? ]]] 1163 4.11. Plenaries 1165 At recent IETF meetings, there has been very little input from remote 1166 attendees even when there is a lot in the room, but that may be due 1167 to the current setup, not lack of interest. 1169 **Requirement 02-65**: Remote attendees SHOULD be able to make 1170 comments at the mic approximately as well as if they were local 1171 attendees. This means that either remote audio to the plenary room 1172 speakers be available, or that IM-to-room relay be available. 1174 [[[ TODO: Are there other requirements that are special to plenaries 1175 that are not covered above? Are there requirements not listed above 1176 that mostly come from plenaries that would also apply to very large 1177 WGs? ]]] 1179 4.12. Use by IETF Leadership 1181 The requirements for bodies like the IESG and IAB to use the RPS 1182 during regular IETF meetings are similar to those of most WGs. The 1183 main difference is that they need a way to limit who can participate 1184 remotely. 1186 **Requirement 02-66**: The IETF Secretariat MUST be able to easily 1187 limit remote access to meetings on a room-by-room basis. 1189 **Requirement 02-67**: The IETF Secretariat must be able to limit 1190 participants in restricted meetings using a simple authentication 1191 mechanism. 1193 Note that the IETF leadership will also heavily use the remote 1194 participation tools between IETF meetings in a manner that is very 1195 similar to virtual interim meetings. 1197 4.13. Additional Requirements for Remote Participation 1199 **Requirement 02-68**: Remote attendees MUST be able to easily find 1200 all the material they need to effectively participate, including 1201 links to audio, video, instant messaging, slides, and so on. This 1202 material MUST be available well before the time of the meeting. The 1203 page with the meeting material SHOULD allow the remote attendee to 1204 easily perform a time conversion to and from the local time at the 1205 IETF meeting. 1207 **Requirement 02-69**: A remote attendee who comes to a meeting late 1208 MUST be able to tell what is happening in the meeting. In specific, 1209 there MUST be an indication if the meeting has not started, if the 1210 meeting is happening (even if there is silence on the mics), and if 1211 the meeting is over. 1213 Remote attendees need to be able to test the remote participation 1214 setup before a regular meeting, and even during the meeting. 1215 **Requirement 02-70**: There MUST be a constantly-running testing 1216 service that covers all interactive tools (audio, video, slide 1217 display, and so on) for at least a week before the meeting begins. 1218 **Requirement 02-71**: The testing service MUST run throughout the 1219 meeting so that last-minute joiners can test their systems. 1220 **Requirement 02-72**: The testing service SHOULD allow remote 1221 attendees to also test whether their outgoing audio, video, and slide 1222 control works. 1224 **Requirement 02-73**: Remote attendees SHOULD be able to easily 1225 contact the IETF Secretariat if they find problems with any of the 1226 RPS tools, and to get fairly rapid response. 1228 **Requirement 02-74**: Similarly, local attendees SHOULD be able to 1229 easily contact the IETF Secretariat if there are RPS problems in the 1230 meeting rooms. 1232 **Requirement 02-75**: The RPS tools MUST be available for AD- 1233 sponsored lunch meetings scheduled by the IETF Secretariat. Regular 1234 IETF meetings are more than just a group of WG meetings. Remote 1235 attendees may want to participate in the other parts of a regular 1236 meeting as well. 1238 **Requirement 02-76**: Any tools that are used by remote attendees 1239 MUST also be available to local attendees as well. At many IETF 1240 meetings, some local attendees act as remote attendees in WG meetings 1241 that they are not sitting in, so they can attend two WGs at once. 1243 5. Requirements for Supporting Remote Participation in Interim Meetings 1245 One of the goals of this document is to increase the effectiveness of 1246 interim meetings. Interim meetings are now uncommon, but might 1247 become more common (and more effective) if the remote participation 1248 becomes more useful. 1250 **Requirement 02-77**: The RPS SHOULD have a central location where 1251 the specifics about how remote participation is supported for every 1252 WG interim meeting. This will reduce the problems often seen where 1253 messages about how to participate in an interim meeting get buried in 1254 the WG mailing list. 1256 **Requirement 02-78**: There SHOULD be documentation and training for 1257 the RPS tools specifically targeted at WG chairs who will lead 1258 interim meetings. 1260 [[[ TODO: Determine how much or how little the IETF Secretariat 1261 should participate in setting up the RPS for interim meetings. The 1262 IETF Secretariat currently offers some help to some WGs, but this 1263 might become more formalized in the future. ]]] 1265 5.1. Requirements for Supporting Remote Participation in Face-to-Face 1266 Interim Meetings 1268 Face-to-face interim meetings have many things in common with regular 1269 IETF meetings, but there are also many significant differences. For 1270 most WGs, fewer people attend interim meetings than IETF meetings, 1271 although those who travel to a face-to-face interim meeting are often 1272 the more active WG participants. There may be a larger demand for 1273 remote participation because people have a harder time justifying 1274 travel for a single WG meeting than for an IETF meeting, but there 1275 may also be less demand because people tend to think of interim WG 1276 meetings as less important than regular IETF meetings.. 1278 Typically, the IETF Secretariat does not control the rooms in which 1279 face-to-face interims are held, so they have no control over whether 1280 outgoing audio will be supported, or supported well enough to 1281 guarantee that remote attendees can hear. [[[ TODO: Should the IETF 1282 Secretariat be tasked with helping set up face-to-face interims? ]]] 1284 **Requirement 02-79**: The RPS tools MUST be at least partially 1285 usable at face-to-face meetings other than regular IETF meetings. 1286 The number of the tools that might be available will be different for 1287 different venues for the virtual interims, but at a minimum, the 1288 following MUST be supported for remote attendees: 1290 o Room audio 1292 o Instant messaging 1294 o Slide distribution 1296 o Slide presentation 1297 o Shared document editing 1299 [[[ TODO: What are the requirements for registering? Interim 1300 meetings are generally considered to have a very different feeling 1301 than regular IETF meetings; does this affect the idea of 1302 registration? What if registration is cheap but not free? ]]] 1304 5.2. Requirements for Supporting All-Remote Interim Meetings 1306 The requirements for meetings that are all remote (that is, with no 1307 local attendees) are mostly a subset of the requirements for remote 1308 participation in a regular IETF meetings and face-to-face interim 1309 meeting. This section highlights the differences from Section 4 and 1310 Section 5.1. 1312 Video for all-remote meetings may be more important than for face-to- 1313 face meetings in order to help the chair with floor control. [[[ 1314 TODO: Determine if this is true and, if so, the additional 1315 requirements for all the remote attendees. ]]] 1317 Attendance at virtual interim meetings is supposed to be taken, but 1318 this is sometimes ignored. A system that is probably at least 1319 somewhat different than that in Section 4.13 may be needed for 1320 collecting attendance at virtual interim meetings. [[[ TODO: What are 1321 the requirements for registering? Virtual interim meetings are 1322 generally considered to have a very different feeling than regular 1323 IETF meetings; does this affect the idea of registration? ]]] 1325 [[[ TODO: Are there different floor control issues for all-remote 1326 meetings? ]]] 1328 6. IANA Considerations 1330 None. [[ ...and thus this section can be removed before publication 1331 as an RFC... ]] 1333 7. Security Considerations 1335 People who participate remotely in face-to-face IETF meetings might 1336 expect the same level of privacy as they have when they participate 1337 directly in those meetings. Some of the proposed tools might cause 1338 it to be easier to know which WGs a remote attendee was following. 1339 When RPS tools are deployed, the IETF should describe the privacy 1340 implications of using such a tool to the users so they can decide 1341 whether or not to use the tools. 1343 The eventual RPS tools will have some user authentication that will 1344 associate people with actions. For example, a remote user might need 1345 to authenticate to the system in order to give a presentation or 1346 speak during a session. The credentials needed for this 1347 authentication will need to be managed in a secure fashion, both by 1348 the system and by the people who are being identified. 1350 8. Acknowledgements 1352 Many of the ideas in this document were contributed by members of the 1353 IETF community based on their experiences during recent IETF 1354 meetings. There are also many contributions from people on the 1355 vmeet@ietf.org mailing list as well as WG chairs. 1357 Some of the text in this document originated in the request for 1358 proposals that was issued by the IAOC that led to this document. 1360 9. Informative References 1362 [BCP78] Bradner, S. and J. Contreras, "Rights Contributors Provide 1363 to the IETF Trust", BCP 78, RFC 5378, November 2008. 1365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1366 Requirement Levels", BCP 14, RFC 2119, March 1997. 1368 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 1369 Procedures", BCP 25, RFC 2418, September 1998. 1371 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1372 Protocol (XMPP): Core", RFC 6120, March 2011. 1374 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1375 Protocol (XMPP): Instant Messaging and Presence", 1376 RFC 6121, March 2011. 1378 [RPS-RFP] IAOC, "Request for Proposals for Requirements Development 1379 for Remote Participation Services", 2011, . 1383 Author's Address 1385 Paul Hoffman 1386 VPN Consortium 1388 Email: paul.hoffman@vpnc.org