idnits 2.17.1 draft-duke-shmoo-virtual-hum-00.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 (8 July 2020) is 1388 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 SHMOO M. Duke 3 Internet-Draft F5 Networks, Inc 4 Intended status: Informational 8 July 2020 5 Expires: 9 January 2021 7 Specification for a virtual humming tool 8 draft-duke-shmoo-virtual-hum-00 10 Abstract 12 This is the specification for a virtual humming tool to emulate as 13 closely as possible the audible hums used in-person meetings to help 14 judge consensus. This specification is based on feedback provided in 15 the survey about virtual humming as well as lived experience with in- 16 person hums. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 9 January 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Key attributes of in-person humming . . . . . . . . . . . . . 2 53 3. Tool specification . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Opening and closing hums . . . . . . . . . . . . . . . . 3 56 3.3. Taking part in a hum . . . . . . . . . . . . . . . . . . 3 57 3.4. After the hum . . . . . . . . . . . . . . . . . . . . . . 4 58 3.5. Explanatory notes . . . . . . . . . . . . . . . . . . . . 4 59 3.6. Implementation notes . . . . . . . . . . . . . . . . . . 5 60 4. Alternative approaches . . . . . . . . . . . . . . . . . . . 5 61 4.1. Single level of hum . . . . . . . . . . . . . . . . . . . 5 62 4.2. More levels of hum . . . . . . . . . . . . . . . . . . . 5 63 4.3. No hum indicator . . . . . . . . . . . . . . . . . . . . 5 64 4.4. Simple result calculation . . . . . . . . . . . . . . . . 6 65 4.5. Bucket size closer to the formulae . . . . . . . . . . . 6 66 4.6. Grayscale . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 7. Informative References . . . . . . . . . . . . . . . . . . . 6 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 This is the specification for a virtual humming tool to emulate as 76 closely as possible the audible hums used in-person meetings to help 77 judge consensus. This specification is based on feedback provided in 78 the survey [SURVEY] about virtual humming, as well as lived 79 experience with in-person hums. This note does not consider whether 80 a better mechanism can be developed for judging consensus in online 81 meetings rather than replicating an in-person hum. 83 2. Key attributes of in-person humming 85 This specification aims to preserve the following attributes of in- 86 person humming: 88 1. Participants can hum at different intensities. 90 2. A hum is only ever about one view, such as "agree" or "disagree", 91 not both. There is no way of differentiating between people 92 humming at the same time for different things. 94 3. Hums often come in sets of two, but not always. 96 4. Participants can hear the overall hum, but the identification of 97 the hum of any individual is unintentional and not to be 98 encouraged. 100 5. The chair will generally assess the overall hum relative to the 101 number of people in the room. 103 6. While the intensity of the overall hum is theoretically on a 104 continuous scale, in practice Chairs only recognise a limited 105 number of intensities of overall hum. 107 7. The overall loudness of a hum is governed by the physics of 108 sound, most closely mapped to that of simple musical instruments 109 [VIOLINS]. 111 8. It gets increasingly difficult to differentiate between hums as 112 the number of people humming increases, with a practical limit 113 reached at some point. 115 9. The larger the number of participants in a session, the more 116 likely it is that there will be some who do not understand the 117 subject matter well enough to participate in a hum. 119 3. Tool specification 121 This specification is intended to be feature complete, which means 122 that what should be implemented is only what is explicitly stated 123 here and nothing else. 125 3.1. General 127 * There is only one type of hum 129 * Only one hum can be open at any one time in a session. 131 3.2. Opening and closing hums 133 * A session chair can open a hum. 135 * A session chair can open a hum at any time during a session, 136 except when a hum is already open. 138 * A session chair can open multiple hums per session. 140 * A hum is automatically closed 20 seconds after it is open. 142 3.3. Taking part in a hum 143 * When a hum is open, each participant in the session, except the 144 chairs, may take part in the hum through the following mechanism: 145 1. Each session participant is presented with the following 146 options from which they can select. No option is selected as a 147 default. 1. "Soft (single)" 2. "Loud (double)" 2. Selection of 148 an option requires a confirmation action and only takes effect 149 when confirmed. 3. Once an option has been chosen and confirmed 150 then it cannot be changed. 152 * When a participant selects and confirms any option, they are 153 considered to have hummed. 155 * If a participant joins the session during the hum then they can 156 take part. 158 * If a participant leaves the session during the hum, they are 159 considered to have hummed and their hum is still used for data 160 calculation. 162 * A timer is shown during the hum to all participants and chairs. 164 3.4. After the hum 166 * When a hum is closed a score **_s_ calculated as the sum of: 1. 1 167 for each Soft hum 2. 2 for each Loud hum 169 * A hum indicator is then displayed as follows depending on the 170 value of **_s_ and the following buckets: 172 1. **_s_ <= 2: niente 174 2. **_s_ > 2 and **_s_ <= 10: pianissimo 176 3. **_s_ > 10 and **_s_ <= 26: piano 178 4. **_s_ > 26 and **_s_ <= 58: forte 180 5. **_s_ > 58: fortissimo 182 * The hum indicator is displayed to all MeetEcho participants, not 183 just the chairs. 185 * When a new hum is opened the indicator from the previous hum is 186 blanked out, ready to be replaced with a new indicator when the 187 hum closes. 189 3.5. Explanatory notes 190 * The choice of buckets for **_s_ uses a simple formula where the 191 size of the bucket doubles each time, which equates to exponential 192 growth in the bucket size. This is roughly equivalent to the 193 logarithmic formulae in [VIOLINS] used to calculate the increase 194 in loudness from one violin to two violins playing the same note. 196 * The names of the hum indicators are taken from loudness marks used 197 in musical notation. 199 3.6. Implementation notes 201 * Some participants will not be allowed to hum contractually, but 202 this will not need to be enforced by the system. 204 * The way in which the options are presented and selected and the 205 way in which the hum indicator is selected is left to the 206 implementer. However, the text for each option should appear as 207 above. 209 * The results display needs to show all the possible results 210 (niente, pianissimo, piano, forte, fortissimo) in some form of 211 ordered view with an indicator as to which end is the quietest and 212 which the loudest, with the appropriate result highlighted. 214 4. Alternative approaches 216 A number of alternative approaches were considered and rejected as 217 set out below. 219 4.1. Single level of hum 221 A single-level of hum was considered but rejected on the basis that 222 it took the specification too close to voting and was not a match to 223 an in-person hum. 225 4.2. More levels of hum 227 More levels of hum were considered but rejected as it was felt that 228 two levels was the best overall match to an in-person hum. 230 4.3. No hum indicator 232 Consideration was given to separating the idea of choosing not to hum 233 and not being informed enough to participate. When we ceased 234 normalizing the result for the number of attendees, this became 235 irrelevant. 237 4.4. Simple result calculation 239 Consideration was given to using a simple formula to calculate the 240 result, such as using the score not the result, and rejected as it 241 was felt that a logarithmic formula was a closer match to an in- 242 person hum. 244 4.5. Bucket size closer to the formulae 246 Consideration was given to directly using the logarithmic formulae in 247 [VIOLINS] used to calculate the increase in loudness from one violin 248 to two violins playing the same note, which would have calculated an 249 approximate decibel level for each hum. Each hum indicator would 250 then represent the same number of decibels, and so produce a similar 251 effect to the chosen specification. This was rejected because it 252 would either produce buckets that were too small and so the top 253 bucket would be reached too quickly, or buckets that were too large 254 giving the inverse problem. 256 4.6. Grayscale 258 An essentially continuous color-based indicator used in place of 259 buckets, would better match the continuous nature of sound and 260 further divorce the output from the absolute numbers of people 261 humming. However, this would produce higher-precision results than 262 are possible with human ears in a room. 264 5. Security Considerations 266 Meetecho participation is restricted to people who have datatracker 267 accounts, providing some assurance of identity. Potential attacks 268 against this tool will either subvert Meetecho admission control, or 269 involve multiple datatracker registrations (and Meetecho logins) to 270 amplify the voice of a single individual. 272 The integrity of this tool is dependent on the integrity of the 273 registration and fee waiver processes. In particular, they must weed 274 out duplicate registrations, bots, and so on. 276 6. IANA Considerations 278 This document has no IANA actions. 280 7. Informative References 282 [SURVEY] "IETF 107 Survey", 2020, 283 . 286 [VIOLINS] "Acoustics FAQ", 2015, . 289 Appendix A. Acknowledgements 291 Alissa Cooper, Jay Daley, Roman Danyliw, Colin Perkins, Alvaro 292 Retana, and Robert Wilton made significant contributions to this 293 document. Benjamin Kaduk, Erik Kline, Warren Kumari, and Barry Leiba 294 also provided helpful feedback. 296 Author's Address 298 Martin Duke 299 F5 Networks, Inc 301 Email: martin.h.duke@gmail.com