<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="false" docName="draft-sheffer-hum-app-req-00" indexInclude="true" ipr="trust200902" prepTime="2020-04-07T00:11:27" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <!-- xml2rfc v2v3 conversion 2.40.1 -->
  <front>
    <title abbrev="Hum Application Requirements">Virtual Hum Application: Requirements</title>
    <seriesInfo name="Internet-Draft" value="draft-sheffer-hum-app-req-00" stream="IETF"/>
    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization showOnFrontPage="true">Intuit</organization>
      <address>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <date month="04" year="2020" day="07"/>
    <area>Security</area>
    <keyword>Internet-Draft</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">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.</t>
      <t pn="section-abstract-2">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.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t pn="section-boilerplate.1-1">
        This Internet-Draft is submitted in full conformance with the
        provisions of BCP 78 and BCP 79.
        </t>
        <t pn="section-boilerplate.1-2">
        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 <eref target="https://datatracker.ietf.org/drafts/current/" brackets="none"/>.
        </t>
        <t pn="section-boilerplate.1-3">
        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."
        </t>
        <t pn="section-boilerplate.1-4">
        This Internet-Draft will expire on 9 October 2020.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-used-in-this-do">Conventions used in this document</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-background">Background</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-requirements">General Requirements</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hum-rooms">Hum Rooms</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hum-questions">Hum Questions</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gauging-consensus">Gauging Consensus</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-graphics-ui">Graphics/UI</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-security">Transport Security</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-access-control-fra">Security, Access Control, Fraud</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t keepWithNext="true" pn="section-toc.1-1.14.1"><xref derivedContent="14" format="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.14.2">
              <li pn="section-toc.1-1.14.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.14.2.1.1"><xref derivedContent="14.1" format="counter" sectionFormat="of" target="section-14.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.14.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.14.2.2.1"><xref derivedContent="14.2" format="counter" sectionFormat="of" target="section-14.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.15">
            <t keepWithNext="true" pn="section-toc.1-1.15.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-document-history">Document History</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.15.2">
              <li pn="section-toc.1-1.15.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.15.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-draft-sheffer-hum-app-req-0">draft-sheffer-hum-app-req-00</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.16">
            <t keepWithNext="true" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">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.</t>
      <t pn="section-1-2">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.</t>
      <t pn="section-1-3">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 <xref target="RFC7282" format="default" sectionFormat="of" derivedContent="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.</t>
      <section anchor="conventions-used-in-this-document" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-conventions-used-in-this-do">Conventions used in this document</name>
        <t pn="section-1.1-1">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 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="background" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-background">Background</name>
      <t pn="section-2-1">Note: the intended audience for this section is application developers who are not familiar
with the IETF process.</t>
      <t pn="section-2-2">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":</t>
      <t pn="section-2-3">4.2 Getting Things Done in a Working Group</t>
      <t pn="section-2-4">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.</t>
      <t pn="section-2-5">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.</t>
      <t pn="section-2-6">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.</t>
      <t pn="section-2-7">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.</t>
      <t pn="section-2-8">See also this article <xref target="Coldewey" format="default" sectionFormat="of" derivedContent="Coldewey"/> for another view on the humming practice.</t>
      <t pn="section-2-9">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.</t>
    </section>
    <section anchor="general-requirements" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-general-requirements">General Requirements</name>
      <t pn="section-3-1">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).</t>
      <ul spacing="compact" bare="false" empty="false" pn="section-3-2">
        <li pn="section-3-2.1">Administration requires a desktop browser.</li>
        <li pn="section-3-2.2">Nice to have: participation from a mobile browser.</li>
        <li pn="section-3-2.3">Nice to have: OpenID authentication for admins.</li>
      </ul>
    </section>
    <section anchor="hum-rooms" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-hum-rooms">Hum Rooms</name>
      <t pn="section-4-1">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:</t>
      <ul spacing="compact" bare="false" empty="false" pn="section-4-2">
        <li pn="section-4-2.1">A name, defined by the room admin.</li>
        <li pn="section-4-2.2">A secret, random management URL, which may be shared with 2-3 additional admins, and visible to the IETF Secretariat.</li>
        <li pn="section-4-2.3">A secret, random participation URL, which will be shared with all participants (should allow up to 500). After the room is archived, the archive view will be returned, as the URL will wind up in minutes.</li>
        <li pn="section-4-2.4">Configuration: the expected number of participants. Entered by admins, visible to all participants. (Note: this value may not be needed, this depends on the exact rules we define for gauging consensus).</li>
        <li pn="section-4-2.5">A list of questions, see below.
