6919
EXPERIMENTAL
Further Key Words for Use in RFCs to Indicate Requirement Levels
Authors: R. Barnes, S. Kent, E. Rescorla
Date: Unknown
Stream: INDEPENDENT
Abstract
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
The key words "MUST (BUT WE KNOW YOU WON\'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.
RFC 6919
EXPERIMENTAL
Errata Exist
Independent Submission R. Barnes
Request for Comments: 6919 S. Kent
Category: Experimental BBN
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
1 April 2013
<span class="h1">Further Key Words for Use in RFCs to Indicate Requirement Levels</span>
Abstract
<a href="./rfc2119">RFC 2119</a> defines a standard set of key words for describing
requirements of a specification. Many IETF documents have found that
these words cannot accurately capture the nuanced requirements of
their specification. This document defines additional key words that
can be used to address alternative requirements scenarios. Authors
who follow these guidelines should incorporate this phrase near the
beginning of their document:
The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER",
"REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO",
"COULD", "POSSIBLE", and "MIGHT" in this document are to be
interpreted as described in <a href="./rfc6919">RFC 6919</a>.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This is a contribution to the RFC Series, independently
of any other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc6919">http://www.rfc-editor.org/info/rfc6919</a>.
<span class="grey">Barnes, et al. Experimental [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc6919">RFC 6919</a> Further RFC Key Words 1 April 2013</span>
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
Table of Contents
<a href="#section-1">1</a>. MUST (BUT WE KNOW YOU WON'T) . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. SHOULD CONSIDER . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. REALLY SHOULD NOT . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. OUGHT TO . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. WOULD PROBABLY . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-6">6</a>. MAY WISH TO . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-7">7</a>. COULD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-8">8</a>. POSSIBLE . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-9">9</a>. MIGHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-10">10</a>. Security Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<span class="grey">Barnes, et al. Experimental [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc6919">RFC 6919</a> Further RFC Key Words 1 April 2013</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. MUST (BUT WE KNOW YOU WON'T)</span>
The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate
requirements that are needed to meet formal review criteria (e.g.,
mandatory-to-implement security mechanisms), when these mechanisms
are too inconvenient for implementers to actually implement.
This phrase is frequently used in a contracted form in which the
parenthetical is omitted. The parenthetical may also be moved later
in the sentence for stylistic reasons. If the parenthetical is
present, authors MUST provide a reason why they know implementors
will not heed this instruction in the parenthetical, as in the
example (BUT WE KNOW YOU WON'T). In the below example, we show a
case from <a href="./rfc6120">RFC 6120</a> where the original text omitted the parenthetical,
and we have indicated an appropriate parenthetical.
For example: "For authentication only, servers and clients MUST
support the SASL Salted Challenge Response Authentication Mechanism
[SCRAM] -- in particular, the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS
variants [(BUT WE KNOW YOU WON'T, because your TLS library doesn't
support extracting channel binding information)]." [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>]
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. SHOULD CONSIDER</span>
The phrase "SHOULD CONSIDER" indicates that the authors of the
specification think that implementations should do something, but
they're not sure quite what.
For example: "Applications that take advantage of typed links should
consider the attack vectors opened by automatically following,
trusting, or otherwise using links gathered from HTTP headers."
[<a href="./rfc5988" title=""Web Linking"">RFC5988</a>]
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. REALLY SHOULD NOT</span>
The phrase "REALLY SHOULD NOT" is used to indicate dangerous
behaviors that some important vendor still does and therefore we were
unable to make MUST NOT.
For example: "This command really should not be used" [<a href="./rfc0493" title=""GRAPHICS PROTOCOL"">RFC0493</a>]
<span class="grey">Barnes, et al. Experimental [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc6919">RFC 6919</a> Further RFC Key Words 1 April 2013</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. OUGHT TO</span>
The phrase "OUGHT TO" conveys an optimistic assertion of an
implementation behavior that is clearly morally right, and thus does
not require substantiation.
For example: "If a decision might affect semantic transparency, the
implementor ought to err on the side of maintaining transparency
unless a careful and complete analysis shows significant benefits in
breaking transparency." [<a href="./rfc2616" title=""Hypertext Transfer Protocol -- HTTP/1.1"">RFC2616</a>]
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. WOULD PROBABLY</span>
The phrase "WOULD PROBABLY" indicates the authors expectation about
what a reasonable implementation is likely to do in a given case.
There is no requirement for implementations to be reasonable.
This phrase is also a good example of an aspect of English grammar
that is often useful in specification writing, namely the passive-
aggressive voice, which provides a meaning in between the active and
the passive voice.
For example: "A SMTP client would probably only want to authenticate
an SMTP server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to." [<a href="./rfc3207" title=""SMTP Service Extension for Secure SMTP over Transport Layer Security"">RFC3207</a>]
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. MAY WISH TO</span>
The phrase "MAY WISH TO" indicates a behavior that might seem
appealing to some people, but which is regarded as ridiculous or
unnecessary by others. This phrase is frequently used to avoid
further delay in approval of a document.
For example: "Verifiers MAY wish to track testing mode results to
assist the Signer." [<a href="./rfc6376" title=""DomainKeys Identified Mail (DKIM) Signatures"">RFC6376</a>]
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. COULD</span>
The phrase "COULD" provides a way for specification authors to
articulate existential possibilities, in order to provide a hint that
might be critical to reliable or secure operation, but without a hard
requirement. The lack of a requirement allows for vendor product
differentiation.
For example: "An implementation could mitigate this race condition,
for example, using timers." [<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>]
<span class="grey">Barnes, et al. Experimental [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc6919">RFC 6919</a> Further RFC Key Words 1 April 2013</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. POSSIBLE</span>
The phrase "POSSIBLE" describes what some of the working group
members thought of as an edge case that will never happen, but in
practice allows the protocol to work at the most fundamental level.
For example: "It is also possible for the server to send a completion
response for some other command (if multiple commands are in
progress), or untagged data." [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>]
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. MIGHT</span>
The phrase "MIGHT" conveys a requirement in an intentionally stealthy
fashion, to facilitate product differentiation (cf. "COULD" above).
For example: "In the case of audio and different "m" lines for
different codecs, an implementation might decide to act as a mixer
with the different incoming RTP sessions, which is the correct
behavior." [<a href="./rfc5888" title=""The Session Description Protocol (SDP) Grouping Framework"">RFC5888</a>]
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Security Considerations</span>
Traditionally, security requirements in IETF documents have been
expressed with a mixture of requirements words from <a href="./rfc2119">RFC 2119</a>
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] and the phrases used above. The key words in <a href="./rfc2119">RFC 2119</a> are
principally useful when threats and mitigations are clear and well
defined. The key words in this document can be applied when the
threat model is ambiguous, and mitigations are unclear or
inconvenient.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC0493">RFC0493</a>] Michener, J., Cotton, I., Kelley, K., Liddle, D., and E.
Meyer, "GRAPHICS PROTOCOL", <a href="./rfc493">RFC 493</a>, April 1973.
[<a id="ref-RFC2616">RFC2616</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.
[<a id="ref-RFC3207">RFC3207</a>] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", <a href="./rfc3207">RFC 3207</a>, February 2002.
<span class="grey">Barnes, et al. Experimental [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc6919">RFC 6919</a> Further RFC Key Words 1 April 2013</span>
[<a id="ref-RFC3501">RFC3501</a>] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", <a href="./rfc3501">RFC 3501</a>, March 2003.
[<a id="ref-RFC5888">RFC5888</a>] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", <a href="./rfc5888">RFC 5888</a>, June 2010.
[<a id="ref-RFC5988">RFC5988</a>] Nottingham, M., "Web Linking", <a href="./rfc5988">RFC 5988</a>, October 2010.
[<a id="ref-RFC6120">RFC6120</a>] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", <a href="./rfc6120">RFC 6120</a>, March 2011.
[<a id="ref-RFC6376">RFC6376</a>] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", <a href="./rfc6376">RFC 6376</a>,
September 2011.
[<a id="ref-RFC6733">RFC6733</a>] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", <a href="./rfc6733">RFC 6733</a>, October 2012.
Authors' Addresses
Richard Barnes
BBN
1300 N 17th St
Arlington, VA 22209
US
EMail: [email protected]
Stephen Kent
BBN
10 Moulton St
Cambridge, MA 02138
US
EMail: [email protected]
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
US
EMail: [email protected]
Barnes, et al. Experimental [Page 6]
Annotations
Select text to annotate