Further Key Words for Use in RFCs to Indicate Requirement Levels
RFC 6919
|
Document |
Type |
|
RFC - Experimental
(April 2013; No errata)
|
|
Last updated |
|
2018-12-20
|
|
Stream |
|
ISE
|
|
Formats |
|
plain text
pdf
html
bibtex
|
Stream |
ISE state
|
|
Published RFC
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 6919 (Experimental)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Independent Submission R. Barnes
Request for Comments: 6919 S. Kent
Category: Experimental BBN
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
1 April 2013
Further Key Words for Use in RFCs to Indicate Requirement Levels
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.
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 Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6919.
Barnes, et al. Experimental [Page 1]
RFC 6919 Further RFC Key Words 1 April 2013
Copyright Notice
Copyright (c) 2013 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
(http://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.
Table of Contents
1. MUST (BUT WE KNOW YOU WON'T) . . . . . . . . . . . . . . . . . 3
2. SHOULD CONSIDER . . . . . . . . . . . . . . . . . . . . . . . . 3
3. REALLY SHOULD NOT . . . . . . . . . . . . . . . . . . . . . . . 3
4. OUGHT TO . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. WOULD PROBABLY . . . . . . . . . . . . . . . . . . . . . . . . 4
6. MAY WISH TO . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. COULD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. POSSIBLE . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. MIGHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
11.1. Normative References . . . . . . . . . . . . . . . . . . . 5
11.2. Informative References . . . . . . . . . . . . . . . . . . 5
Barnes, et al. Experimental [Page 2]
RFC 6919 Further RFC Key Words 1 April 2013
1. MUST (BUT WE KNOW YOU WON'T)
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 RFC 6120 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)]." [RFC6120]
2. SHOULD CONSIDER
The phrase "SHOULD CONSIDER" indicates that the authors of the
Show full document text