Some analytics, including the total number of participants seen, the total number of hums taken, number of unique IPs etc. Analytics are open to all participants.</li>
        <li pn="section-4-2.6">Expiry time of the room.</li>
        <li pn="section-4-2.7">A "get summary" button that enables downloading (e.g. as JSON) a summary of all analytics, questions and results, so they can be used in the meeting minutes. This button is available to everybody.</li>
        <li pn="section-4-2.8">A way to close the room even before it has expired. Available only to admins.</li>
      </ul>
    </section>
    <section anchor="hum-questions" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-hum-questions">Hum Questions</name>
      <t pn="section-5-1">Questions are typically entered on-the-fly by the admin, during the meeting. So the interface must be very minimal/simple.</t>
      <ul spacing="compact" bare="false" empty="false" pn="section-5-2">
        <li pn="section-5-2.1">Introductory text (up to 2-3 lines of text).</li>
        <li pn="section-5-2.2">Between 2-4 options, with text and a button for each. "I don't understand the question" shall be suggested as one of the options, however it should be possible to delete it.</li>
        <li pn="section-5-2.3">A link or popup with the detailed rules for consensus for this question, visible to all participants.</li>
      </ul>
      <t pn="section-5-3">For example:</t>
      <artwork name="" type="" align="left" alt="" pn="section-5-4"><![CDATA[
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")
]]></artwork>
      <ul spacing="compact" bare="false" empty="false" pn="section-5-5">
        <li pn="section-5-5.1">Questions are visible to all participants as soon as they are entered (even keystroke by keystroke), similarly to Etherpad/hack-MD.</li>
        <li pn="section-5-5.2">Buttons become available only when the admin enables the question.</li>
        <li pn="section-5-5.3">Buttons are available for a short duration, e.g. 3 minutes</li>
        <li pn="section-5-5.4">Buttons are treated as toggles, i.e. a second press disables the selection.</li>
        <li pn="section-5-5.5">People are allowed to press more than one button (this is weird but it replicates the hum experience).</li>
        <li pn="section-5-5.6">All participants see an indicator (e.g. progress bar) of how much time remains.</li>
      </ul>
    </section>
    <section anchor="gauging-consensus" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-gauging-consensus">Gauging Consensus</name>
      <t pn="section-6-1">When the time expires for a question, each option is evaluated separately:</t>
      <ul spacing="compact" bare="false" empty="false" pn="section-6-2">
        <li pn="section-6-2.1">Zero responses: silence.</li>
        <li pn="section-6-2.2">Less than 20% of the total number of people who responded: weak hum.</li>
        <li pn="section-6-2.3">20-70%: medium hum.</li>
        <li pn="section-6-2.4">70-100%: strong hum.</li>
      </ul>
      <t pn="section-6-3">Only the summary (e.g. "medium hum") is displayed/retained, not the exact numbers. In addition, we display the total number of responses.</t>
      <t pn="section-6-4">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.</t>
    </section>
    <section anchor="graphicsui" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-graphics-ui">Graphics/UI</name>
      <t pn="section-7-1">Please include the IETF logo, https://www.ietf.org/logo/.</t>
    </section>
    <section anchor="transport-security" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-transport-security">Transport Security</name>
      <ul spacing="compact" bare="false" empty="false" pn="section-8-1">
        <li pn="section-8-1.1">HTTPS, and redirection from HTTP to HTTPS.</li>
        <li pn="section-8-1.2">Please use Let's Encrypt for certificates. You should probably use the Certbot client.</li>
        <li pn="section-8-1.3">The server should have scheduled code that fetches a new certificate automatically 2 weeks before the cert expires.</li>
        <li pn="section-8-1.4">To authorize the server to Let's Encrypt, use the HTTP-01 challenge.</li>
      </ul>
    </section>
    <section anchor="security-access-control-fraud" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-access-control-fra">Security, Access Control, Fraud</name>
      <t pn="section-9-1">Basically none. Counting unique IPs allows for detection of simple-minded fraud.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t pn="section-10-1">This is a process document, with no IANA implications.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-11-1">The process described here may have operational security considerations
