Subject: [Emu] Issue 6: RFC 2119 Language

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 5 Aug 2009 13:18:40 -0700

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.