Subject: RFC2119 Upper Case Syntax for rfc2460bis

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Oct 2015 14:58:48 -0700

There has been several suggestions on the list that rfc2460bis (and I assume rfc4291bis) should reference RFC2119 and use the Upper cast SHOULD, MUST, etc. language.  RFC2460 and RFC4291 were written before this was commonplace.

Formally RFC2119 is not required to be used, nor does it require upper case language.  It’s use is a SHOULD :-)

RFC2460 and RFC4291 both use similar words, that is should, must, recommend, may etc, but not in upper case.  IPv6 is widely implemented and I do not think that there is any evidence that the lack of use of RFC2119 language has been a hinderance to IPv6 implementations.  Nor do any of the RFCs that update fix this kind of problem.

My view is that we should not introduce RFC2119 style of language into rfc2460bis and rfc4291bis.  I have several reasons for this.

I think we should be making as few changes a possible in order to move these specification to Internet Standard. The more changes we make that are not required to meet the requirements in RFC6410, the greater the risk of breaking interoperability.

While I don’t think there would be a risk with many of the changes from “should” to “SHOULD” etc., there are more than a few cases where the language is declarative, but the RFC2119 words are not used.  While the meaning of this current text is clear, if we change all of the lower case should/must language to upper case, some may argue that because the text that doesn’t use these words they are not required to implement.  If we try to rewrite all of the declarative text to use upper case “SHOULD/MUST” we may well break interoperability.

Overall I think that moving to RFC2119 style has the potential to create problems where they don’t exist today.

Bob

---

From: Ralph Droms <[email-masked]>
Date: Tue, 20 Oct 2015 18:47:40 -0400

> On Oct 20, 2015, at 5:58 PM 10/20/15, Bob Hinden <[email-masked]> wrote:
> 
> 

I agree with the points Bob makes and my input is that RFC 2119 style requirements language should not be edited into rfc2460bis.

- Ralph

> 
> Bob
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: james woodyatt <[email-masked]>
Date: Tue, 20 Oct 2015 16:13:35 -0700

On Oct 20, 2015, at 15:47, Ralph Droms <[email-masked]> wrote:
>> […]

I won’t object if rfc2460bis and rfc4291bis are published without using RFC 2119 style requirements language, but I think it’s reasonable to ask that the specifications include an explanation for their diversion from recommended style. (I’d compose an offering to that effect, but I think a straightforward editing of Bob’s message to initiate this thread would suffice.)

—james

---

From: David Farmer <[email-masked]>
Date: Tue, 20 Oct 2015 18:59:40 -0500

On 10/20/15 18:13 , james woodyatt wrote:
> On Oct 20, 2015, at 15:47, Ralph Droms <[email-masked]
> <mailto:[email-masked]>> wrote:
>> On Oct 20, 2015, at 5:58 PM 10/20/15, Bob Hinden <[email-masked]
>> <http://ail.com>> wrote:
>>>
>>> There has been several suggestions on the list that rfc2460bis (and I
>>> assume rfc4291bis) should reference RFC2119 and use the Upper cast
>>> SHOULD, MUST, etc. language.  RFC2460 and RFC4291 were written before
>>> this was commonplace.
>>>
>>> Formally RFC2119 is not required to be used, nor does it require
>>> upper case language.  It’s use is a SHOULD :-)
>>> […]
>>> Overall I think that moving to RFC2119 style has the potential to
>>> create problems where they don’t exist today.
>>
>> I agree with the points Bob makes and my input is that RFC 2119 style
>> requirements language should not be edited into rfc2460bis.
>
> I won’t object if rfc2460bis and rfc4291bis are published without using
> RFC 2119 style requirements language, but I think it’s reasonable to ask
> that the specifications include an explanation for their diversion from
> recommended style. (I’d compose an offering to that effect, but I think
> a straightforward editing of Bob’s message to initiate this thread would
> suffice.)
>
> —james

In general I think I can support this proposed compromise, at least for 
rfc2460bis.  I haven't fully considered rfc4291bis yet.

However, there is an additional wrinkle; some of the original sources 
for the updating text in rfc2460bis had RFC2119 keywords capitalized 
making the nominative use of the keywords abundantly clear.  It concerns 
me that this abundance of clarity has been at least somewhat obfuscated 
by changing their use to lower case in rfc2460bis.