related to the IETF process, but none that apply directly to any IETF deliverables.</t>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t pn="section-12-1">IETF processes are not expected to ensure anonymity of participants.
The process described
here does not make any changes to the existing privacy guarantees.</t>
    </section>
    <section anchor="acknowledgements" numbered="true" toc="include" removeInRFC="false" pn="section-13">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t pn="section-13-1">I would like to thank Michael Richardson for his extensive comments to a previous version of this document.</t>
    </section>
  </middle>
  <back>
    <references pn="section-14">
      <name slugifiedName="name-references">References</name>
      <references pn="section-14.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="BCP" value="14"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="BCP" value="14"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references pn="section-14.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Coldewey" target="https://techcrunch.com/2018/06/11/the-messy-musical-process-behind-the-webs-new-security-standard/" quoteTitle="true" derivedAnchor="Coldewey">
          <front>
            <title>The messy, musical process behind the web's new security standard</title>
            <author initials="D." surname="Coldewey" fullname="Devin Coldewey">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="June"/>
          </front>
        </reference>
        <reference anchor="RFC7282" target="https://www.rfc-editor.org/info/rfc7282" quoteTitle="true" derivedAnchor="RFC7282">
          <front>
            <title>On Consensus and Humming in the IETF</title>
            <seriesInfo name="RFC" value="7282"/>
            <seriesInfo name="DOI" value="10.17487/RFC7282"/>
            <author initials="P." surname="Resnick" fullname="P. Resnick">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="June"/>
            <abstract>
              <t>The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters.  In particular, the IETF is supposed not to be run by a "majority rule" philosophy.  This is why we engage in rituals like "humming" instead of voting.  However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns.  This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.</t>
              <t>Note: This document is quite consciously being put forward as Informational.  It does not propose to change any IETF processes and is therefore not a BCP.  It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus.</t>
            </abstract>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="document-history" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-document-history">Document History</name>
      <t pn="section-appendix.a-1">[[Note to RFC Editor: please remove before publication.]]</t>
      <section anchor="draft-sheffer-hum-app-req-00" numbered="true" toc="include" removeInRFC="false" pn="section-a.1">
        <name slugifiedName="name-draft-sheffer-hum-app-req-0">draft-sheffer-hum-app-req-00</name>
        <t pn="section-a.1-1">Initial version.</t>
      </section>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
        <organization showOnFrontPage="true">Intuit</organization>
        <address>
          <email>yaronf.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAP6ai14AA+1a23LjRpJ9x1fUsmPC0ixBXdzrtrkPXrkluzXRN7fU09Hr
