Description: Section 2 " Because this specification is an informational specification (not able to directly use [RFC2119])," Since a large number of Informational RFCs reference RFC 2119 and use normative language, this statement seems odd. Perhaps what it is trying to say is that the terms don't mean the same thing in this document as they do in RFC 2119? If that is the case, language such as that from RFC 2989 Section 1.1 might make sense:
Please note that the requirements specified in this document are to be used in evaluating protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted. A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST, MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant." As it is, the MUST, MUST NOT, SHOULD, SHOULD NOT, etc. definitions are confusing. Proposed Resolution: Currently we use the same text as in RFC 5209 (NEA requirements). I think we can remove the first sentence in the paragraph, which is not in RFC 5209, to remove the confusion. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