In the spirit of the suggestion above, maybe call out each of these 
situations explicitly with a footnote or within an appendix discussing 
the issue.  Further, it might be good to call out the issues in general 
and these situations specifically during IETF last call similar to a 
DOWNREF.

Thanks.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Oct 2015 14:21:17 +1300

> I agree with the points Bob makes and my input is that RFC 2119 style requirements language should not be edited into rfc2460bis.

The real issue IMHO is that we must end up with unambiguous text. There are
certainly places in the text where there is ambiguity (my favourite is that
there is no statement that extension headers are never inserted by intermediate
nodes, although I'm dead certain that was the designers' intention). I don't
really care how the ambiguities are resolved - it certainly doesn't require upper
case to state that something must not happen - but we must resolve them.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 21 Oct 2015 12:25:02 -0700

Brian,

> On Oct 20, 2015, at 6:21 PM, Brian E Carpenter <[email-masked]> wrote:
> 
>>> 

I agree that we should add text that extension headers are never inserted by intermediate nodes.  I think I can say it was the designers intent and think it is a clarification.  I also don’t think there are any RFCs that call for the insertion of extension headers, so we wouldn’t be breaking any standards based interoperability.  How about something like this, following the figure showing extension header examples on page 7:

   Extension headers must never be inserted by any node other than the source
   of the packet.  If there is a requirement to add a header, IPv6 encapsulation is the
   recommended approach.

Thanks,
Bob

---

From: Sander Steffann <[email-masked]>
Date: Wed, 21 Oct 2015 22:42:16 +0200

Hi,

>   of the packet.  If there is a requirement to add a header, IPv6 encapsulation is the

Sounds good,
Sander

---

From: Mark Smith <[email-masked]>
Date: Thu, 22 Oct 2015 08:37:08 +1100

Hi,

> I agree that we should add text that extension headers are never inserted
by intermediate nodes.  I think I can say it was the designers intent and
think it is a clarification.  I also don’t think there are any RFCs that
call for the insertion of extension headers, so we wouldn’t be breaking any
standards based interoperability.  How about something like this, following
>    of the packet.  If there is a requirement to add a header, IPv6
encapsulation is the

Separate to that, it might be worth being both more general and more
absolute regarding what the source address of the packet means. For
example, something like the following text for the source address field
description in section 3:

Source Address: 128-bit address of the originator of the packet, where
originator means creator of the IPv6 header and its fields' initial values,
all extension headers and their initial values, and the entire payload.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Thu, 22 Oct 2015 19:09:51 -0500

> and these situations specifically during IETF last call similar to a

So the discussion regarding extension headers that forked from this 
thread has caused me to rethink my position a bit;  So far we have 
discussed two options;

1. Add RFC2119 reference text and rewrite rfc2460bis using upper case 
SHOULD, MUST, etc. language.

2. Not reference RFC2119 and leaving old rfc2460 text lower case, and 
adding any new text using lower case style.

But what about another option;

3.  Add RFC2119 reference text (slightly modified, see below), leaving 
old rfc2460 text lower case (as-is for compatibility sake), but use of 
upper case SHOULD, MUST, etc. for any new text.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119] when
    capitalized.

    However, much of the text within this document predates [RFC2119],
    and has not be modified to prevent any possible change in meaning
    that could unintentionally or accidentally effect compatibility.
    Therefore, in this document when these key words are not capitalized
    they are to be interpreted based on their complete context, but
    likely have normative meaning despite not being capitalized.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Oct 2015 21:59:10 -0300

>    likely have normative meaning despite not being capitalized.

Me, I have preference for RFC2119 keywords over no RFC2119 keywords at
all. However, what I wouldn't do is to have "some" RFC2119. -- IMO,
consistence trumps.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: David Farmer <[email-masked]>
Date: Thu, 22 Oct 2015 21:15:32 -0500

> all. However, what I wouldn't do is to have "some" RFC2119. -- IMO,

I take your point.  But, we have already had the argument that lowercase 
"recommended" was not normative text in an associated thread.  Whether 
or not its correct, its a fairly common interpretation.  I would like 
the clarity of RFC2119 notation at least for any new text, to avoid any 
doubt of the intent of the new text.  But at the same time I'm loathed 
to suggest a rewrite of the old text.

