meaning RFC 2119 (was Re:I'm struggling with 2219 language again)

[Abdussalam Baryun <[e-mail]>]

Hi Dean

I agree with you which I suggested before an update to the RFC [*], I
actually writing a work in progress ID, you may give me your
suggestion if you like. I recommend you use for your work IF, THEN
rather than MUST. Easier to read.

*  http://tools.ietf.org/id/draft-baryun-rfc2119-update-00.txt

AB

>
>
> 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
>