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(_at_)ietf(_dot_)org] On Behalf Of Brian E
Carpenter
Sent: Wednesday, August 10, 2016 4:37 PM
To: Barry Leiba <barryleiba(_at_)computer(_dot_)org>;
adrian(_at_)olddog(_dot_)co(_dot_)uk
Cc: draft-leiba-rfc2119-update(_dot_)all(_at_)ietf(_dot_)org; IETF discussion
list <ietf(_at_)ietf(_dot_)org>
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