I've always held to the idea that RFC 2119 language is for defining levels of
compliance to requirements, and is best used very sparingly (as recommended in
RFC 2119 itself). To me, RFC 2119 language doesn't make behavior normative --
rather, it describes the implications of doing something different than the
defined behavior, from "will break the protocol if you change it" to "we have
reason to think that there might be a reason we don't want to describe here
that might influence you not to do this" to "here are some reasons that would
cause you to do something different" and on to "doing something different might
offend the sensibilities of the protocol author, but probably won't hurt
anything else."
But I'm ghost-editing a document right now whose gen-art review suggested
replacing the vast majority of "is" "does" and "are" prose with MUST. The
comments seem to indicate that protocol-defining text not using RFC 2119
language (specifically MUST) is "not normative".
This makes me cringe. But my co-editor likes it a lot. And I see smart people
like Ole also echoing the though that RFC 2119 language is what makes text
normative.
For example, the protocol under discussion uses TLS or DTLS for a plethora of
security reasons. So, every time the draft discusses sending a response to a
request, we would say "the node MUST send a response, and this response MUST be
constructed by (insert some concatenation procedure here) and MUST be
transmitted using TLS or DTLS.
Or, a more specific example:
For the text:
In order to originate a message to a given Node-ID or
Resource-ID, a node constructs an appropriate destination list.
The Gen-ART comment here is:
-First sentence: "a node constructs" -> "a node MUST construct"
We'll literally end up with hundreds of RFC 2119 invocations (mostly MUST) in a
protocol specification.
Is this a good or bad thing? My co-editor and I disagree -- he likes
formalization of the description language, and I like the English prose. But it
raises process questions for the IETF as a whole:
Are we deliberately evolving our language to use RFC 2119 terms as the
principle verbs of a formal specification language?
Either way, I'd like to see some consensus. Because my head is throbbing and I
want to know if it MUST hurt, SHOULD hurst, or just hurts. But I MUST proceed
in accordance with consensus, because to do otherwise would undermine the
clarity of our entire specification family.
--
Dean