Brian, One part of the issues I've seen with RFC 2119 relate to the fact that there are some subtleties in the usage of the normative terminology that results in differences in interpretation by authors and reviewers alike, depending on both when the draft is written/reviewed and who is doing the review. For instance, a lot of external (non-IETF) documents use the same terms, even referring to RFC 2119, and yet explicitly create implied differences in interpretation. For instance, I know of a few cases where - in spite of an explicit reference to RFC 2119 - usage in context implicitly treats "SHOULD" and "MAY" as equivalent (often because the fact that a requirement is defined as something that SHOULD be done, makes it an optional requirement - very much like "MAY"). We can take a parochial view and claim that this "outside usage" doesn't affect us - but that is a very narrow perspective that ignores the fact that this usage in practically any context is likely to color the way people in the IETF tend to interpret the similar usage in an IETF context. A related subtlety in this is that - in many cases - SHOULD can never quite be the same as MAY (except in the sense that - when a specification states that an implementation "SHOULD do X", it implies that implementations MAY decide not to for some reason). The reason why they can never quite be the same is that explicitly saying that implementations "MAY do X" - where doing "X" results in externally visible behavior that impacts interaction with the implementations that elect to exercise this option - implies that all implementations MUST be prepared to deal with the consequences of this choice. A subtle difference in the usage of SHOULD is that (as I understand it) the intention of RFC 2119 and the most common interpretation that seems to apply in a majority of published standards track RFCs seems to be that saying implementations "SHOULD do X" means that other implementations are allowed to assume this behavior and that the burden of dealing with potential consequences of not doing "X" then falls on the implementation that elects _not_ to do "X." There are cases where this usage is appropriate; as an example, it may turn out over time that other implementations are not affected by the omission of a recommended behavior. This is often at least part of the reason why it can be necessary to use "SHOULD" instead of "MUST" in order to achieve rough consensus for some specifications. Other people may interpret RFC 2119 differently. I know that folks who use these terms outside of the IETF context frequently do interpret them differently (even when explicitly referring to RFC 2119). For this reason, it would be helpful if these subtleties were cleared up unambiguously. This could also establish a somewhat greater degree of consistency in the use of the fuzzier of the normative terms defined in RFC 2119, and could lead to improved RFC quality in a number of ways, on a number of different levels. -- Eric -----Original Message----- From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Brian E Carpenter Sent: Wednesday, August 10, 2016 4:37 PM To: Barry Leiba <barryleiba@xxxxxxxxxxxx>; adrian@xxxxxxxxxxxx Cc: draft-leiba-rfc2119-update.all@xxxxxxxx; IETF discussion list <ietf@xxxxxxxx> Subject: Re: My two cents on draft-leiba-rfc2119-update On 11/08/2016 04:49, Barry Leiba wrote: ... > There *is* a problem that this is fixing: we (collectively) spend a > lot of time messing with this -- discussing, in document after > document, whether lower-case versions matter, and what should be what. > This document is attempting to get rough-consensus answers so the > questions don't have to be re-argued over and over. Yes, I believe we have two real problems with RFC 2119 itself: 1. When a draft cites RFC 2119 *and* contains lower case instances of the RFC 2119 keywords, it is often unclear whether all those instances are intentionally "normal English" or whether they are typing mistakes. Some text to clarify what BCP 14 intends to say about that would be helpful, and what this draft says about seems fine (whether published as BCP or as commentary). 2. Uses of SHOULD are often unclear about the exceptions. The raw definition ("there may exist valid reasons...") is all one can say in a generic definition but it seems to me that we should expect specific guidance about what those reasons might be in each case. However, that is quite rare. (Before anyone checks, I am just as guilty in this respect as anyone else.) This tends to degrade SHOULD until it's almost the same as MAY. However, no amount of fixing RFC 2119, or commentary on it, can solve those two problems - only careful document review can do that. On 11/08/2016 05:27, Melinda Shore wrote: ... > I'd like to think that our review processes are robust enough > to catch misuse. As others have said, that may be optimistic, but making BCP 14 more complicated to understand won't help authors or reviewers who already find this aspect of IETF bureaucracy annoying. Regards Brian