cGwUgSJZIxAFowDR9IT9LfMt+2V7TlYVCKplzwfM9kuLICorKy8nT2Yxz/Os
s11l5mryV9t2va7Ui36jLpqmsoXurKvn6p35qbet2Zi685NMLxatuZ8/fO3g
rax0Ra03kFq2etnlfm2WS9Pm636T66bJW/NTfnqaYaVZuXY3V7ZeuiyzTTtX
Xdv77vz09KvT80y3Rs/VjSn61na77M7stq4t5+q67kxbmy6/pPgs852uy//R
laux5c74rLHzTKl2WZjSd7sqPlWqc8XoT1uX0DY98K7tWrP0w+fd5uBj19pi
eLlwGzlp+mzrytb7bczPXV5Zj5PvNgtX4TWX//nfw7pG78X4fnHwJNN9t3Yt
lM/xLcVi6ceZugkGlGfBsB91C6OPn7t2pWv7S3QaTNTbTr4wG20ryOeK5cya
bvlfKz6aYWsYHaZvN1h1b2iz564qzdbs5rJUqRwe0fHvTrcrA00n665r/Pzk
pDPFumj7ulhT1sn56dmXJ6dfnJydnXRrk2+M97t803uESJU3rSvwIF+YNeye
84WtWfi8NtvcRw/n4kjdlieTtGUMztu1USJvqqJAFQWqIFBBoILAz7yCRJUk
qiQxCSwRc3P1l742iurGp4PZ4798+CvZ+9Lc23qwTpZleZ4rvUBUwHlZRv2u
r26/VWtNjUyNP7Bgpe5jVm2M6fDZK1hbaYVQXeFwGzNT7+vOVqo1BeKp2vEc
3nC1CXIsY91uBgHTDAeClKpyW27Ac+uqytNG1CI/O30GYyjzc2OKDqEOe8B+
rsWrWCx/fPhur1On74wISkJa13dQLbuQQEegNTymLbC+kxflrNZTdA91W+c2
CIt+s4G8CZ+udL+CQ1x7RyVXENhAVu1N7XucAebuV2sRtbQ1dhy+o9TS4MwQ
ZUq12AXPHgpaa9t6OUu3axgN1S5rAwDhsWJ0822moGpgKgWvbE1VzdQHo0qn
atdlYmKtGMO1/amHtbD+XldwAw/AXXEg8ddDJ05la2RDrxfiMuuxfdkjHmUd
k7JgRtUMULeMTk3LZ4wXHtMVPVEE54UR4tp2hKNq2cKumnGt9Ahrt2vnTbZy
UCn4YONw0KW23XrZwxYQEl4OXp0sjakm1AMHgvLduh2sD+9l+AJ2aHVpKR1C
uR++aEPwLXVhZjHiN7YsK5NlTwgwrcORueT/4/9fOf6n/yIJwBhPGqPM+MI1
htsHZoBNoVisQmNlg7Fo8fh9Klx2M7zjo24MHxRyfuIJdMHPtkMUZFqVlrWe
5jqK4bOGBuG83m5spdtjCtEMVwd+46pZ9rYymgFqsJSG+vvfv3737fNn51+e
//prRt9K/kj5s52wAOzji9572hl6bNcIeQn3fYhujK5hxrXbZlCuwIYLbqGL
tSnDccWRrjIqT6HH//m0gqZdPHQ+OjaIiIIAawQ2hr1g9ydPUHdrxFJYBL+U
8IsE3eCP4B0QRGZK6dXk1fub28k0/K9ev5G/3119//763dUl/755cfHy5fBH
Ft+4efHm/cvL/V/7lc/fvHp19foyLMZTdfAom7y6+DgJR5+8eXt7/eb1xcvJ
J1oiZQydAGtJYDUtEh2JBMJsfNHaRTjZN8/f/u8/zp7CV/8GX52fnX3166/x
w5dnz57iw3ZtYly5Gt4PH2FdhEnTGM24JSjCNQ2MXTFhEafwF3AZIUQ0f6K+
0cUd8aQus+y1Iy2if6gYeDG06ktrakBeiBIGuhG0Z8yPk7E096ZCJAKRkJdy
RkQ7shEhaXWbbZGVe9CM0Q8V+HEavoh8Xl3VK+AA8B4hcKv9nfrWtYWZyo41
EwYcXcOOidWh1rhyp1IcJzmz7BrYARSUTGCRogSYb/AEY1En3BnSxc+4IcqG
RmqaqNvb4esAzcuEy5T37KszgrlRL25vf/dFDcu11kiSYxG8cfvyRp3NPn9E
4JdPn34xOyynWt2bdhdKJtzQoWMS18tTlAqAPdZHuxL/vUdvoxlZYnqL09I9
4i2aZlSkwWdp688hsCbCE+ryzuX8/2HN3mvBwh3qMA4gEVi7LTBYUleqa0Al
xJL7pHjM4Cbu08Xq1xK55fVxCU+vZzbARt+gElO8fIn6PmXV5gPCJCIOLRdw
xtypo1iiqaQAGIAN7x2PrEp0gSHFIaX7xQT8PaixfsCxHTmApG1pCusjBvFF
nYyesQLD3JNQVgbwmiAhbLEOeBkiTgpVo1uQCdtoBiLzxdIi9wH4tSoMotzW
w35Z1KSVclM7VbERExsy//QKL0MqnVQrJGOt/IYKtcMri74LsYBaBQfC1mtT
ATwaW/M8s+z73tFIakLL3WqnUkbBXJN5lj2dnavvTCfvoHQzKC7RbQvOqA/R
cN/RcFn2pjbJvzgwjLHsGZaoSzv2ZrRmKzRHvpcgGEfdmJjRNpseFqxo5X3+
23oPKJBSBz9FS4qJHe110BMj8C7q3WBU6FOSzqGwPhb0bDOB15UnlYPQffGL
VZxqjmhW4AckmIQ/YAxs4ROSSHjttd/HkegA6QdklFahlAopjCMg7boeqFYm
/jDedgrJwGtkc6FJRD2MS78QiAvXV2X9GYR1hPSwNp6uccR5RAACI8AT1M2W
ld4m21ZuZYtQbDs3pAC/SeoDLEldSQAf+IybTmT0w73gfDktymTgAIOnqG30
1AGiAyvnYx9P1SBMqikOaCpvtrGWXdRBhvZC92Hrg4j0+0BksYuR2BgHz6gI
L/t4HeeZTEYqdS+5EfBjBUrbskPosZjFz/qm78RIIOKHYX2ghYDuyJKfYMU0
I0yEloYREPFWUn2j/+ZknCFUGtw3ODikB+N01Rr0K1QQIYejbAxeKwXfYi9B
LH2wpbrXUpaEZB8qCwUPHszUDfQmpPo/alX2LVCu7FLtXB9UC+AjeNk4r6up
fMX2gtSFjzdNt+92pL+ZqVdMZIqcKPQnPtA/sR9jY+sER/08S7JifIaSwu8e
0SES8KgFUO7BYnAch1wZrc7g4t8RMFOvBzxbcggFNozmBV0HArEn+ZkK9OIx
i4uX4gujBQMPJ021pTTBHI/HTuTX6oETY2OCInhHdx+ErKwTYChDru1LeGkq
vQuVXb5JR/JBY8HQwNdGtSpj1EnfCFOwtftUHYU8ZSqCzaJvJqpgqwWQDHuh
CdsnR1QgwBfa1r7q2AIsUGSwfsTIji5qNBXRk+Ch9Z3SCydWlRYk4FzwI1Wb
hLNPQm0KDTN3hfR7Sz1IjIV+I6SEcJf23pYgHpKfw3k7EyiAuMSy4yOCA8oW
lQmJ3NfhKGMTfX2cvXtgkYFtJarHGkUI2sIA/0n4ZScozvGRXouVbDcmDqly
Z6FyL/4WyLgPALAw0cyl6mWeEnhGwDjChEcN9EtLoIoeAIiMpPCdLXdAPN0Y
EyqfsH45HKT8kIafPwY+GEH33pptqompg03TEsj6kHIG7FDM9uksAYFdSbfh
8oVmSCUxkexAKSPUxjWBwX7gPIQ+r+xdJGbSgcCUoWuW4UE4KFosVLd7ocWB
SuD/wY1hMqF8Y4Gu2TBJxsbDwEfy10v+ai7h2bdIVXAoAANa/4XAfzrW4aBm
NPB4Av4USsfBTUkYhNDM0L2SBjy083Tcg0kCmHMHBmVKH5vI3otKi6Gapf7L
GxMnB6k1CqAonPhoIAGjuD0mFo6kSCqtdewyWD82MnNPYzCONEzgBqG3MNwN
5VWSF9DQQ42jx8ZWIOLZn9VFSZkcnwtBHQ2v0ArfoZiqReu2cN0ML7/mll1Q
aj7KUK6ME6KNW1ia4vcWvWlMfX0pkw4OEmLrKoFMTYKHeKf1zrmNB6XYSWdZ
SNgZIgkLkQz6JqHQysyPjrsHHxtCAzWOZEpKb7A2sl4D3ObqC6BVj/OnxqLm
8EQSrFjD7eVI7KhBmYu15BZiOm4Wu/Su6D+Tl1C8WgNUbLEDvgHI6FXIhffv
Xk5TM6J3jB2/RqDEDvE8RwNYDtOvYJGAfvd2ALyBcd/INuAOunt030MHjbbe
WkDvg72Jxgf90JFfS3JrTnhjqfyP09Nj0HcpLd3Y9tF0oVWPnwIkpb2gmLDn
aRpAQZ/w5ZbJDvmEY1sjiz1P8xw00a76Nt6jyTRTxshQGLx+YaRJG2s8U1dS
TUKvH203stvDE6KkpXGLJQereiNO4dBkYSStwomEXiH4yqHpCOSO3JNDtTS+
YNxx3nwwODsOrpERMBQeCNRUZuEL4OV2lpHUwc262kE7fGXrourLNFbvXIdo
ePzQlBJmTp+8xhmrjNTx/f5pH4bM12/RFXUFe7G4qwCW5NhjtsIhrn4GPO+G
fj75P5xvsjKojSgYut1NCNadmArIb2omJduFbV05Lac6MrPVjIHwl5s3r49Z
esNK6bs5o9ybYs84mQaBoNB4Ls4EwtBzP4wcdY4xmJRAe1TpAChwUENcJcSE
Y4AKCKeoyO2HCJdefmGWnKjYMLYxNAax4mKQJgMY2u4QyL5PB8i+3x+F88d0
YwALhbB1tVzHLvEoAouIAtz0bYqFeDj2AcOYsA0Nc+Qf40JxEgqYIP1wUcS5
FW/G1VFIaqJOJWN/ehVfSMh+Y7otydJ5/jQWfFg9MG+ulYuHZFQGPlnxTE2u
2RZ+FiuQNJOiZvLihJgTwadfrQLz08yrIaaGzcAp6R1aPEIRVo2ZH4q/kXqX
UgyUlNXTNTjY0CQMk7mQrtR1zwmHmWpS8I8RI8tGc0lUhN9++y27CbpthxsT
+LNod3KKFM8ylUSNXS5tIQCoFQfiX2fZR6j0QzDjjxz/jj5ciiGFAJhauOzw
GwFITu+po8RciFvCojTBxI+uzh//9099dSzng20PA/cPDCTjbcdZ2GjAkML7
SNLozuxIoe+ELg0fjqfp6iTk0BU5baPLkzX6qfzVpUSkHJgcXnpPfZh4Q8cm
OTOgzvhAYyFU7CFjQJSh2yxjzZkqAanPE448WNyBLsfg7dxqhb0A2zM0/3ro
XUm/SE73mnhEbJFUebvvCqTGBhYXVsnwViZqzIyYZkdd9PTW2LZMHe1wxeaH
u0IWylYuDUL1eeglVh7O8dFxYSHOHvAYzd5Kdl/wBosVhNNkcnXB/JY/YInA
9l0sc89TJmUfkv3l3QCPaWK9Ty6iRMxwHsSw6ooZvYGG+KvaCdH6b9M6gn1D
+X6O4Kh4HJ7mJTUU05yf/imBxiclcs+ggxSU8jnspu9oIIo5P82fnf5pDkAt
LUwWnz47zc9O+Ti0eeFx9qYOF+JDmQr2muzXTo5lCGM92p6dKU/Iy6ywnZSV
gTIEDcPsPTG9qVCIsPTRwwx24IxNisvvMPqQboklMT9rAAfvjsKFrtTORCFT
ax/45X7uId3kI13zcK8YC2G8ZnB1Eiij/32uMUpa3YBw+pP311m6AQ3UxuxZ
bOVWDmAff8q03W7lp1Ez165O+NWJSLoFpfWc2+5/hQZvEVZvppEYlAi4Yt+K
BMh14R1Jt7A/p7MvDccIVwGmQ0UwSI9lSKOZ+uj6VHJgpYX8uKSPhOA53lzA
p0WFBJPKcyuJ3bJUxUWC2Z7W6ll4CifnBRdagnKtpbvij6NGm7IhckT2wAjO
5QrFJ1PLhAovp7SSXV26Lv7FRGwRFXDkg+NNB81pifz0jMFSIZtWRiyb7DlV
F4VchyOlEfsIi29b3ZfZN9pHpWpA0Qxfc7ABx4+IpMBXSHbOIYtU+gL7yDdW
LjKXlBeuPK8vXl8IdiDmAtoedODpZj7dEkbiUbuwcHxhf3CGR0Tur/n3V7sy
WSbTFz8NV3LIueHnasWhIBkJhJR6eIEa5nS0TZwXN42MJBiMkQ/Wu7ACfAVt
USvlINjhbWvvdfGp3uMNjB+ucsepzeyU39G4ereJI+lDrvLo4TM5fOlM4Asb
/uKGCiIoEBEDOJif0a+EEVLQcNUDnlHITbD4RXFXuy2Ce5XmJ9cPZkFE6Dv1
Cu2mNpV6x//b0keySE8DLXAG9onpR5xiLBbAe5lXpjmcQPzo9j79BmoBakBd
LtOt/otwKZtlP/zAxo7ieJV7BZh17Vw16ScYMgKLqdX0i2Gs8+OP8iOHP/yt
bHZdA7Q52Q3azbL/A7Ul7HG8KwAA

-->

</rfc>
