idnits 2.17.1 draft-sheffer-hum-app-req-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (7 April 2020) is 1473 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Informational 7 April 2020 5 Expires: 9 October 2020 7 Virtual Hum Application: Requirements 8 draft-sheffer-hum-app-req-00 10 Abstract 12 The IETF has been having virtual meetings for a long time. Until 13 recently these have been interim meetings, and following the all- 14 virtual IETF-107 we expect to see more and more WG meetings take the 15 virtual route. A common practice at the IETF is to use room 16 "humming" to gauge working group consensus, though the final 17 consensus is determined by the working group chairs and typically 18 requires a mailing list poll as well. We do not have a technique 19 equivalent to the hum for virtual meetings, and arguably this reduces 20 the effectiveness of these meetings. 22 This document defines the requirements from a web application whose 23 goal is to most faithfully replicate the "feel" of hums, through the 24 use of a traditional web user interface. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 9 October 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions used in this document . . . . . . . . . . . . 3 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. General Requirements . . . . . . . . . . . . . . . . . . . . 4 63 4. Hum Rooms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Hum Questions . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. Gauging Consensus . . . . . . . . . . . . . . . . . . . . . . 6 66 7. Graphics/UI . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Transport Security . . . . . . . . . . . . . . . . . . . . . 6 68 9. Security, Access Control, Fraud . . . . . . . . . . . . . . . 7 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 72 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 14.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 14.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Appendix A. Document History . . . . . . . . . . . . . . . . . . 8 77 A.1. draft-sheffer-hum-app-req-00 . . . . . . . . . . . . . . 8 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 The IETF has been having virtual meetings for a long time. Until 83 recently these have been interim meetings, and following the all- 84 virtual IETF-107 we expect to see more and more WG meetings take the 85 virtual route. A common practice at the IETF is to use room 86 "humming" to gauge working group consensus, though the final 87 consensus is determined by the working group chairs and typically 88 requires a mailing list poll as well. We do not have a technique 89 equivalent to the hum for virtual meetings, and arguably, this 90 reduces the effectiveness of these meetings. 92 This document defines the requirements from a web application whose 93 goal is to most faithfully replicate the "feel" of hums, through the 94 use of a traditional web user interface. 96 The document's scope is strictly on the web application, and not on 97 the process implications of humming or of replacing it by a different 98 (though hopefully similar) human protocol. Please refer to [RFC7282] 99 for the authoritative discussion of what IETF consensus means, how it 100 can be reached, and the role - as well as the limitations - of 101 humming in achieving consensus. 103 1.1. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in 108 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 2. Background 113 Note: the intended audience for this section is application 114 developers who are not familiar with the IETF process. 116 IETF, the Internet Engineering Task Force, is an important standards 117 body for the Internet. Its main product is RFC documents that define 118 protocols. For example, the IP protocol is defined by RFC 791, the 119 HTTP protocol is defined by a series of RFCs, TLS 1.3 is defined by 120 RFC 8446. The IETF has a very long history and very detailed 121 processes associated with its operation. It has been holding 3 122 annual face-to-face meetings for a very long time, and is only now 123 moving more fully into virtual meetings. In fact the first fully 124 virtual IETF meeting is the upcoming IETF 107, taking place next week 125 (at the time of writing). The IETF consists of dozens of working 126 groups, and they come to decisions using a process called "rough 127 consensus" which means that most participants are in favor of a 128 certain decision and there is no large faction against or an even 129 smaller faction but with strongly held opinions. Quoting "the Tao or 130 the IETF": 132 4.2 Getting Things Done in a Working Group 134 One fact that confuses many newcomers is that the face-to-face WG 135 meetings are much less important in the IETF than they are in most 136 other organizations. Any decision made at a face-to-face meeting 137 must also gain consensus on the WG mailing list. 139 There are numerous examples of important decisions made in WG 140 meetings that are later overturned on the mailing list, often because 141 someone who couldn't attend the meeting pointed out a serious flaw in 142 the logic used to come to the decision. Finally, WG meetings aren't 143 "drafting sessions", as they are in some other standards bodies: in 144 the IETF, drafting is done elsewhere. 146 Another aspect of Working Groups that confounds many people is the 147 fact that there is no formal voting. The general rule on disputed 148 topics is that the Working Group has to come to "rough consensus", 149 meaning that a very large majority of those who care must agree. The 150 exact method of determining rough consensus varies from Working Group 151 to Working Group. Sometimes consensus is determined by "humming" - 152 if you agree with a proposal, you hum when prompted by the chair. 153 Most "hum" questions come in two parts: you hum to the first part if 154 you agree with the proposal, or you hum to the second part if you 155 disagree with the proposal. Newcomers find it quite peculiar, but it 156 works. It is up to the chair to decide when the Working Group has 157 reached rough consensus. 159 The lack of formal voting has caused some very long delays for some 160 proposals, but most IETF participants who have witnessed rough 161 consensus after acrimonious debates feel that the delays often result 162 in better protocols. (And, if you think about it, how could you have 163 "voting" in a group that invites all interested individuals to 164 participate, and when it's impossible to count the participants?) 165 Rough consensus has been defined in many ways; a simple version is 166 that it means that strongly held objections must be debated until 167 most people are satisfied that these objections are wrong. 169 See also this article [Coldewey] for another view on the humming 170 practice. 172 With the move to virtual meetings, real audio-based humming is no 173 longer an option. We would like to develop a replacement that 174 preserves as much as possible of the spirit behind this practice but 175 is workable for widely distributed virtual working group meetings. 177 3. General Requirements 179 This is a relatively simple web application. It needs to be usable 180 by people who are seeing it for the first time (meeting participants) 181 or people who have had very minimal practice and need to operate it 182 under pressure (working group chairs). 184 * Administration requires a desktop browser. 185 * Nice to have: participation from a mobile browser. 186 * Nice to have: OpenID authentication for admins. 188 4. Hum Rooms 190 Anybody can open a "hum room". The room is available for a period of 191 time (default: 6 hours) and then it is archived. The room consists 192 of: 194 * A name, defined by the room admin. 195 * A secret, random management URL, which may be shared with 2-3 196 additional admins, and visible to the IETF Secretariat. 197 * A secret, random participation URL, which will be shared with all 198 participants (should allow up to 500). After the room is 199 archived, the archive view will be returned, as the URL will wind 200 up in minutes. 201 * Configuration: the expected number of participants. Entered by 202 admins, visible to all participants. (Note: this value may not be 203 needed, this depends on the exact rules we define for gauging 204 consensus). 205 * A list of questions, see below. Some analytics, including the 206 total number of participants seen, the total number of hums taken, 207 number of unique IPs etc. Analytics are open to all participants. 208 * Expiry time of the room. 209 * A "get summary" button that enables downloading (e.g. as JSON) a 210 summary of all analytics, questions and results, so they can be 211 used in the meeting minutes. This button is available to 212 everybody. 213 * A way to close the room even before it has expired. Available 214 only to admins. 216 5. Hum Questions 218 Questions are typically entered on-the-fly by the admin, during the 219 meeting. So the interface must be very minimal/simple. 221 * Introductory text (up to 2-3 lines of text). 222 * Between 2-4 options, with text and a button for each. "I don't 223 understand the question" shall be suggested as one of the options, 224 however it should be possible to delete it. 225 * A link or popup with the detailed rules for consensus for this 226 question, visible to all participants. 228 For example: 230 Should we require encryption of all HTTP traffic, as a MUST? 232 Yes [button] 234 No [button] 236 Don't have enough information [button] (This is not the same as 237 "I don't understand the question") 239 * Questions are visible to all participants as soon as they are 240 entered (even keystroke by keystroke), similarly to Etherpad/hack- 241 MD. 242 * Buttons become available only when the admin enables the question. 243 * Buttons are available for a short duration, e.g. 3 minutes 244 * Buttons are treated as toggles, i.e. a second press disables the 245 selection. 246 * People are allowed to press more than one button (this is weird 247 but it replicates the hum experience). 248 * All participants see an indicator (e.g. progress bar) of how much 249 time remains. 251 6. Gauging Consensus 253 When the time expires for a question, each option is evaluated 254 separately: 256 * Zero responses: silence. 257 * Less than 20% of the total number of people who responded: weak 258 hum. 259 * 20-70%: medium hum. 260 * 70-100%: strong hum. 262 Only the summary (e.g. "medium hum") is displayed/retained, not the 263 exact numbers. In addition, we display the total number of 264 responses. 266 Admins (working group chairs) are expected to announce the results to 267 the protocol, and decide whether consensus has been reached, before 268 moving on to the next question. 270 7. Graphics/UI 272 Please include the IETF logo, https://www.ietf.org/logo/. 274 8. Transport Security 276 * HTTPS, and redirection from HTTP to HTTPS. 278 * Please use Let's Encrypt for certificates. You should probably 279 use the Certbot client. 280 * The server should have scheduled code that fetches a new 281 certificate automatically 2 weeks before the cert expires. 282 * To authorize the server to Let's Encrypt, use the HTTP-01 283 challenge. 285 9. Security, Access Control, Fraud 287 Basically none. Counting unique IPs allows for detection of simple- 288 minded fraud. 290 10. IANA Considerations 292 This is a process document, with no IANA implications. 294 11. Security Considerations 296 The process described here may have operational security 297 considerations related to the IETF process, but none that apply 298 directly to any IETF deliverables. 300 12. Privacy Considerations 302 IETF processes are not expected to ensure anonymity of participants. 303 The process described here does not make any changes to the existing 304 privacy guarantees. 306 13. Acknowledgements 308 I would like to thank Michael Richardson for his extensive comments 309 to a previous version of this document. 311 14. References 313 14.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 14.2. Informative References 326 [Coldewey] Coldewey, D., "The messy, musical process behind the web's 327 new security standard", June 2018, 328 . 331 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", 332 RFC 7282, DOI 10.17487/RFC7282, June 2014, 333 . 335 Appendix A. Document History 337 [[Note to RFC Editor: please remove before publication.]] 339 A.1. draft-sheffer-hum-app-req-00 341 Initial version. 343 Author's Address 345 Yaron Sheffer 346 Intuit 348 Email: yaronf.ietf@gmail.com