I'm struggling with 2219 language again

[Dean Willis <[e-mail]>]

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