It seems to me that the solution to this type of problem is for
the IESG and the RFC Editor to take the position that documents
whose use of 2119 (and 2119-like) terminology is ambiguous or
confusing should be bounced back to authors and/or WGs for
clarification and rewriting. The community, of course, would
need to back such a change of position rather than insisting
that documents go through because everyone has tried hard and
has run out of energy and/or that careful reviews aren't work
the effort.
More rules or fine-tuning BCPs seem extremely unlikely to be of
any help unless a position intolerant of ambiguous, sloppy,
terminology is taken and to be unnecessary if it is.
To repeat what some others have said, I think Barry's draft
addresses a real issue in how the lower-case forms should
normally be interpreted. But it won't solve any problems unless
we also change how we review and evaluate the individual
documents.
john
--On Thursday, August 11, 2016 21:01 +0200 Martin Rex
<mrex(_at_)sap(_dot_)com> wrote:
Eric Gray wrote:
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
We do not need to go that far.
Inside-IETF (ab)use of rfc2119 terminology is fairly common.
Canonical example of how bad it can get is PKIX (rfc5280).
The document targets three very distinct audiences:
- implementors of PKIX ("relying parties")
- application writers on top of PKIX implementations
- PKIX-conforming CAs.
but often fails to indicate to which audience individual
requirements apply.
Then it creates lots and lots of SHOULD and MUST requirements
on Certificates and Certificate Extensions (Section 4) and on
CRLs and CRL extensions (Section 5), and goes on and
waters down essentially all of those SHOULDs into factual MAYs
with the concept of a "minimum requirements implementation".
You may now think "well, that still leaves the MUST in place".
WRONG. All of the MUSTs in Sections 4 and 5 are _euthanized_
for "implementations of PKIX" with the following paragraph
in Section 6.1 of rfc5280 on the implementation of a
certificate path validation function (end of 3rd paragraph of
section 6.1):
https://tools.ietf.org/html/rfc5280#section-6.1
While the certificate and CRL profiles specified in
Sections 4 and 5 of this document specify values for
certificate and CRL fields and extensions that are
considered to be appropriate for the Internet PKI, the
algorithm presented in this section is not limited to
accepting certificates and CRLs that conform to these profiles.
Therefore, the algorithm only includes checks to verify
that the certification path is valid according to X.509 and
does not include checks to verify that the certificates and
CRLs conform to this *> profile. While the algorithm could be
extended to include checks for *> conformance to the profiles
in Sections 4 and 5, this profile *> RECOMMENDS against
including such checks.
So much for the IETF itself being clear on its use of rfc2119
in its own standards and RFC documents.
-Martin