Subject: My two cents on draft-leiba-rfc2119-update

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Aug 2016 17:30:23 +0100

The recent high-volume threads on this draft had the effect of causing me to
read it. Sorry for being sucked in.

I oppose the deprecation of the keywords in Section 3. More specifically: if I
choose to capitalise these words in a document that I write then I either have
to define the meaning afresh in each document or write a new 2119 replacement of
my own to reference.

In general, however, I don't see the motivation for the document. 2119 (despite
some clumsy language) has served us well enough and is well-enough understood to
have been used a few times.

Barry's most recent suggestion is...

   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized, as shown below, but they do not have to be.  This
   document defines how these words are interpreted in IETF documents
   when the words are capitalized and/or marked as <bcp14> in the

This appears to say (well, it does say) that "the words" are used to "signify"
the requirements and are not always capitalised when they do. It then says it
defines how they are interpreted when capitalised "and/or" marked with BCP14,
which implies that if I use lower case but reference BCP14 then the
interpretation provided by this document applies. The later attempt to disclaim
definition of "normal English meanings" runs counter to these two statements.

If you feel a strong need to pursue this document then I think Ted's suggestion
(Talmudic commentary) is the way to go: that is, "Report on the use of RFC 2119
and guidance for future use of normative language." This would not be an update
to 2119 and would not require (but could be used as a) normative reference from
other documents.

Cheers,
Adrian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 10 Aug 2016 11:49:39 -0500

> definition of "normal English meanings" runs counter to these two statements.

It's more than "referencing" BCP 14: it's using specific XML markup to
mark them as BCP 14 key words.  They will be rendered in all caps in
the generated plain text, PDF, and HTML.

OK, and a second bit:
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.

Barry

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Aug 2016 13:03:15 -0400

Yup, the re-arguing thing is why I think this is a good idea.   I just
don't think it should directly update 2119.   The XML markup is also a good
idea, and another good motivating factor for doing this work.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 10 Aug 2016 09:27:39 -0800

I actually don't worry that much about repeat discussions
unless they're likely to have, or have a history of having,
different outcomes.  The main question I have when I look
at documents like this is the extent to which they'll solve
problems around making sure that our specifications are
sufficiently clear to implement from, and timely, and I'm
unconvinced that this will address either of those questions.

I'd like to think that our review processes are robust enough
to catch misuse.

Melinda

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Aug 2016 13:33:02 -0400

Repeat discussions waste time.   Our review process is not very robust--a
lot of things slip through the cracks.   Having a clear statement about the
problem, with advice on how to proceed, would be very helpful.   Otherwise
every document that comes out is likely to choose a slightly different
approach (this is a phenomenon we see quite a bit).   This document will
not prevent that from happening, but it will stop it being the default.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 10 Aug 2016 10:03:47 -0800

On 8/10/16 9:33 AM, Ted Lemon wrote:
> Repeat discussions waste time.   

Not much, I don't think.  I certainly cannot think of
an instance where a document has been anything other than
trivially delayed by a discussion about normative language.
And of course there are serious discussions about whether
something should be mandatory or recommended, and this
document really doesn't help those at all.

I suppose my broader point is that less-than-useful process
documents waste time, as well, and they clog up the
document stream.  I'm afraid I tend to view documents like
this as contributing to our gradual but steady metamorphosis
into a conventional, process-bound standards body.

> Our review process is not very
> robust--a lot of things slip through the cracks.   

Indeed they do, but typically not 2119 mistakes.  I have
seen an awful lot of secdir and opsdir reviews go through
that don't have any useful security or operational review
but which have caught tons of nits.

Melinda

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Aug 2016 15:03:34 -0400

Actually there was plenty of back and forth on normative language when I
was on the IESG, and a lot of it had to do with the issues that Barry is
addressing in this document, particularly the uppercase/lowercase stuff.
And there was a lot of confusion on the part of draft authors, because the
IESG wasn't being particularly consistent about it.   (E.g., I really hate
it when people use tortured english to avoid saying lower-case should or
lower-case must, and a few other ADs at the time shared this view, but not
everyone did.)

A lot of the time wasted is wasted when people get it wrong and there's a
big discussion.   If you tend to get it right, you wouldn't have seen this.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Aug 2016 08:37:19 +1200

On 11/08/2016 04:49, Barry Leiba wrote:
...
> 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

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 11 Aug 2016 10:51:42 +0900

fwiw, i have been using the following for some years

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
   be interpreted as described in RFC 2119 [RFC2119] only when they
   appear in all upper case.  They may also appear in lower or mixed
   case as English words, without normative meaning.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 11 Aug 2016 11:17:48 +0900

given that i use an augmented "Requirements Language" section, the only
reason that i am not 100% with melinda is that i am often caught between
clean design and ops reality; so the SHOULD issue looms larger for me
than for most, e.g. scott.  i would not mind asking for a reason for the
escape clause; but am quite willing to go without if it avoids opening
yet another process can of worms.  

we should not open this pandora's box just to remind us to ask authors
to explain the SHOULD.

randy

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 11 Aug 2016 15:15:17 +0000

I like this boiler plate wording a little bit better than what is in draft-leiba-rfc2119-update.

I think it will better end the ambiguity as to whether lowercase is intended to be normative within the document.

However, I’m not convinced it will reduce the amount of discussion as to whether a particular use of one of these words in a document should have been written in ALL CAPS.

	Tony Hansen

On 8/10/16, 9:51 PM, "ietf on behalf of Randy Bush" <[email-masked] on behalf of [email-masked]> wrote:

    Requirements Language

    randy

---

From: Eric Gray <[email-masked]>
Date: Thu, 11 Aug 2016 15:23:42 +0000

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:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, August 10, 2016 4:37 PM
To: Barry Leiba <[email-masked]>; [email-masked]
Cc: [email-masked]; IETF discussion list <[email-masked]>
Subject: Re: My two cents on draft-leiba-rfc2119-update

Regards
   Brian

---

From: [email-masked] (Martin Rex)
Date: Thu, 11 Aug 2016 21:01:45 +0200 (CEST)

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Aug 2016 15:24:51 -0400

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
<[email-masked]> 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
> 
> 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
> in Section 6.1 of rfc5280 on the implementation of a
> certificate path validation function (end of 3rd paragraph of
> 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
>    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.
> 
>