ietf-corpus

rfc-2119

Key words for use in RFCs to Indicate Requirement Levels

S. Bradner
date1997-03 streamIETF wgnon working group statusBEST CURRENT PRACTICE pages3 canonicalhttps://www.rfc-editor.org/rfc/rfc2119 doi10.17487/RFC2119 errataview
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.

updated by

also

Extracted elements (10)

design-rationale §6

Imperatives must be used with care and sparingly to preserve their meaning; overuse diminishes their normative force and imposes unnecessary constraints on implementors.

bcp, process

design-rationale §abstract

The force of these keywords is modified by the requirement level of the document in which they are used, meaning the same keyword may carry different weight depending on the overall document status (e.g., Experimental vs. Standards Track).

bcp, process

interoperability-note §5 MUST

An implementation that includes a MAY/OPTIONAL feature MUST be prepared to interoperate with implementations that omit it; likewise, an implementation that omits a MAY feature MUST interoperate with implementations that include it.

bcp, process

normative-requirement §5 MAY

MAY (or OPTIONAL) means the item is truly optional. An implementation that does not include a particular option MUST be prepared to interoperate with another implementation that does include the option, and vice versa.

bcp, process

normative-requirement §2 MUST NOT

MUST NOT (or SHALL NOT) means the definition is an absolute prohibition of the specification.

bcp, process

normative-requirement §1 MUST

MUST (or REQUIRED or SHALL) means the definition is an absolute requirement of the specification.

bcp, process

normative-requirement §4 SHOULD NOT

SHOULD NOT (or NOT RECOMMENDED) means there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

bcp, process

normative-requirement §3 SHOULD

SHOULD (or RECOMMENDED) means there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

bcp, process

normative-requirement §6 MUST

These imperative keywords MUST only be used where actually required for interoperation or to limit behavior with potential for causing harm; they must not be used to impose a particular method on implementors where the method is not required for interoperability.

bcp, process

security-consideration §7

These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done, may be very subtle. Document authors should elaborate the security implications of not following recommendations or requirements.

security, bcp, process