Furthermore, most of the updating RFCs use RFC2119 notation, and at 
least one has explicit text intended to be added with RFC2119 notation 
in it.  Is it right to change that text to lowercase?

We have conflicting consistency issues.  There is not best here, only 
least worst.  Would you suggest the full rewrite?  Maybe in the long-run 
we should just take the hit now.

Thanks.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Oct 2015 04:05:31 -0300

Hi, David,

On 10/22/2015 11:15 PM, David Farmer wrote:
> doubt of the intent of the new text.  

BUt.. since the goal is to incorporate as few text as possible, then
you'd end up with only a few RFC2119-keyword instances, and then the
reader might think those are the only reqs that he needs to comply to.

> we should just take the hit now.

I wouldn't call applying RFC2119 a "full rewrite". And, since I'd expect
the resulting RFC to be current for ages, maybe this is the only single
time we have the chance to do this... (just me thinking out loud).

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: t.petch <[email-masked]>
Date: Fri, 23 Oct 2015 12:38:21 +0100

---- Original Message -----
From: "David Farmer" <[email-masked]>
To: "Fernando Gont" <[email-masked]>; "james woodyatt"
<[email-masked]>; "IPv6 List" <[email-masked]>; "Bob Hinden"
<[email-masked]>
Sent: Friday, October 23, 2015 3:15 AM
> we should just take the hit now.

Full rewrite (groan).

It is a pain to do - perhaps 70 changes - but anything else will cause
confusion for years to come.

If we  struggle to decide what text should be in the style of RFC2119,
well then that is part of the necessary work to advancing this to
Standard.

Tom Petch

---

From: Bob Hinden <[email-masked]>
Date: Fri, 23 Oct 2015 11:29:02 -0700

David,

> So the discussion regarding extension headers that forked from this thread has caused me to rethink my position a bit;  So far we have discussed two options;
> 
> 1. Add RFC2119 reference text and rewrite rfc2460bis using upper case SHOULD, MUST, etc. language.
> 
> 2. Not reference RFC2119 and leaving old rfc2460 text lower case, and adding any new text using lower case style.
> 
> 3.  Add RFC2119 reference text (slightly modified, see below), leaving old rfc2460 text lower case (as-is for compatibility sake), but use of upper case SHOULD, MUST, etc. for any new text.
> 

Thanks for the suggestion, but I think it’s a bad idea to have a mix of styles.  It will make the IPv6 specification very hard to read and understand.  It will very likely cause confusion and interoperability problems, some will give more weight to the upper case than the lower case.  I think it is important that it continue to be in a single style.

The focus of moving these specification to Internet standards needs to focus on the requirements in RFC6410.

Bob

---

From: james woodyatt <[email-masked]>
Date: Fri, 23 Oct 2015 11:49:52 -0700

> The focus of moving these specification to Internet standards needs to focus on the requirements in RFC6410.

So does that mean we will be changing the normative all-caps 2119 keywords present in the existing RFCs that update 2460 with non-2119 lower case when the text is incorporated within 2460bis? That would carry its own risks too, I’d think.

—james

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Oct 2015 08:23:04 +1300

> So does that mean we will be changing the normative all-caps 2119 keywords present in the existing RFCs that update 2460 with non-2119 lower case when the text is incorporated within 2460bis? That…

I don't think so. "MUST" and "must" actually mean the same thing. "may not"
and "may" when you really mean "might" are things to avoid, but if we read the
text critically for ambiguity we should be OK. In a sense, the upper case usage
is just a lazy writing technique.

   Brian

---

From: David Farmer <[email-masked]>
Date: Fri, 23 Oct 2015 18:58:40 -0500

> David,
...
> Thanks for the suggestion, but I think it’s a bad idea to have a mix of styles.  It will make the IPv6 specification very hard to read and understand.  It will very likely cause confusion and inter…

Sleeping on it I think your right, mixing styles would be bad.

At the start of this thread you pointed out that capitalization in 
RFC2119 is essentially a SHOULD.  In response James Woodyatt suggested 
that rfc2460bis therefore needs explain its reasons for not following 
that SHOULD.

