| Internet-Draft | Hum Application Requirements | April 2020 |
| Sheffer | Expires 9 October 2020 | [Page] |
The IETF has been having virtual meetings for a long time. Until recently these have been interim meetings, and following the all-virtual IETF-107 we expect to see more and more WG meetings take the virtual route. A common practice at the IETF is to use room "humming" to gauge working group consensus, though the final consensus is determined by the working group chairs and typically requires a mailing list poll as well. We do not have a technique equivalent to the hum for virtual meetings, and arguably this reduces the effectiveness of these meetings.¶
This document defines the requirements from a web application whose goal is to most faithfully replicate the "feel" of hums, through the use of a traditional web user interface.¶
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 October 2020.¶
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.¶
The IETF has been having virtual meetings for a long time. Until recently these have been interim meetings, and following the all-virtual IETF-107 we expect to see more and more WG meetings take the virtual route. A common practice at the IETF is to use room "humming" to gauge working group consensus, though the final consensus is determined by the working group chairs and typically requires a mailing list poll as well. We do not have a technique equivalent to the hum for virtual meetings, and arguably, this reduces the effectiveness of these meetings.¶
This document defines the requirements from a web application whose goal is to most faithfully replicate the "feel" of hums, through the use of a traditional web user interface.¶
The document's scope is strictly on the web application, and not on the process implications of humming or of replacing it by a different (though hopefully similar) human protocol. Please refer to [RFC7282] for the authoritative discussion of what IETF consensus means, how it can be reached, and the role - as well as the limitations - of humming in achieving consensus.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Note: the intended audience for this section is application developers who are not familiar with the IETF process.¶
IETF, the Internet Engineering Task Force, is an important standards body for the Internet. Its main product is RFC documents that define protocols. For example, the IP protocol is defined by RFC 791, the HTTP protocol is defined by a series of RFCs, TLS 1.3 is defined by RFC 8446. The IETF has a very long history and very detailed processes associated with its operation. It has been holding 3 annual face-to-face meetings for a very long time, and is only now moving more fully into virtual meetings. In fact the first fully virtual IETF meeting is the upcoming IETF 107, taking place next week (at the time of writing). The IETF consists of dozens of working groups, and they come to decisions using a process called "rough consensus" which means that most participants are in favor of a certain decision and there is no large faction against or an even smaller faction but with strongly held opinions. Quoting "the Tao or the IETF":¶
4.2 Getting Things Done in a Working Group¶
One fact that confuses many newcomers is that the face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list.¶
There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision. Finally, WG meetings aren't "drafting sessions", as they are in some other standards bodies: in the IETF, drafting is done elsewhere.¶
Another aspect of Working Groups that confounds many people is the fact that there is no formal voting. The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree. The exact method of determining rough consensus varies from Working Group to Working Group. Sometimes consensus is determined by "humming" - if you agree with a proposal, you hum when prompted by the chair. Most "hum" questions come in two parts: you hum to the first part if you agree with the proposal, or you hum to the second part if you disagree with the proposal. Newcomers find it quite peculiar, but it works. It is up to the chair to decide when the Working Group has reached rough consensus.¶
The lack of formal voting has caused some very long delays for some proposals, but most IETF participants who have witnessed rough consensus after acrimonious debates feel that the delays often result in better protocols. (And, if you think about it, how could you have "voting" in a group that invites all interested individuals to participate, and when it's impossible to count the participants?) Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong.¶
See also this article [Coldewey] for another view on the humming practice.¶
With the move to virtual meetings, real audio-based humming is no longer an option. We would like to develop a replacement that preserves as much as possible of the spirit behind this practice but is workable for widely distributed virtual working group meetings.¶
This is a relatively simple web application. It needs to be usable by people who are seeing it for the first time (meeting participants) or people who have had very minimal practice and need to operate it under pressure (working group chairs).¶
Anybody can open a "hum room". The room is available for a period of time (default: 6 hours) and then it is archived. The room consists of:¶
Questions are typically entered on-the-fly by the admin, during the meeting. So the interface must be very minimal/simple.¶
For example:¶
Should we require encryption of all HTTP traffic, as a MUST?
Yes [button]
No [button]
Don't have enough information [button] (This is not the same as
"I don't understand the question")
¶
When the time expires for a question, each option is evaluated separately:¶
Only the summary (e.g. "medium hum") is displayed/retained, not the exact numbers. In addition, we display the total number of responses.¶
Admins (working group chairs) are expected to announce the results to the protocol, and decide whether consensus has been reached, before moving on to the next question.¶
Please include the IETF logo, https://www.ietf.org/logo/.¶
Basically none. Counting unique IPs allows for detection of simple-minded fraud.¶
This is a process document, with no IANA implications.¶
The process described here may have operational security considerations related to the IETF process, but none that apply directly to any IETF deliverables.¶
IETF processes are not expected to ensure anonymity of participants. The process described here does not make any changes to the existing privacy guarantees.¶
I would like to thank Michael Richardson for his extensive comments to a previous version of this document.¶
[[Note to RFC Editor: please remove before publication.]]¶
Initial version.¶