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