idnits 2.17.1 draft-saintandre-chatroom-relay-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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. Saint-Andre 3 Internet-Draft &yet 4 Intended status: Informational D. York 5 Expires: April 30, 2015 Internet Society 6 October 27, 2014 8 The Chatroom Relay Role at IETF Meetings 9 draft-saintandre-chatroom-relay-02 11 Abstract 13 During IETF meetings, individual volunteers often help sessions run 14 more smoothly by relaying information back and forth between the 15 physical meeting room and an associated textual chatroom (where 16 remote participants can send questions or feedback to the physical 17 room). 19 This document provides suggestions for fulfilling the role of a 20 chatroom relay. 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 April 30, 2015. 39 Copyright Notice 41 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Know Your Users . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Primary Tasks . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Additional Tasks . . . . . . . . . . . . . . . . . . . . . . 4 61 6. Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 During IETF meetings, individual volunteers often help sessions run 71 more smoothly by relaying information back and forth between the 72 physical meeting room and an associated textual chatroom. This role 73 is critical as it is currently the only "real-time" way for a remote 74 attendee to provide feedback or comments back into most IETF meeting 75 sessions (whether for an IETF working group, IRTF research group, or 76 IETF "birds of a feather" or "BoF" session). Although there are 77 multiple ways that a remote attendee can listen and follow along, the 78 chatroom provides a method of returning feedback to the physical 79 meeting. 81 This document provides suggestions for fulfilling the role of a 82 chatroom relay. 84 2. Terminology 86 A chatroom relay is often referred to as a "Jabber scribe". This 87 term is misleading because nothing prevents the IETF from using a 88 technology other than Jabber/XMPP [RFC6120] [XEP-0045] for chatrooms 89 (say, IRC or an integrated collaboration environment), and more 90 importantly because volunteers are not expected to scribe the 91 complete contents of the meeting into the chatroom (which would be a 92 much more onerous task than relaying selected information back and 93 forth between the physical room and the chatroom). Use of the term 94 "scribe" might discourage people from volunteering to serve in the 95 role. 97 3. Know Your Users 99 The participants in a chatroom typically fall into three categories: 101 o Remote attendees who are listening to the audio stream or in some 102 cases following the proceedings using a real-collaboration system 103 (currently exemplified by the MeetEcho service). These 104 participants might wish to send questions or feedback to the 105 physical room. 107 o IETF meeting attendees who are in another simultaneous session in 108 a different physical room. These participants are often 109 monitoring the chatroom session to find out when a particular 110 topic is being discussed or to observe what is being discussed in 111 the chatroom. Typically they are not able to listen to the audio 112 stream and sometimes they ask for a higher level of commentary so 113 that they can know when they might need to change locations to 114 participate in the session's physical room. 116 o IETF meeting attendees who are in the same session. These 117 participants like to follow the discussions in the physical room 118 and the chatroom at the same time. They can also provide some 119 assistance to chatroom relays. 121 Because all chatroom sessions are logged during IETF meetings and the 122 logs are publicly available, the logs can be a very useful history of 123 what occurs during a meeting. For that reason any additional 124 information that can be supplied to remote participants can be very 125 helpful. 127 4. Primary Tasks 129 Individuals who volunteer for the role of chatroom relay usually 130 complete the following tasks: 132 o Relay questions and comments from the chatroom to the physical 133 room. This typically involves going to the microphone to relay 134 the comment from the remote participant. 136 o Count the number of chatroom participants who virtually "hum", 137 raise their hands, volunteer to provide feedback on documents, 138 etc., and feed that information back to the physical room. 140 o Relay information about hums and similar interactions from the 141 physical room to the chatroom (preferably after receiving a 142 "reading" from the session chairs). 144 It is the convention in most sessions that the chatroom relay has the 145 privilege to go to the front of the microphone line to relay the 146 question(s) from remote participants. Some chatroom relays choose to 147 exercise that privilege while others choose to wait in line along 148 with the participants in the physical meeting rooom. 150 5. Additional Tasks 152 Additionally some chatroom relays often complete the following tasks: 154 o Relay the names of people speaking in the physical room to the 155 chatroom. 157 o Relay the slide numbers or slide names to help chatroom 158 participants follow along. 160 o Query remote participants about audio streaming quality, and relay 161 such information to the session chairs. 163 o Relay to the chatroom participants any logistical or procedural 164 issues related to the meeting (for instance, known technical 165 glitches at the physical meeting or delays in starting the 166 session). 168 o Provide links to the current set of slides and the document being 169 discussed so that chatroom participants can easily follow along. 171 Although chatroom relays are not generally expected to scribe the 172 complete contents of conversations that happen the physical room to 173 the chatroom, they sometimes relay the gist of such conversations, 174 especially during ad-hoc discussions for which slides are not 175 available. (By prior arrangement between the session chairs and the 176 chatroom relay, more detailed scribing might be expected for 177 particular sessions.) 179 6. Suggestions 181 Experience has shown that the following behaviors make it easier to 182 act as a chatroom relay. 184 If you have volunteered before the session: 186 o Coordinate with the chairs to ensure that remote participants have 187 received information about where to find the meeting materials, 188 agenda, audio stream, etc. (e.g., this information can be sent to 189 a working group discussion list so that remote participants do not 190 need to ask about it on entering the chatroom). 192 o Coordinate with the chairs to see if they have any special 193 expectations for the chatroom relay (e.g., some chairs might want 194 you to actually "scribe" more detailed information about the 195 session proceedings into the chatroom). 197 o Ask the session chairs whether it is acceptable for you to advance 198 to the front of the mic line with time-sensitive comments from 199 remote participants. 201 As you are getting settled and ready for the meeting to start: 203 o Seat yourself near the microphone most likely to be used for 204 discussions in the physical room, so that you can more easily 205 capture the names of people who come to the mic. Typically this 206 will be a seat near the end of a row or in some location where you 207 can easily get up out of your seat to go to the microphone. 209 o It can be helpful to open several browser windows or tabs for: 211 * the agenda page for the session 213 * the materials page so that you can relay links to slides if 214 necessary 216 * the documents page for the working group or research group (or 217 BoF wiki page) in case you want easy access to documents 218 mentioned but not in the agenda page 220 * the meeting registration system page (see below) 222 o Determine if the session will be streamed via a real-collaboration 223 system such as MeetEcho. If so, that system might automatically 224 post the slide names into the chatroom and this is one less task 225 you need to be concerned about. 227 o If the session is large or is expected to be especially active 228 (e.g., a controversial BoF), find an assistant who can help you by 229 sitting at another mic, taking turns relaying information, etc. 231 Identifying one or more assistants is very useful particularly if you 232 want to go up to the microphone to speak as an individual or if you 233 need to take a break or step out of the physical room at some point. 235 During the session: 237 o Identify yourself in both the physical room and the chatroom so 238 that participants in both venues know that you are a relay. 240 o Ask chatroom participants what level of information they need 241 relayed into the chatroom. For example if all chatroom 242 participants are listening via audio or a system like MeetEcho 243 they might need very little information relayed from the room. 245 o Ask chatroom participants to prepend statements they would like 246 you to relay with "RELAY" or "MIC" (the former term is less 247 ambiguous). 249 o When relaying a question or comment from the chatroom to the 250 physical room, say "this is X relaying for Y from the chatroom" so 251 that people know you are not speaking for yourself. 253 o It's not expected that you will know the names of everyone who 254 comes to the mic. If you don't know the name of a person at the 255 microphone, you have several options: 257 * look at their name badge if you are seated nearby 259 * query them directly (calling out "state your name, please" is 260 acceptable) 262 * ask in the chatroom or type something like "?? at the mic", 263 since it is likely that someone who is present in both the 264 physical room and the chatroom will be able to identify the 265 person for you 267 * look up the name of the attendee in the meeting registration 268 system (this is typically found at a URL of the form "https:// 269 www.ietf.org/registration//attendance.py", such as 270 "https://www.ietf.org/registration/ietf90/attendance.py"); you 271 can quickly look up a name using this system if you are in 272 doubt. 274 o Be aware that lag happens between the time when something is said 275 in the physical room and the time when someone provides a response 276 in the chatroom, and take this into account when the interaction 277 is time-sensitive (e.g., during a hum or a show of hands). 279 7. IANA Considerations 281 This document requests no actions from the IANA. 283 8. Security Considerations 285 Although XMPP multi-user chat rooms [XEP-0045] can be configured to 286 lock down nicknames and require registration with the chatroom in 287 order to join, at the time of this writing IETF chatrooms are not so 288 configured. This introduces the possibility of social engineering 289 attacks on discussions held in IETF chatrooms. It can be helpful for 290 chatroom relays to be aware of this possibility. 292 Denial of service (DoS) attacks of various kinds are possible, e.g., 293 flooding a chatroom with unwanted or automated traffic. 295 9. References 297 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 298 Protocol (XMPP): Core", RFC 6120, March 2011. 300 [XEP-0045] 301 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 302 2012. 304 Appendix A. Acknowledgements 306 Thanks to Dan Burnett, Jelte Jansen, Warren Kumari, Hugo Salgado, 307 Yaakov Stein, and Greg Wood for their input. Thoughts and ideas sent 308 by Wes George and Janet Gunn to an IETF 87 mailing list were 309 incorporated into this document. 311 Authors' Addresses 313 Peter Saint-Andre 314 &yet 316 Email: peter@andyet.com 317 URI: https://andyet.com/ 319 Dan York 320 Internet Society 322 Email: york@isoc.org 323 URI: https://www.internetsociety.org/