idnits 2.17.1 draft-ietf-genarea-rps-reqs-03.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 (March 9, 2012) is 4429 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 March 9, 2012 5 Expires: September 10, 2012 7 Requirements for Remote Participation Services for the IETF 8 draft-ietf-genarea-rps-reqs-03 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 September 10, 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 . . . . . . . . . . . . . . . . . . . . 24 85 4.7. Shared Document Editing . . . . . . . . . . . . . . . . . 24 86 4.8. Archiving . . . . . . . . . . . . . . . . . . . . . . . . 25 87 4.9. Transcription . . . . . . . . . . . . . . . . . . . . . . 26 88 4.10. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 4.11. Plenaries . . . . . . . . . . . . . . . . . . . . . . . . 26 90 4.12. Use by IETF Leadership . . . . . . . . . . . . . . . . . . 26 91 4.13. Additional Requirements for Remote Participation . . . . . 27 92 5. Requirements for Supporting Remote Participation in 93 Interim Meetings . . . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . . . 30 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 100 9. Informative References . . . . . . . . . . . . . . . . . . . . 30 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 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 03-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 called out in this document as 232 "**Functional spec 03-00**". 234 The requirements and functional specifications covered in this 235 document apply almost exclusively to tools and services that are used 236 for remote participation in real-time meetings. The document does 237 not cover the many other tools used by WGs for non-real-time 238 communication such as mailing lists, issue trackers, document flow 239 control systems, and so on. Many of the non-real-time tools are also 240 being improved over time, but they are not the subject of this 241 document. 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in RFC 2119 [RFC2119]. 247 This document is being discussed on the vmeet@ietf.org mailing list. 248 See for more 249 information. 251 2. Scenarios Required to be Supported 253 The are many IETF-related activities that can be aided by remote 254 participation tools. The scenarios in which the RPS described in 255 this document is expected to be used are: 257 o WG sessions at regular IETF meetings -- A typical regular IETF 258 meeting has about 150 sessions, with up to 8 of those sessions 259 happening at the same time. A session might have between 20 and 260 200 local attendees in the room, and might have only a few or many 261 dozens of remote attendees. WG sessions typically have one to 262 three co-chairs at the front of the room and a series of 263 individuals who come to the front to present; some presentations 264 are made by small panels. 266 o Plenaries at regular IETF meetings -- There are usually two 267 plenaries at a regular IETF meeting, with on-site attendance of 268 about 700 local attendees and dozens of remote attendees. There 269 are from 1 to 20 presenters; presentations may be made by multiple 270 people. 272 o Face-to-face interim WG meetings -- Between regular IETF meetings, 273 some WGs hold interim meetings where participants get together at 274 a site (often a company's meeting room, but sometimes a meeting 275 room rented at a hotel). At such meetings, there are between a 276 handful and a few dozen local attendees and a similar number of 277 remote attendees. Presentations are common. 279 o Virtual interim WG meetings -- Between regular IETF meetings, some 280 WGs hold virtual interim meetings where there are no local 281 attendees because there is no central meeting location. There are 282 between a handful and a few dozen attendees. Presentations are 283 common. 285 o IETF leadership meetings -- The IETF leadership (the IESG, IAOC, 286 IAB, and probably others) have periodic virtual meetings, usually 287 with presentations. These groups also meet at the regular IETF 288 meetings, and sometimes have remote attendees at those meetings 289 (such as members who cannot attend the IETF meeting or presenters 290 who are not part of the leadership group). 292 [[[ TODO: Count the number of f2f and virtual interims from the past 293 few years. ]]] 295 3. Interactions with Current RPS Tools Used by the IETF 297 Users' experience with the current IETF tools vary widely. Some 298 participants think the tools are fine and are grateful that they 299 exist. Other participants find them barely acceptable because they 300 have used better tools in other environments. Often, local attendees 301 mostly forget that the remote attendees are participating until one 302 gets something said at the mic. Local attendees don't have a feeling 303 for how many remote attendees are just listening like most of the 304 local attendees. 306 The variety of current experiences can help inform the discussion of 307 how to improve the tools. The requirements here are derived from the 308 current tools; later sections derive requirements from needs that are 309 not at all met by the current tools. 311 The IETF has years of experience with the two primary tools used at 312 its regular meetings (Jabber for IM and streaming audio). This 313 section discusses some of the reactions of users -- those in the 314 meetings and those who have participated remotely -- to the current 315 tools. 317 3.1. Technologies Currently Used at Regular IETF Meetings 319 There are three tools that are used by remote attendees for WG 320 participation at regular IETF meetings: real-time audio, instant 321 messaging, and slides. 323 For the past few years, the IETF has used audio streamed over HTTP 324 over TCP. TCP is often buffered at many places between (and in) the 325 origination in the IETF meeting venue and the users' computer. At 326 recent meetings, delays of around 30 seconds have been recorded, with 327 minimum delays typically being five seconds. This delay is caused by 328 buffering at the hop-by-hop ISPs and in the remote attendee's 329 computer. At recent IETF meetings, remote attendance is almost 330 always less than 10% of local attendance, and is often less than 5%. 331 (There are more remote attendees when the IETF meeting is in the 332 U.S.) Each stream is represented by an MP3 playlist (sometimes called 333 an "m3u file"). 335 The IETF long ago standardized on Jabber / XMPP ([RFC6120], 336 [RFC6121], and others) for instant messaging used within the IETF. 337 Jabber rooms (formally called "multi-user conferences" or "MUCs") 338 exist for every WG, and those rooms are live all the time, not just 339 during regular IETF meetings. There are also stable Jabber rooms for 340 the plenaries and certain other activities. BoFs are usually 341 assigned Jabber rooms before a regular meeting. 343 Presentation slides normally are stored either as PDFs or in one of 344 Microsoft's formats for PowerPoint. They are projected on a local 345 screen from someone's laptop computer. 347 There has been experience at recent meetings with two tools, WebEx 348 and Meetecho, which are supported experimentally by the IETF. Each 349 tool was used by a handful of WGs with mixed success. The tools 350 require remote attendees to use specific clients, and installation of 351 those clients caused problems for some people. On the other hand, 352 the tools have much more robust meeting control features, and 353 participants appreciated the real-time showing of slides during 354 presentations. 356 3.2. Locating the Meeting Information 358 Finding information for the real-time audio, instant messaging, and 359 slides for an upcoming or current regular meeting is complicated by 360 that information being in many different locations on the IETF web 361 site, and the fact that the relevant URLs can change before and even 362 during the meeting. Further, a WG chair might copy the latest 363 information and send it to the WG mailing list, but there can be 364 later changes. Experienced remote attendees have gotten used to 365 checking just before the meeting itself, but even that does not 366 always guarantee the correct information. 368 Currently, the meeting information appears in two different agendas: 370 o The official agenda on the IETF Datatracker includes links to 371 venue maps, WG charters, agendas, and Internet-Drafts. For 372 example, see 373 . 375 o The unofficial "tools-style agenda" includes the same links as the 376 official agenda plus links to the presentations, audio, minutes, 377 Jabber room, and Jabber logs 9represnted as small icons). For 378 example, see . 380 3.2.1. Audio 382 The URL for the audio stream for a WG or BoF meeting is based on the 383 room that the meeting is in. The audio streams are announced on the 384 general IETF mailing list (ietf@ietf.org) before each meeting. 386 A common complaint is that when a WG meeting moves to a different 387 room, remote users need to know about the move so that they can use 388 the proper URL to hear the audio stream. The room changes are often, 389 but not always, announced on WG mailing lists; when they are not 390 announced, there is no easy way for a remote attendee to find out 391 which audio stream they should be listening to. Sometimes, room 392 changes happen just as a WG meeting is starting, making it nearly 393 impossible for a remote attendee to know about the change in streams. 395 3.2.2. Instant Messaging 397 The Jabber rooms used by WGs and BoFs do not change between IETF 398 meetings, so finding the right Jabber room is relatively easy. Some 399 Jabber clients have odd interfaces for joining Jabber rooms, and this 400 can cause some problems; even though participants can test their 401 Jabber clients before a meeting, there still seems to be some who 402 need help just before a WG meeting. There are sometimes problems 403 with people joining Jabber rooms; in these cases, the participant 404 needs to find someone already in the Jabber room to invite them to 405 the discussion. 407 3.2.3. Slides 409 Slides are available from the meeting materials page. Many, but 410 certainly not all, local and remote attendees know how to find the 411 meeting materials page. 413 It has become fairly common for presenters to not have their 414 presentations available for distribution until just before the WG 415 meeting. Because materials are uploaded by the WG chairs, this often 416 causes the beginning of WG meetings to be a dance involving 417 presenters giving the chairs their slides, followed by chairs 418 uploading the slides to the IETF site, followed by the chairs saying 419 "the slides are there now". 421 3.3. Remote Participation at IETF Meetings 423 3.3.1. Remotely Speaking at the Mic 425 In order for a remote attendee to speak at the mic, a local attendee 426 must say it for them. In most WG and BoF meetings, this is done by 427 the remote attendee typing into the Jabber room for the meeting, and 428 some local attendee going to the mic and repeating what was typed 429 into the Jabber room. Remote attendees often precede what they want 430 said at the mic with the string "mic:" to differentiate that from the 431 rest of the discussion in the Jabber room. 433 This method of participation often works adequately, but there are 434 many places where it fails. The following is a compendium of stories 435 from recent IETF meetings and interim face-to-face meetings where 436 remotely speaking at the mic didn't work as well as it could have. 437 The participants are Chris and Carl (WG co-chairs), Sam (volunteer 438 Jabber scribe), Rachel and Robert (remote attendees), Pete 439 (presenter), and Len and Lee (local attendees). 441 o Robert cannot understand what Pete is saying about slide 5, but 442 Sam doesn't get Pete's attention until Pete is already on slide 7 443 and Pete doesn't want to go back. 445 o Rachel wants to say something, but Sam's Jabber client has crashed 446 and no one else in the Jabber room knows why Sam isn't going to 447 the mic. 449 o Robert wants to say something, but Sam is already at the mic 450 speaking for Rachel so Sam doesn't see Robert's message until he 451 has gotten out of the mic line. 453 o Sam is speaking for Robert, and Rachel wants to comment on what 454 Robert said. Unless Sam reads the message as he is walking back 455 to his seat, Rachel doesn't get to speak. 457 o Robert wants to say something at the mic, but Sam is having an 458 important side discussion with the AD. 460 o Sam is also the minutes taker, and is too busy at the moment 461 catching up with the lively debate at the mic to relay a question 462 from Rachel. 464 o Chris thought Carl was watching the Jabber room, but Carl was 465 reading the draft that is being discussed. 467 o Chris and Carl start the meeting by asking for volunteers to take 468 minutes and be Jabber scribe. They couldn't find a Jabber scribe, 469 and it took a lot of begging to get someone to take minutes, so 470 they figured that was the best they could do. 472 o Sam is also a presenter, and Robert has a question about Sam's 473 presentation, but Sam is obviously not looking at the Jabber room 474 at the time. 476 o Rachel asks a question through Sam, and Pete replies. Len, who is 477 next in line at the mic, starts talking before Sam has a chance to 478 see whether or not Rachel has a follow-up question. 480 o Robert makes a point about one of Pete's slides, and Pete responds 481 "I don't think you're looking at the right slide" and continues 482 with his presentation. Robert cannot reply in a timely fashion 483 due to the lag in the audio channel. 485 o Pete starts his presentation by asking for questions to be held 486 until the end. Robert has a question about slide 5, and is 487 waiting until the end of the presentation to post the question in 488 the Jabber room. After slide 7, Len jumps to the mic and 489 vehemently disagrees with something that Pete said. Then Lee gets 490 up to respond to Len, and the three of them go at it for a while, 491 with Lee getting up again after slide 10. The presentation ends 492 and is over time, so Carl says "we need to move on", so Robert 493 never gets to ask his question. 495 o Chris asks "are there any more questions" while Rachel is typing 496 furiously, but she doesn't finish before Chris says "I don't see 497 anyone, thanks Pete, the next speaker is...". 499 o Rachel comments on Pete's presentation though Sam. Sam doesn't 500 understand what Rachel is asking, and Len goes to the mic to 501 explain. However, Len gets his explanation of what Rachel said 502 wrong and by the time Pete answers Len's interpretation, Rachel 503 gives up. 505 o This is the first time Pete is presenting at an IETF meeting, and 506 Robert has the first question, which is relayed through Sam. Pete 507 stays silent, not responding the question. Robert can't see 508 Pete's face to know if Pete is just not understanding what he 509 asked, is too afraid to answer, is just angry, or something else. 511 o Pete says something incorrect in his presentation, and Len asks 512 the folks in the Jabber room about it. Rachel figures out what 513 Pete should have said, and others in the Jabber room agree. No 514 one goes to the mic because Pete has left the topic, but only the 515 people watching Jabber know that the presentation was wrong. 517 o Pete says something that the AD sitting at the front of the room 518 (not near a mic) doesn't like, and the AD says a few sentences but 519 doesn't go to the mic. The chairs try to repeat what the AD says, 520 get it only approximately right, but the remote attendees do not 521 hear what really was said and therefore cannot comment 522 effectively. 524 o Sam only volunteered to be scribe because no one else would do it, 525 and isn't sitting close to the mic, and gets tired of getting up 526 and down all the time, and doesn't really agree with Robert on a 527 particular issue, so Sam doesn't relay a request from Robert. 529 o Rachel cannot join the Jabber room due to a client or server 530 software issue. She finally finds someone else on Jabber who is 531 also in the meeting, and gets them to invite her into the room. 533 3.3.2. Remotely Presenting 535 Some WGs have experimented with remote presentations at regular IETF 536 meetings, with quite mixed results. For some, it works fine: the 537 remote presenter speaks, the chair moves the slides forward, and 538 questions can be heard easily. For others, it is a mess: the local 539 attendees can't hear the presenter very well, the presenter can't 540 hear questions or there is a long delay, and it was not clear when 541 the presenter was waiting for input or there was a lag in the sound. 543 At a recent meeting that had a remote presenter, a WG had a video 544 camera set up at the chairs' desk pointed towards the audience so 545 that the presenter could see who was at the mic; this was considered 546 to be a great help and a lot friendlier because the presenter could 547 address the people at the mic by name. They also had the presenter's 548 head projected on the screen in the room, which led to a lot of jokes 549 and discussion of whether seeing the remote presenter caused people 550 to pay more attention. 552 Remote presenters have commented how difficult it is to set up their 553 systems, particularly because they are not sure whether their setup 554 is working until the moment they are supposed to be presenting. Even 555 then, the first few minutes of the presentation has a feeling of "is 556 this really working?". 558 [[[ TODO: More discussion about experiences with remote presenters. 559 Include more discussion of where it went well. ]]] 561 3.3.3. Floor Control 563 Although Section 3.3.1 may seem like it is a bit harsh on WG chairs, 564 the current tools do not give them the kind of control over remote 565 attendees that they have over local attendees. The chairs can tell 566 what is happening at the mics, but have much less view into what is 567 happening on Jabber, even if they are watching the Jabber room. 568 Without as much view, they cannot assist the flow of the conversation 569 as well. 571 o Carl sees that the Jabber room has an active and useful back- 572 channel discussion during Pete's provocative presentation. Pete 573 finishes and asks for questions. Lee and Len rush to the mic 574 line, and it takes Robert a few seconds to get his question into 575 the Jabber room and for Sam to go to the mic. Carl tries to 576 prioritize Sam forward in the line, but Len gets upset when he 577 does. 579 o Rachel asks a question, but Sam is not going to the mic to relay 580 it. In fact, Sam has pretty much stopped paying attention. Chris 581 cannot do something about the situation without making Sam look 582 bad. 584 o Pete has run over time, Robert asks what is supposed to be the 585 last question, and Pete doesn't understand what Sam said. Carl 586 cannot tell whether to wait for Robert to rephrase the question or 587 whether Robert even heard Pete's response. 589 o In a virtual interim where remote attendees all participate by 590 voice, someone can be heard typing / eating / talking loudly to 591 someone else. Carl and Chris try to get that person's attention 592 over the audio and Jabber, but to no avail. The tool being used 593 does not have the ability to mute individual participants, so the 594 meeting is disrupted until that person finally realizes that he or 595 she is not muted. 597 3.4. Remote Participation at IETF Interim WG Meetings 599 3.4.1. Face-to-Face Interim Meetings 601 Many interim meetings are held face-to-face in conference rooms 602 supplied by companies active in the IETF (and, much less often, in 603 commercial conference facilities such as hotels). Because these 604 facilities are not controlled by the IETF Secretariat, the ability to 605 include remote attendees varies widely. Some facilities can 606 distribute the in-room audio over the Internet just fine, while 607 others have no or limited abilities to do so. 609 For example, a recent face-to-face interim meeting was supposed to be 610 open to remote attendees through WebEx, but the sound coming from the 611 room was too soft to hear reliably. Even if a face-to-face interim 612 meeting has good facilities for audio and slide presenting, it will 613 probably have similar to regular IETF meetings. 615 3.4.2. Virtual Interim Meetings 617 Because few WGs have virtual interim meetings (those with no face-to- 618 face attendees), there is less experience with the tools that are 619 commonly used for them. The IETF has had free use of WebEx for a few 620 years, and some WGs have used different tools for audio 621 participation. For example, some virtual interims are held using 622 Skype, others with TeamSpeak, and so on. 624 So far, the experience with virtual interim meetings has been 625 reasonably good, and some people say that it is better than for 626 remote attendees at regular IETF meetings and face-to-face interims 627 because everyone has the same problems with getting the group's 628 attention. Also, there are no problems getting the in-room audio 629 into the RPS because all attendees are using their own computers for 630 speaking to the group. 632 One of the often-debated aspects of virtual interim meetings is what 633 time to have them in order to make them available to all 634 participants. Such scheduling of virtual interim meetings is out of 635 scope for this document. However, it is noted that because many 636 participants will be attending at different times of day and night, 637 no assumption can be made that participants will be at an "office". 638 This debate also affects face-to-face interim meetings because the 639 meeting hosts normally will schedule the meeting during business 640 hours at the host company, but that might be terribly inconvenient 641 for some WG members. 643 [[[ TODO: More discussion about experiences with virtual interims. 644 Focus on differences between the all-in-one systems like WebEx and 645 the cobble-together systems where there is an audio feed with no 646 floor control plus pre-distributed slideware. ]]] 648 4. Requirements for Supporting Remote Participation in Regular IETF 649 Meetings 651 This section covers the requirements and functional specification for 652 effective remote participation in meetings where some members are in 653 regular IETF face-to-face meetings. Some of the requirements in this 654 section overlap with those in Section 5, but many are unique to 655 meetings that have a large number of attendees physically present. 657 There is an assumption in this section that the meeting chairs will 658 continue to control the flow of the discussion. That is, if a 659 presenter is speaking and a remote attendee wants to ask a question, 660 the request to do so goes to the chair, not to the presenter. This 661 is covered in more detail in Section 4.2.2.1. 663 **Requirement 03-01**: The specifications SHOULD rely upon IETF and 664 other open standards for all communications and interactions wherever 665 possible. 667 **Requirement 03-02**: All tools in the RPS SHOULD be able to be run 668 on the widest possible array of computers. The tool may be a stand- 669 alone application, from any modern web browser, or from the command 670 line, but needs to be available on all of (at least) MacOS version 671 10.6 or later, Windows 7 or later, and any common Linux distribution 672 produced in 2010 or later. This also means that the tools MUST NOT 673 rely on Adobe Flash to work correctly. [[[ TODO: Do we need to 674 include IOS and Android platforms in that list? ]]] 675 **Requirement 03-03**: Audio, video, instant messaging, and slide 676 streams going to and from remote attendees SHOULD be delivered in as 677 close to real-time as is practically possible. A common complaint 678 with the current RPS is that the streaming audio can take more than 679 10 seconds (and sometimes as much as 30 seconds) to reach the remote 680 attendee. This causes many of the problems listed in Section 3.3.1. 682 [[[ TODO: Proposed replacement for this requirement is "Delays MUST 683 be less than X milliseconds greater than the network delay to the 684 remote attendee." Two values for X have been proposed: 200 and 500. 685 ]]] 687 [[[ TODO: A possibly different way to set the requirement is "The 688 audio MUST achieve a MOS (Mean Opinion Score) of 3.5 or better." And 689 there should probably be a discussion of a possible equivalent for 690 video. A proposal was "320x240 @ 15fps". ]]] 692 **Requirement 03-04**: The outgoing audio, video, and slide streams 693 MUST have the same delays so the remote participant does not get 694 confused during slide presentations. 696 **Requirement 03-05**: All streaming information from the RPS MUST be 697 usable over slow Internet connections. Many remote attendees will be 698 in places with limited bandwidth. [[[ TODO: We need to define "slow" 699 here, or drop the requirement.]]] 701 **Requirement 03-06**: All proposed tools MUST detail the bandwidth 702 required for each participant for various levels of participation 703 (audio-only, audio and video, and so on). 705 [[[ TODO: Is there a requirement for PSTN for audio-only? ]]] 707 **Requirement 03-07**: Audible echo in the audio stream MUST be 708 damped and/or eliminated by the tools. [[[ TOOD: Proposed 709 replacement: the RPS MUST recognize audible echo and automatically 710 take measures to reduce it to a level which won't distract listeners. 711 ]]] 713 **Requirement 03-08**: WG chairs MUST be able to test whether or not 714 the tools for their session are working at least 30 minutes before 715 the meeting begins (unless, of course, there is already another 716 meeting occurring in the room during that time). 718 **Requirement 03-09**: There MUST be written operational 719 documentation for each RPS tool that is accessible at all times. 720 This will help reduce problems where a WG chair is having problems 721 during a meeting that is affecting the meeting as a whole. 723 **Requirement 03-10**: There SHOULD be training materials for WG 724 chairs in how to use the RPS tools. 726 4.1. Registration for Remote Participation 728 There has been periodic discussion of whether or not remote attendees 729 are bound by the "Note Well" text that local attendees are bound to. 730 The core question is which local and remote attendees are 731 "contributors" based on the definitions in [BCP78]. By requiring 732 registration before participating, remote attendees can be better 733 alerted to, and thus hopefully bound to, the requirements of 734 contributors. 736 The cost for remote attendees to register, if any, is not covered in 737 this document but will instead be determined by the IETF at a later 738 time. There are many ideas on the subject (tiered costs for 739 different services, no cost at all for the first year, and others), 740 but the effects of different cost structures is beyond the scope of 741 this document. 743 **Requirement 03-11**: All remote attendees MUST register with the 744 IETF Secretariat before using any of the RPS tools described here. 745 Note that this would be a significant change to the current RPS tools 746 in that an unregistered person would not be able to use the IM 747 system. [[[ TODO: Should this be split into "unregistered people can 748 listen and read, but not contribute"? ]]] 750 **Functional spec 03-01**: The RPS MUST have a system where a remote 751 attendee can register their name and have that name be used in the 752 instant messaging and video systems. Registration must only need to 753 be done once for an entire regular IETF meeting. 755 **Requirement 03-12**: A remote attendee may register a nickname that 756 will be shown to other attendees during the meeting. A remote 757 attendee must register with a "verified" name with the IETF 758 Secretariat. The nickname will appear in video and instant 759 messaging. [[[TODO: Is this anonymity appropriate in light of the 760 "note well" and floor control requirements? ]]] 762 **Requirement 03-13**: The RPS tools (particularly the registration 763 tool) MUST gracefully handle multiple attendees who have the same 764 name. 766 **Functional spec 03-02**: To support the "blue sheet" functionality 767 for remote attendees, the registration tool SHOULD allow a registered 768 user to indicate which sessions he or she attended. This notations 769 SHOULD be allowed for all WG meetings throughout the meeting period. 770 The registration system SHOULD remind all registered remote attendees 771 at the end of the week to update their notations. 773 4.2. Audio 775 Audio from face-to-face meetings travels in two directions: from the 776 room to remote attendees, and from remote attendees to the room. 778 A few requirements come from the IETF's current use of audio in 779 meetings. Meeting rooms have many mics: one or two for the chairs, 780 one for the presenter, and at least one for other local attendees to 781 ask questions. Plenaries have many more mics, both at the front of 782 the room and in the audience. 784 **Requirement 03-14**: Remote attendees MUST be able to hear what is 785 said by local attendees and chairs at any mic in the meeting. 787 Comments on early drafts of this document indicated that the latter 788 may not really be a requirement for all participants if IM-to-mic is 789 made predictable. The two options are split below to make the 790 discussion clearer. Note that even if the consensus is towards IM- 791 to-mic, remote-to-room might still be required to enable remote 792 presenters; in this case, there would probably be little need for 793 floor control. The requirements for audio are expected to be 794 important discussion points in future versions of this document. 796 [[[ TODO: Should the ability to dial into a meeting stream via POTS 797 be a requirement? ]]] 799 4.2.1. IM-to-Mic Relay of Comments from Remote Participants 801 As described in Section 3.3.1, the current tools support an informal 802 method for remote attendees to speak at the mic: in the Jabber room, 803 they enter "mic:" before their comment and hope that the designated 804 scribe or someone else goes to the mic to relay the comment. This 805 method works, but has significant flaws described in that section. 807 **Requirement 03-15**: Relay of messages from IM to the mic MUST 808 happen as quickly as if the remote attendee was local. 810 **Requirement 03-16**: The person relaying from IM to the mic must be 811 available throughout the WG meeting. This could be facilitated by 812 hiring people to attend meetings for the specific purpose of being 813 IM-to-mic scribes. 815 **Requirement 03-17**: If multiple remote attendees want to comment 816 at the same time, the person relaying from IM to the mic MUST be able 817 to relay for all of them. 819 Note: during the development of this document, there have been many 820 suggestions for how WG chairs can better manage the IM-to-mic 821 relaying (for example, with planned pauses, better tracking of the IM 822 room, and so on). Some of those suggestions might turn into 823 requirements to be included in this document, but so far most of them 824 seem to be really about improving WG chairs, not the RPS tools. 826 4.2.2. Audio from Remote Participants to the Room 828 Note that the requirements here assume a very large change in the way 829 that remote participation will happen. Instead of a remote attendee 830 typing something into the Jabber room that someone will repeat at a 831 mic in the room, remote attendees will use their own mics to speak to 832 the meeting. 834 **Requirement 03-18**: Remote attendees MUST be able to speak 835 directly to a meeting without going through a local attendee, and 836 have their speaking be heard by local attendees. (Note that the 837 ability to speak is controlled by the chair; see Section 4.2.2.1.) 839 **Requirement 03-19**: Local attendees MUST be able to determine 840 which remote attendee is speaking. If the remote attendee is using a 841 nickname (see Requirement 03-12), that nickname can be used by the 842 remote speaker. 844 **Requirement 03-20**: The floor control portion of the RPS MUST give 845 a remote attendee who is allowed to speak a clear signal when they 846 should and should not speak. 848 **Requirement 03-21**: The audio system used by the RPS MUST be able 849 to integrate with systems commonly used in the venues used for IETF 850 meetings. IETF meetings happen in venues such as hotels and 851 conference centers, most of which have their own audio setups. The 852 IETF Secretariat contracts with those venues for the use of some or 853 all of their audio system. Without such integration, audio from 854 remote attendees might not be reliably heard by local participants. 856 **Requirement 03-22**: When a remote attendee connects to the audio 857 stream to the room, their mic SHOULD start off muted. This will 858 prevent problems such as those common with WebEx where a remote 859 attendee doesn't realize that they can be heard. 861 **Requirement 03-23**: Remote participants MUST be able to unmute 862 themselves; unmuting MUST NOT require interaction from the chair. 864 4.2.2.1. Floor Control for Chairs for Audio from Remote Attendees 866 Newcomers to regular IETF meetings often expect the floor control in 867 WG meetings to be fairly straight-forward. By Tuesday, they might be 868 shaking their heads, wondering why some people cut into the mic 869 lines, why some people get up to the mics after the chair has closed 870 the line, why some people ignore presenters' requests to hold 871 questions to the end, and so on. Mixing remote attendees into this 872 social structure will be a daunting task, but one that has been dealt 873 with in many remote participation systems. 875 It is not yet clear how the set of remote attendees would be treated 876 for queueing. Some tools have each remote attendee being considered 877 separately, while others pool all remote attendees into one group. 878 This affects the chair knowing and being able to act on the order 879 that remote attendees ask to speak. 881 Note that, if the remote video to room requirements from 882 Section 4.3.2 need to be met, it is very likely that a related 883 requirement to those below is that "the audio and video floor 884 controls must be in the same tool". 886 **Requirement 03-24**: Remote attendees MUST have an easy and 887 standardized way of requesting the attention of the chair when the 888 remote attendee wants to speak. The remote attendee MUST also be 889 able to easily cancel an attention request. (Note that Requirement 890 03-62 implies that someone is watching the request queue, something 891 that does not happen consistently with the current tools.) 893 **Functional spec 03-03**: The RPS MUST allow a remote attendee's 894 request for attention to include an optional short text string. A 895 remote attendee might want to indicate that they are asking a 896 question of the presenter, or answering a question that someone else 897 asked at the mic, or want to bring up a new topic. 899 **Functional spec 03-04**: Remote attendee's requests MUST be part of 900 the floor control tool, not in the instant messaging system. 902 **Requirement 03-25**: The chair MUST be able to see all requests 903 from remote attendees to speak at any time during the entire meeting 904 (not just during presentations) in the floor control system. 906 **Requirement 03-26**: The floor control system MUST allow a chair to 907 easily turn off and on an individual's ability to speak over the 908 audio at any time. 910 **Requirement 03-27**: The floor control system MUST allow a chair to 911 easily mute all remote attendees. 913 **Requirement 03-28**: The floor control system MUST allow a chair to 914 easily allow all remote attendees to speak without requesting 915 permission; that is, the chair MUST be able to easily turn on all 916 remote attendees mics at once. 918 **Requirement 03-29**: The floor control system for the chair MUST be 919 able to be run by at least two users at the same time. It is common 920 for a chair to leave the room, to have a side discussion with an AD, 921 or to become a presenter. They should be able to do so without 922 having to do a handoff of the floor control capability. 924 **Functional spec 03-05**: The RPS MUST authenticate users who can 925 use the floor control system in a particular meeting using simple 926 passwords. 928 **Requirement 03-30**: The IETF Secretariat MUST be able to easily 929 set up the individuals allowed to use the floor control system for a 930 particular meeting and to change the settings at any time, including 931 during the meeting. [[[ TODO: Should those who are given floor 932 control be allowed to augment that list to meet changing needs 933 without going back to the Secretariat? ]]] 935 [[[ TODO: Is it possible to tell if a remote attendee who is speaking 936 loses network connectivity? If so, maybe this can be shown to the 937 chair. ]]] 939 **Requirement 03-31**: The chair SHOULD be able to monitor the sound 940 levels of the audio being delivered to remote attendees to be sure 941 that they can hear what is going on in the room. 943 4.3. Video 945 The RFP that preceded the current document, [RPS-RFP], discusses 946 video as a requirement. The IETF has experimented with one-way and 947 two-way video at some meetings in the past few years. Remote 948 attendees have said that seeing people in the meetings gave them a 949 better understanding of the meeting; at a recent meeting, a remote 950 presenter was able to see the people in line at the mic and was 951 better able to interact with them. [[[ TODO: determine how much of 952 this is needed for effective participation. ]]] 954 4.3.1. Video from the Room to Remote Participants 956 **Requirement 03-32**: Remote attendees MUST be able to see the 957 presenter at a meeting. 959 **Requirement 03-33**: Remote attendees MUST be able to see local 960 attendees at any mic in the meeting. 962 [[[ TODO: Is there a requirement that IETF video integrate with the 963 venue video, if any? ]]] 965 4.3.2. Video from Remote Participants to the Room 967 Note that the requirements in this section probably only apply if 968 there is consensus that audio from remote participants to the room is 969 required. If so, there will probably also be requirements for video 970 floor control as well. 972 **Requirement 03-34**: The RPS MUST have the capability of showing 973 video of the remote attendee who is speaking over the audio to the 974 local attendees. 976 **Requirement 03-35**: A remote attendee who is speaking MUST be able 977 to choose what is shown to local attendees: video of them speaking, a 978 still picture of their face, or just their name. 980 **Requirement 03-36**: The RPS MUST give a remote attendee a clear 981 indication when their video image is being shown to the local 982 attendees. 984 [[[ TODO: The way to fulfill these might be that the IETF provide a 985 laptop for the chair that has the right tools on it, and that laptop 986 is the one connected to the projector. ]]] 988 4.4. Instant Messaging 990 Instant messaging (IM) is used both as a remote participation tool 991 and as a communication tool for local attendees at a regular meeting. 992 As noted earlier, while the current tool's Jabber room is a good way 993 to get questions to the mic, it also becomes a second communications 994 channel that only a few people in the room are participating in. 995 This document does not address how to prevent that problem (or 996 whether it really is much of a problem). The instant messaging 997 system is also useful for remote users to ask about the status of the 998 room ("is anyone there?"). 1000 **Requirement 03-37**: The IM system MUST allow anyone to see all 1001 messages in the WG's or BoF's room. 1003 **Requirement 03-38**: The IM system MUST allow any registered user 1004 (even those registered to use anonymous names) to post messages in 1005 the WG's or BoF's room. 1007 **Requirement 03-39**: The date and time that a message appears in an 1008 IM stream MUST be retained. IM clients MUST be able to show an 1009 indication of the date and time for all messages. Someone coming 1010 into a meeting late requires context for which messages in an instant 1011 messaging room are recent and which are old. 1013 [[[ TODO: Should there be multiple rooms for a meeting? There were 1014 many requests for a separate "speak into the mic" room, but that is 1015 not needed if the requirements in Section 4.2.2 are met. Is there a 1016 need for other rooms? ]]] 1018 [[[ TODO: Should non-registered people be allowed to read the IM 1019 traffic in real time, given that anyone can register anonymously? 1020 Should people registered anonymously be allowed to post in IM rooms? 1021 Should non-registered attendees be able to post to the IM rooms? ]]] 1023 4.5. Slide Presentations 1025 Slides are presented in regular IETF meetings with projectors on a 1026 screen at the front of the room from the video output of one or more 1027 local attendees' computers. If slides are to be presented to remote 1028 attendees, the slides being projecte need to also be sent as a stream 1029 to the remote attendees. 1031 In many current remote participation systems, slide presentations and 1032 the video coming from in-meeting cameras are sent as two separate 1033 streams (called the "slide stream" and the "camera stream"). The 1034 slide stream is usually much lower bandwidth than the camera stream, 1035 so remote attendees with limited bandwidth can choose to watch just 1036 the slides but not the local attendees. Further, separating the 1037 streams allows remote attendees to see the slide stream and the 1038 camera streams in separate windows that can be independently sized. 1040 **Functional spec 03-06**: The RPS MUST transmit the slide stream 1041 separately from the camera stream. 1043 **Requirement 03-40**: The slide stream MUST represent the slides as 1044 they are projected in the room, allowing the presenter to go back and 1045 forth, as well as to edit slides in real time. 1047 **Requirement 03-41**: It MUST be made clear to the remote attendees 1048 which set of slides, and which slide number, is being currently 1049 shown. 1051 [[[ TODO: If the slides will be visible to remote attendees as they 1052 are presented, is there a requirement that presenters be able to use 1053 the equivalent of a laser pointer? ]]] 1055 4.6. Slide Distribution 1057 Slides are available to local and remote attendees on the IETF 1058 servers before and during regular IETF meetings. This service is 1059 useful to all attendees who want to be prepared for WG meetings. The 1060 slides are not only used by remote attendees listening to the WG 1061 meeting; it is common for local attendees to download the slides and 1062 view them on their laptops during meetings instead of having to read 1063 them at the front of the room. 1065 **Functional spec 03-07**: The RPS MUST be able to handle both PDF 1066 and PowerPoint formats (".ppt" and ".pptx") for distributed slides. 1067 [[[ TODO: Is there a requirement to support other formats? ]]] [[[ 1068 TODO: For the distributed slides, is there a requirement that 1069 animation in PowerPoint be supported, or just static slides? ]]] 1071 **Functional spec 03-08**: The RPS MUST automatically convert 1072 PowerPoint presentations to PDF and make both available for 1073 distribution at the same time. 1075 **Requirement 03-42**: Presenters MUST be able to update their slides 1076 on the IETF site up to just before their presentation, if such update 1077 is allowed by the chairs. 1079 **Requirement 03-43**: Chairs MUST be able to approve or disapprove 1080 of any slide submission or updates, with the default being that all 1081 submissions are allowed. 1083 4.7. Shared Document Editing 1085 In some WG meetings, there is an attempt to edit a document with 1086 input from the local attendees. This is typically done for proposed 1087 charter changes, but sometimes happens on a WG document or the 1088 meeting's agenda. This is usually unsuccessful, given the amount of 1089 text and the size of what can be displayed on the screen. In recent 1090 meetings, shared document editing has been used for editing charters 1091 and for taking minutes of meetings. 1093 An RPS tool for shared document editing would be equally useful for 1094 local and remote attendees watching the edits happen in real-time. 1095 There is a good chance that this tool would be watched by local 1096 attendees on their laptops instead of being projected on the screen 1097 because of the small size of the the text. This, in turn, means that 1098 local attendees who aren't using their laptops at the moment would 1099 not be able to participate by watching. 1101 **Requirement 03-44**: It MUST be easy to start a new shared document 1102 and to import existing text into a shared document. 1104 **Requirement 03-45**: Shared real-time editing of text-only 1105 documents MUST be supported. This system must allow at least three 1106 people to have write access and hundreds of people to have read 1107 access to any particular document. 1109 **Requirement 03-46**: Remote attendees MUST be able to be either the 1110 writers or the readers of shared documents. 1112 **Requirement 03-47**: Those with read access MUST be able to see the 1113 edits made by those with write access within less that five seconds 1114 after each edit. 1116 **Requirement 03-48**: It MUST be easy to change the permissions for 1117 who gets write access to a document during an editing session. 1119 [[[ TODO: Is this also needed for non-text documents? If so, in what 1120 formats? For example, is drawing on a whiteboard needed? ]]] 1122 4.8. Archiving 1124 Archived recordings of the events of the meetings are valuable for 1125 remote attendees who are not able to hear everything in real time. 1127 **Requirement 03-49**: The RPS MUST support storage and distribution 1128 of recordings of the audio, video, and slide presentations for all WG 1129 meetings. 1131 **Requirement 03-50**: Transcripts of the instant messaging for all 1132 meetings MUST be kept for distribution after IETF meetings. 1134 **Requirement 03-51**: The recordings and transcripts SHOULD be made 1135 available during the meetings, within a day of them being made. 1137 **Requirement 03-52**: Users MUST be able to easily find the archives 1138 of the recordings and instant messaging transcripts of a particular 1139 WG or BoF session at a particular meeting. 1141 **Requirement 03-53**: The RPS SHOULD support indexing of archived 1142 audio and video for particular events in meetings such as when 1143 speakers change. 1145 **Requirement 03-54**: The RPS MUST support recording and storage of 1146 recordings of the audio, video, and slide presentations of interim 1147 meetings as well as regular IETF meetings. 1149 **Requirement 03-55**: Given that interim meetings are run without 1150 the help of the IETF Secretariat, making these recordings MUST be 1151 easy for WG chairs. 1153 4.9. Transcription 1155 **Requirement 03-56**: Transmitting real-time transcription to remote 1156 attendees MUST be supported. The lag in transmission MUST be less 1157 than five seconds. 1159 4.10. Polling 1161 The common IETF method of assessing support is a straw poll, 1162 sometimes managed by audible humming, sometimes by raising hands. 1164 **Requirement 03-57**: A system for polling meeting participants, 1165 including remote attendees at the same time, MUST be provided. It 1166 MUST be easy to set up a simple poll, and it must be easy for all 1167 participants to find the poll and participate. Note that this would 1168 add a requirement that everyone in a meeting be using their computer 1169 to participate in the poll. [[[ TODO: Should the RPS also provide a 1170 tool that allows yes / no / abstain indications, which comes a lot 1171 closer to "voting" than currently is common? ]]] 1173 4.11. Plenaries 1175 At recent IETF meetings, there has been very little input from remote 1176 attendees even when there is a lot in the room, but that may be due 1177 to the current setup, not lack of interest. 1179 **Requirement 03-58**: Remote attendees SHOULD be able to make 1180 comments at the mic approximately as well as if they were local 1181 attendees. This means that either remote audio to the plenary room 1182 speakers be available, or that IM-to-room relay be available. 1184 [[[ TODO: Are there other requirements that are special to plenaries 1185 that are not covered above? Are there requirements not listed above 1186 that mostly come from plenaries that would also apply to very large 1187 WGs? ]]] 1189 4.12. Use by IETF Leadership 1191 The requirements for bodies like the IESG and IAB to use the RPS 1192 during regular IETF meetings are similar to those of most WGs. The 1193 main difference is that they need a way to limit who can participate 1194 remotely. 1196 **Requirement 03-59**: The IETF Secretariat MUST be able to easily 1197 limit remote access to meetings on a room-by-room basis. 1199 **Requirement 03-60**: The IETF Secretariat must be able to limit 1200 participants in restricted meetings using a simple authentication 1201 mechanism. 1203 Note that the IETF leadership will also heavily use the remote 1204 participation tools between IETF meetings in a manner that is very 1205 similar to virtual interim meetings. 1207 4.13. Additional Requirements for Remote Participation 1209 **Requirement 03-61**: Remote attendees MUST be able to easily find 1210 all the material they need to effectively participate, including 1211 links to audio, video, instant messaging, slides, and so on. This 1212 material MUST be available well before the time of the meeting. The 1213 page with the meeting material SHOULD allow the remote attendee to 1214 easily perform a time conversion to and from the local time at the 1215 IETF meeting. 1217 **Requirement 03-62**: A remote attendee who comes to a meeting late 1218 MUST be able to tell what is happening in the meeting. In specific, 1219 there MUST be an indication if the meeting has not started, if the 1220 meeting is happening (even if there is silence on the mics), and if 1221 the meeting is over. 1223 **Requirement 03-63**: There MUST be a constantly-running testing 1224 service that covers all interactive tools (audio, video, slide 1225 display, and so on) for at least a week before the meeting begins. 1226 Remote attendees need to be able to test the remote participation 1227 setup before a regular meeting, and even during the meeting. 1229 **Requirement 03-64**: The testing service MUST run throughout the 1230 meeting so that last-minute joiners can test their systems. 1232 **Requirement 03-65**: The testing service SHOULD allow remote 1233 attendees to also test whether their outgoing audio, video, and slide 1234 control works. 1236 **Requirement 03-66**: Remote attendees SHOULD be able to easily 1237 contact the IETF Secretariat if they find problems with any of the 1238 RPS tools, and to get fairly rapid response. 1240 **Requirement 03-67**: Similarly, local attendees SHOULD be able to 1241 easily contact the IETF Secretariat if there are RPS problems in the 1242 meeting rooms. 1244 **Requirement 03-68**: The RPS tools MUST be available for AD- 1245 sponsored lunch meetings scheduled by the IETF Secretariat. Regular 1246 IETF meetings are more than just a group of WG meetings. Remote 1247 attendees may want to participate in the other parts of a regular 1248 meeting as well. 1250 **Requirement 03-69**: Any tools that are used by remote attendees 1251 MUST also be available to local attendees as well. At many IETF 1252 meetings, some local attendees act as remote attendees in WG meetings 1253 that they are not sitting in, so they can attend two WGs at once. 1255 5. Requirements for Supporting Remote Participation in Interim Meetings 1257 One of the goals of this document is to increase the effectiveness of 1258 interim meetings. Interim meetings are now uncommon, but might 1259 become more common (and more effective) if the remote participation 1260 becomes more useful. 1262 **Functional spec 03-09**: The RPS SHOULD have a central location 1263 where the specifics about how remote participation is supported for 1264 every WG interim meeting. This will reduce the problems often seen 1265 where messages about how to participate in an interim meeting get 1266 buried in the WG mailing list. 1268 **Requirement 03-70**: There SHOULD be documentation and training for 1269 the RPS tools specifically targeted at WG chairs who will lead 1270 interim meetings. 1272 [[[ TODO: Determine how much or how little the IETF Secretariat 1273 should participate in setting up the RPS for interim meetings. The 1274 IETF Secretariat currently offers some help to some WGs, but this 1275 might become more formalized in the future. ]]] 1277 5.1. Requirements for Supporting Remote Participation in Face-to-Face 1278 Interim Meetings 1280 Face-to-face interim meetings have many things in common with regular 1281 IETF meetings, but there are also many significant differences. For 1282 most WGs, fewer people attend interim meetings than IETF meetings, 1283 although those who travel to a face-to-face interim meeting are often 1284 the more active WG participants. There may be a larger demand for 1285 remote participation because people have a harder time justifying 1286 travel for a single WG meeting than for an IETF meeting, but there 1287 may also be less demand because people tend to think of interim WG 1288 meetings as less important than regular IETF meetings.. 1290 Typically, the IETF Secretariat does not control the rooms in which 1291 face-to-face interims are held, so they have no control over whether 1292 outgoing audio will be supported, or supported well enough to 1293 guarantee that remote attendees can hear. [[[ TODO: Should the IETF 1294 Secretariat be tasked with helping set up face-to-face interims? ]]] 1296 **Requirement 03-71**: The RPS tools MUST be at least partially 1297 usable at face-to-face meetings other than regular IETF meetings. 1298 The number of the tools that might be available will be different for 1299 different venues for the virtual interims, but at a minimum, the 1300 following MUST be supported for remote attendees: 1302 o Room audio 1304 o Instant messaging 1306 o Slide distribution 1308 o Slide presentation 1310 o Shared document editing 1312 [[[ TODO: What are the requirements for registering? Interim 1313 meetings are generally considered to have a very different feeling 1314 than regular IETF meetings; does this affect the idea of 1315 registration? What if registration is cheap but not free? ]]] 1317 5.2. Requirements for Supporting All-Remote Interim Meetings 1319 The requirements for meetings that are all remote (that is, with no 1320 local attendees) are mostly a subset of the requirements for remote 1321 participation in a regular IETF meetings and face-to-face interim 1322 meeting. This section highlights the differences from Section 4 and 1323 Section 5.1. 1325 Video for all-remote meetings may be more important than for face-to- 1326 face meetings in order to help the chair with floor control. [[[ 1327 TODO: Determine if this is true and, if so, the additional 1328 requirements for all the remote attendees. ]]] 1330 Attendance at virtual interim meetings is supposed to be taken, but 1331 this is sometimes ignored. A system that is probably at least 1332 somewhat different than that in Section 4.13 may be needed for 1333 collecting attendance at virtual interim meetings. [[[ TODO: What are 1334 the requirements for registering? Virtual interim meetings are 1335 generally considered to have a very different feeling than regular 1336 IETF meetings; does this affect the idea of registration? ]]] 1338 [[[ TODO: Are there different floor control issues for all-remote 1339 meetings? ]]] 1341 6. IANA Considerations 1343 None. [[ ...and thus this section can be removed before publication 1344 as an RFC... ]] 1346 7. Security Considerations 1348 People who participate remotely in face-to-face IETF meetings might 1349 expect the same level of privacy as they have when they participate 1350 directly in those meetings. Some of the proposed tools might cause 1351 it to be easier to know which WGs a remote attendee was following. 1352 When RPS tools are deployed, the IETF should describe the privacy 1353 implications of using such a tool to the users so they can decide 1354 whether or not to use the tools. 1356 The eventual RPS tools will have some user authentication that will 1357 associate people with actions. For example, a remote user might need 1358 to authenticate to the system in order to give a presentation or 1359 speak during a session. The credentials needed for this 1360 authentication will need to be managed in a secure fashion, both by 1361 the system and by the people who are being identified. 1363 8. Acknowledgements 1365 Many of the ideas in this document were contributed by members of the 1366 IETF community based on their experiences during recent IETF 1367 meetings. There are also many contributions from people on the 1368 vmeet@ietf.org mailing list as well as WG chairs. 1370 Some of the text in this document originated in the request for 1371 proposals that was issued by the IAOC that led to this document. 1373 9. Informative References 1375 [BCP78] Bradner, S. and J. Contreras, "Rights Contributors Provide 1376 to the IETF Trust", BCP 78, RFC 5378, November 2008. 1378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1379 Requirement Levels", BCP 14, RFC 2119, March 1997. 1381 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 1382 Procedures", BCP 25, RFC 2418, September 1998. 1384 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1385 Protocol (XMPP): Core", RFC 6120, March 2011. 1387 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1388 Protocol (XMPP): Instant Messaging and Presence", 1389 RFC 6121, March 2011. 1391 [RPS-RFP] IAOC, "Request for Proposals for Requirements Development 1392 for Remote Participation Services", 2011, . 1396 Author's Address 1398 Paul Hoffman 1399 VPN Consortium 1401 Email: paul.hoffman@vpnc.org