Further Key Words for Use in RFCs to Indicate Requirement Levels
RFC 6919

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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