This document defines key words used in RFCs to indicate requirement levels in IETF documents. These words, such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", are interpreted as described in RFC 2119. The force of these words is modified by the requirement level of the document in which they are used. "MUST" and "REQUIRED" indicate absolute requirements, while "MUST NOT" and "SHALL NOT" indicate absolute prohibitions. "SHOULD" and "RECOMMENDED" suggest that there may be valid reasons to ignore an item, but the implications must be carefully considered. "MAY" and "OPTIONAL" indicate that an item is truly optional, and implementations must be prepared to interoperate regardless of whether the option is included. The use of these imperatives should be careful and sparing, only where necessary for interoperability or to limit harmful behavior. Security considerations are emphasized, as not following recommendations or requirements can have subtle security implications. The definitions of these terms are based on various RFCs and suggestions from individuals. The document was authored by Scott Bradner of Harvard University.This document defines key words used in RFCs to indicate requirement levels in IETF documents. These words, such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", are interpreted as described in RFC 2119. The force of these words is modified by the requirement level of the document in which they are used. "MUST" and "REQUIRED" indicate absolute requirements, while "MUST NOT" and "SHALL NOT" indicate absolute prohibitions. "SHOULD" and "RECOMMENDED" suggest that there may be valid reasons to ignore an item, but the implications must be carefully considered. "MAY" and "OPTIONAL" indicate that an item is truly optional, and implementations must be prepared to interoperate regardless of whether the option is included. The use of these imperatives should be careful and sparing, only where necessary for interoperability or to limit harmful behavior. Security considerations are emphasized, as not following recommendations or requirements can have subtle security implications. The definitions of these terms are based on various RFCs and suggestions from individuals. The document was authored by Scott Bradner of Harvard University.