Internet DRAFT - draft-duke-shmoo-virtual-hum
draft-duke-shmoo-virtual-hum
SHMOO M. Duke
Internet-Draft F5 Networks, Inc
Intended status: Informational 8 July 2020
Expires: 9 January 2021
Specification for a virtual humming tool
draft-duke-shmoo-virtual-hum-00
Abstract
This is the specification for a virtual humming tool to emulate as
closely as possible the audible hums used in-person meetings to help
judge consensus. This specification is based on feedback provided in
the survey about virtual humming as well as lived experience with in-
person hums.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 January 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Duke Expires 9 January 2021 [Page 1]
Internet-Draft VirtualHum July 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key attributes of in-person humming . . . . . . . . . . . . . 2
3. Tool specification . . . . . . . . . . . . . . . . . . . . . 3
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Opening and closing hums . . . . . . . . . . . . . . . . 3
3.3. Taking part in a hum . . . . . . . . . . . . . . . . . . 3
3.4. After the hum . . . . . . . . . . . . . . . . . . . . . . 4
3.5. Explanatory notes . . . . . . . . . . . . . . . . . . . . 4
3.6. Implementation notes . . . . . . . . . . . . . . . . . . 5
4. Alternative approaches . . . . . . . . . . . . . . . . . . . 5
4.1. Single level of hum . . . . . . . . . . . . . . . . . . . 5
4.2. More levels of hum . . . . . . . . . . . . . . . . . . . 5
4.3. No hum indicator . . . . . . . . . . . . . . . . . . . . 5
4.4. Simple result calculation . . . . . . . . . . . . . . . . 6
4.5. Bucket size closer to the formulae . . . . . . . . . . . 6
4.6. Grayscale . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Informative References . . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This is the specification for a virtual humming tool to emulate as
closely as possible the audible hums used in-person meetings to help
judge consensus. This specification is based on feedback provided in
the survey [SURVEY] about virtual humming, as well as lived
experience with in-person hums. This note does not consider whether
a better mechanism can be developed for judging consensus in online
meetings rather than replicating an in-person hum.
2. Key attributes of in-person humming
This specification aims to preserve the following attributes of in-
person humming:
1. Participants can hum at different intensities.
2. A hum is only ever about one view, such as "agree" or "disagree",
not both. There is no way of differentiating between people
humming at the same time for different things.
3. Hums often come in sets of two, but not always.
Duke Expires 9 January 2021 [Page 2]
Internet-Draft VirtualHum July 2020
4. Participants can hear the overall hum, but the identification of
the hum of any individual is unintentional and not to be
encouraged.
5. The chair will generally assess the overall hum relative to the
number of people in the room.
6. While the intensity of the overall hum is theoretically on a
continuous scale, in practice Chairs only recognise a limited
number of intensities of overall hum.
7. The overall loudness of a hum is governed by the physics of
sound, most closely mapped to that of simple musical instruments
[VIOLINS].
8. It gets increasingly difficult to differentiate between hums as
the number of people humming increases, with a practical limit
reached at some point.
9. The larger the number of participants in a session, the more
likely it is that there will be some who do not understand the
subject matter well enough to participate in a hum.
3. Tool specification
This specification is intended to be feature complete, which means
that what should be implemented is only what is explicitly stated
here and nothing else.
3.1. General
* There is only one type of hum
* Only one hum can be open at any one time in a session.
3.2. Opening and closing hums
* A session chair can open a hum.
* A session chair can open a hum at any time during a session,
except when a hum is already open.
* A session chair can open multiple hums per session.
* A hum is automatically closed 20 seconds after it is open.
3.3. Taking part in a hum
Duke Expires 9 January 2021 [Page 3]
Internet-Draft VirtualHum July 2020
* When a hum is open, each participant in the session, except the
chairs, may take part in the hum through the following mechanism:
1. Each session participant is presented with the following
options from which they can select. No option is selected as a
default. 1. "Soft (single)" 2. "Loud (double)" 2. Selection of
an option requires a confirmation action and only takes effect
when confirmed. 3. Once an option has been chosen and confirmed
then it cannot be changed.
* When a participant selects and confirms any option, they are
considered to have hummed.
* If a participant joins the session during the hum then they can
take part.
* If a participant leaves the session during the hum, they are
considered to have hummed and their hum is still used for data
calculation.
* A timer is shown during the hum to all participants and chairs.
3.4. After the hum
* When a hum is closed a score **_s_ calculated as the sum of: 1. 1
for each Soft hum 2. 2 for each Loud hum
* A hum indicator is then displayed as follows depending on the
value of **_s_ and the following buckets:
1. **_s_ <= 2: niente
2. **_s_ > 2 and **_s_ <= 10: pianissimo
3. **_s_ > 10 and **_s_ <= 26: piano
4. **_s_ > 26 and **_s_ <= 58: forte
5. **_s_ > 58: fortissimo
* The hum indicator is displayed to all MeetEcho participants, not
just the chairs.
* When a new hum is opened the indicator from the previous hum is
blanked out, ready to be replaced with a new indicator when the
hum closes.
3.5. Explanatory notes
Duke Expires 9 January 2021 [Page 4]
Internet-Draft VirtualHum July 2020
* The choice of buckets for **_s_ uses a simple formula where the
size of the bucket doubles each time, which equates to exponential
growth in the bucket size. This is roughly equivalent to the
logarithmic formulae in [VIOLINS] used to calculate the increase
in loudness from one violin to two violins playing the same note.
* The names of the hum indicators are taken from loudness marks used
in musical notation.
3.6. Implementation notes
* Some participants will not be allowed to hum contractually, but
this will not need to be enforced by the system.
* The way in which the options are presented and selected and the
way in which the hum indicator is selected is left to the
implementer. However, the text for each option should appear as
above.
* The results display needs to show all the possible results
(niente, pianissimo, piano, forte, fortissimo) in some form of
ordered view with an indicator as to which end is the quietest and
which the loudest, with the appropriate result highlighted.
4. Alternative approaches
A number of alternative approaches were considered and rejected as
set out below.
4.1. Single level of hum
A single-level of hum was considered but rejected on the basis that
it took the specification too close to voting and was not a match to
an in-person hum.
4.2. More levels of hum
More levels of hum were considered but rejected as it was felt that
two levels was the best overall match to an in-person hum.
4.3. No hum indicator
Consideration was given to separating the idea of choosing not to hum
and not being informed enough to participate. When we ceased
normalizing the result for the number of attendees, this became
irrelevant.
Duke Expires 9 January 2021 [Page 5]
Internet-Draft VirtualHum July 2020
4.4. Simple result calculation
Consideration was given to using a simple formula to calculate the
result, such as using the score not the result, and rejected as it
was felt that a logarithmic formula was a closer match to an in-
person hum.
4.5. Bucket size closer to the formulae
Consideration was given to directly using the logarithmic formulae in
[VIOLINS] used to calculate the increase in loudness from one violin
to two violins playing the same note, which would have calculated an
approximate decibel level for each hum. Each hum indicator would
then represent the same number of decibels, and so produce a similar
effect to the chosen specification. This was rejected because it
would either produce buckets that were too small and so the top
bucket would be reached too quickly, or buckets that were too large
giving the inverse problem.
4.6. Grayscale
An essentially continuous color-based indicator used in place of
buckets, would better match the continuous nature of sound and
further divorce the output from the absolute numbers of people
humming. However, this would produce higher-precision results than
are possible with human ears in a room.
5. Security Considerations
Meetecho participation is restricted to people who have datatracker
accounts, providing some assurance of identity. Potential attacks
against this tool will either subvert Meetecho admission control, or
involve multiple datatracker registrations (and Meetecho logins) to
amplify the voice of a single individual.
The integrity of this tool is dependent on the integrity of the
registration and fee waiver processes. In particular, they must weed
out duplicate registrations, bots, and so on.
6. IANA Considerations
This document has no IANA actions.
7. Informative References
[SURVEY] "IETF 107 Survey", 2020,
<https://www.ietf.org/media/documents/survey-planning-
possible-online-meetings-responses.pdf>.
Duke Expires 9 January 2021 [Page 6]
Internet-Draft VirtualHum July 2020
[VIOLINS] "Acoustics FAQ", 2015, <https://newt.phys.unsw.edu.au/jw/
musFAQ.html#extraviolin>.
Appendix A. Acknowledgements
Alissa Cooper, Jay Daley, Roman Danyliw, Colin Perkins, Alvaro
Retana, and Robert Wilton made significant contributions to this
document. Benjamin Kaduk, Erik Kline, Warren Kumari, and Barry Leiba
also provided helpful feedback.
Author's Address
Martin Duke
F5 Networks, Inc
Email: martin.h.duke@gmail.com
Duke Expires 9 January 2021 [Page 7]
