Subject: An observation on draft-leiba-rfc2119-update-01

From: Stewart Bryant <[email-masked]>
Date: Tue, 7 Feb 2017 10:01:41 +0000

Barry,

Your proposed text says:

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
       "MAY", and "OPTIONAL" in this document are to be interpreted as
       described in BCP 14 [RFC2119],[RFCxxxx] when, and only when, they
       appear in all capitals, as shown here.

The above text raises an interesting problem. If the update system works 
then
the text should read [RFC2119]. If the update system does not work than
the text needs to be [RFC2119],[RFCxxxx] as shown, but we also need to move
to a system where we always list the update set at the time of 
publication, for
example in RFC5462:

Updates: 3032, 3270, 3272, 3443, 3469,
                  3564, 3985, 4182, 4364, 4379,
                  4448, 4761, 5129

If your text is right, then whenever I would write [RFC3032], I should 
in future
write [RFC3032],[RFC5462] etc, alternatively your text is incorrect and
should simply say [RFC2119].

I am also somewhat curious about the practical implication of 
misinterpreting
MUST as must, and must as MUST.

For example: if A receives a foo packet, it MUST/must reply with a bar 
packet

The interoperability considerations are identical, with but with the 
advantage
that  MUST draws the eye of the reader to  the point and reducing the 
chance
that they will miss it. Similarly with the other keywords. So is there 
really
a problem to be fixed here?

- Stewart

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Feb 2017 10:45:56 -0500

Hi, Stewart.

> to a system where we always list the update set at the time of publication,

It took me a while to get what you mean here, but I think I have it:
you're saying that because this document (RFC xxxx) UPDATES RFC 2119,
*any* document that cites RFC 2119 and is published after this one
must automatically be taken to refer to this one and must follow the
terms of this one.  So why have the double citation?

You're right, as far as that goes, but if it's important to know for
sure whether a document is following the terms of RFC xxxx or not (and
see below about that), then I think it's important to be explicit
about it.  It's a question of clarity: the reader of another document
should not have to wonder, should not have to check publication dates,
should not be uncertain.  Having the citation there explicitly is good
for clarity.

In fact, we *do* often (though not always) cite update documents when
we're explicitly talking about a feature that was updated.  I think we
do it when calling the reader's attention to the update is
particularly important.

Now, as to the other point:

> that  MUST draws the eye of the reader to  the point and reducing the chance

This did come up in earlier discussion about "MUST".  Sure, it's
possible that there really isn't a reason to define "MUST" in BCP 14
because the English meaning is clear enough.  But "SHOULD" and "MAY"
do need these definitions: the English meanings don't accurately
convey the BCP 14 meaning.  And even with "MUST", the BCP 14 meaning
explicitly says that it's a protocol requirement that affects
interoperability or security, and we do seem to think that making that
distinction is important.

In any case, the current BCP 14 defines "MUST", and it's specifically
not a goal of this document to change that older decision.

Barry

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 7 Feb 2017 16:10:23 +0000

> do it when calling the reader's attention to the update is

I am afraid I disagree. Either the update system works or it does not. 
If you think
people do not follow through the updates, then we need to always include 
update
list, or we need a system that always gives them the update when they 
request the
base document. So for example someone asking for RFC2119 would find this
automatically but distinctly appended to it.

Ironically in this case the result is no text change to the document 
making the
reference since a MUST is a MUST.

> not a goal of this document to change that older decision.

No, the point is that either type of must is exactly the same 
instruction - "do it or it's broken".

Similarly when should is given it is advisory, and there is no forcing 
how seriously the
individual takes that advice.

So if someone mistakes a MUST for a must, I don't see how the on the 
wire behaviour
can possibly change. Same for the other key words.

- Stewart

---

From: "John Levine" <[email-masked]>
Date: 7 Feb 2017 16:38:56 -0000

>do it when calling the reader's attention to the update is

Agreed, since this update is not backward compatible.  It would have
been a lot cleaner to replace 2119 with, say, 8119, but I can see why
you didn't want to open that particular institutional size can of
worms.

> even with "MUST", the BCP 14 meaning

That is surprisingly unclear to a lot of people, particularly ones not
deeply embedded in the IETF.  We know that MUST means "do this if you
want to interoperate" but I know people who imagine it means "do this
or else."

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Feb 2017 08:15:06 +1300

On 08/02/2017 04:45, Barry Leiba wrote:
> terms of this one. 

Huh? If a document refers to RFC2119, it refers to 2119. That might be
a bug in the document, but I don't think we've ever said that updates
propagate by magic in that way. (We have said that the current system
is broken, because implementers have to follow a daisy chain to find out
the latest versions of everything, but that's a different problem.)

Recommending that future documents cite [BCP14] would simplify life.
The RFC Editor knows how to handle that.

   Brian

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Feb 2017 11:23:40 -0800

> The RFC Editor knows how to handle that.

I thought about that, but then there's the "publication date" problem
again: you'd have to look at what BCP 14 was at the time the document
you're reading was published.  That's why I've suggested using "BCP
14" in the text, but explicitly citing the two RFCs.  Looking for
strong clarity.

Of course, one could argue that the BCP 14 boilerplate text makes it
clear enough, so....

Barry