IESG Statement on Clarifying the Use of BCP 14 Key Words

Since March 1997, the IETF has relied on BCP 14 for definitions and guidelines for the use of certain key words to specify requirement levels for various normative assertions in technical specifications. Other standards organizations have also adopted the use of BCP 14 in their specifications.

Notably, BCP 14 recommends these key words be used “sparingly” and mandates they not be used unless they are “actually required for interoperation or to limit behavior which has potential for causing harm.”

Over time, the use of these key words has become less crisp, and they are now used in additional ways in Internet-Drafts. The IESG provides the following clarifying guidance on the interpretation and use of BCP 14. However, this guidance is not exhaustive, and other questionable uses of BCP 14 may be identified as documents are processed by the IESG.

Key words not required for normative guidance

There is occasionally a misunderstanding that BCP 14 key words are the only way to make normative expressions in an RFC. This is incorrect. For instance, the sentence “The client sends a CR and LF after a command” is a normative statement, describing an interoperability requirement, that does not use a BCP 14 key word. BCP 14 is an optional tool, and not strictly necessary.

Common Additional Uses of Key Words

As stated above, BCP 14 defined its key words to support assertions around requirements related to interoperability of a protocol and avoidance of potential harm in potential misuse of a protocol. Since its publication, the practice of using of its key words to specify the following additional types of requirements has become generally accepted by the IESG:

• Operational requirements, especially around mandatory logging and configuration needed to produce successful deployments
• Minimum components of a benchmarking framework for the results to be compared
• RFC 2119 specifically refers to use of these key words on standards track documents, but their use has also become common – and is useful – in experimental documents. They are also seen in informational documents that have interoperability requirements.

On the use of “SHOULD” and “RECOMMENDED”

The use of “SHOULD” and “RECOMMENDED” (and their corresponding negations) warrants additional guidance:

• These key words present a choice to the reader. It improves the document to provide readers with all of the details they need to make an informed decision. Thus, “You SHOULD do X” is less valuable than “You SHOULD do X because if you don’t, you get Y, which is less preferable because Z”.
• Use of these key words is not appropriate when the only reason they are chosen is to avoid committing to a “MUST” or “REQUIRED”. They shouldn’t be used merely to express a preference. If there are no interoperability implications to the choice being presented, using “MAY” or “OPTIONAL”, or omitting key words entirely, is likely more appropriate.
• Sometimes these key words are used as a way to allow for backward compatibility when introducing a change into an existing deployment. If this is the case, document authors should make it explicit that this is the reason these are used. Additional text explaining that this is the only legitimate reason to deviate from the normative advice is preferred. An alternative approach is to stipulate “All new implementations MUST do $NEW_WAY but SHOULD also accept $OLD_WAY [for some period of time] for backward compatibility”.

Inappropriate Uses of Key Words

Other uses have been observed that are generally not appropriate, such as the following (non-exhaustive) list:

• The IANA Considerations section: Using these key words to specify actions IANA should or must take. The section is entirely normative guidance to IANA; MUSTs are implied, and SHOULDs would leave IANA with choices they would prefer not to have.
• The abstract: This is not an appropriate place to make normative assertions, with or without these key words.
• In examples: The details of what’s normative should be laid out in the prose in sections before examples are presented, and thus there should be no need for normative text attached to examples.
• In appendices: An appendix is usually considered to be supplementary material only, and the specification portions of the document should be complete without it. Key words are thus best used in the primary prose of the document. An example where normative material in an appendix would be a reasonable choice is a document that contains a large table of values that form part of the specification, but would be out of place when presented in the discussion sections of the specification.
• In diagrams, figures or their captions: These are not necessarily rendered in all formats or readily available with certain Accessibility Tools. All key words must be normatively available within the main body of the document or in code blocks.

Role of RFC Editor

The RFC Editor is not expected to identify incorrect use of these key words.