I think its important to include that explicitly in rfc2460bis, to 
refute the "its not capitalized, therefore its not nominative" argument. 
  Otherwise, I can see there being discussions on that point for the 
next 20 years without it.

I think that is the last thing to resolve this issue for me.

Thanks.

---

From: t.petch <[email-masked]>
Date: Sat, 24 Oct 2015 12:22:39 +0100

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 23, 2015 8:23 PM
> >> Thanks for the suggestion, but I think it’s a bad idea to have a
mix of styles.  It will make the IPv6 specification very hard to read
and understand.  It will very likely cause confusion and
interoperability problems, some will give more weight to the upper case
than the lower case.  I think it is important that it continue to be in
a single style.
> > So does that mean we will be changing the normative all-caps 2119
keywords present in the existing RFCs that update 2460 with non-2119
lower case when the text is incorporated within 2460bis? That would
carry its own risks too, I’d think.
> is just a lazy writing technique.

Weelll ... I think it a bit more than that.

Like Internet as opposed to internet, the capitalisation indicates that
this might have a specific meaning that the reader needs to understand,
to look up.  Ok, so we put all of the RFC2119 words into capitals, which
makes sense to me as they are short and everyday words, but the message
is the same, to those not versed in IETF lore, 'Look out, you may not
understand the wrinkles here'.

Tom Petch

---

From: Bob Hinden <[email-masked]>
Date: Mon, 26 Oct 2015 08:58:25 -0700

David,

> On Oct 23, 2015, at 4:58 PM, David Farmer <[email-masked]> wrote:
> 
> At the start of this thread you pointed out that capitalization in RFC2119 is essentially a SHOULD.  In response James Woodyatt suggested that rfc2460bis therefore needs explain its reasons for not following that SHOULD.
> 
> I think its important to include that explicitly in rfc2460bis, to refute the "its not capitalized, therefore its not nominative" argument.  Otherwise, I can see there being discussions on that point for the next 20 years without it.
> 

Thanks.  I am not sure it needs to be in the actual RFC as it seems more to me about IETF procedures than IPv6.  It will definitely be in the write up when (if?) this goes to the IESG and that will be recored in the data-tracker for posterity.

Thanks,
Bob

---

From: james woodyatt <[email-masked]>
Date: Mon, 26 Oct 2015 11:24:31 -0700

> Thanks.  I am not sure it needs to be in the actual RFC as it seems more to me about IETF procedures than IPv6.  It will definitely be in the write up when (if?) this goes to the IESG and that will…

I would like to see it in the actual RFC, because the RFC series is a Publication, whereas the data-tracker is not.

Put another way, I’m fairly confident that Posterity will be able to read RFC 2460 for the next millennium, even after it passes into the Historical category, and I’m much less confident that Posterity will be able to find the data-tracker after such a long time, much less query it for the entire history of the IETF. I’m not even very confident that all the public information stored in the data-tracker today will continue to be available next week, much less after a millennium.

—james

---

From: Bob Hinden <[email-masked]>
Date: Mon, 26 Oct 2015 12:55:35 -0700

James,

> On Oct 26, 2015, at 11:24 AM, james woodyatt <[email-masked]> wrote:
> 

I am sure it will be fertile grounds to future IETF historians :-)

Any other view on this?

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2015 13:59:01 +1300

> I am sure it will be fertile grounds to future IETF historians :-)

I think it's a sad day if we have to write "In this document, English words written
in lower case mean what they say, without resorting to SHOUTING." In other words,
I take James' point but I don't know how to express it without absurdity.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Oct 2015 14:20:00 +0100

> I take James' point but I don't know how to express it without absurdity.

I agree.

For some reason I appreciate RFC2460 not using Upper case.  I somehow 
got used to it.  And at the same time, despite considering it an 
example, I had to follow best practice in new draft text to use Upper 
case for RFC2119 words... to a point that whenever such a word appeared 
it _had_ to be upper case.  This is non-sense as well, because it's good 
when one needs formulations like
"Should the reply be positive the bit MUST be set to 0".

I think I can live with such exception to the Upper case RFC2119 words 
for this particular document, and to the total absence of shouting.

Maybe dont tell other RFC authors that this is the best thing to do 
(unless there's good reason :-)

Alex