Subject: [tcpm] [Editorial Errata Reported] RFC7323 (6798)

From: RFC Errata System <[email-masked]>
Date: Sun, 26 Dec 2021 00:59:38 -0800 (PST)

The following errata report has been submitted for RFC7323,
"TCP Extensions for High Performance".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6798

--------------------------------------
Type: Editorial
Reported by: Yaakov Stein <[email-masked]>

Section: GLOBAL

Original Text
-------------
The Timestamps option may appear in any data or <ACK> segment, adding

The timestamp clock may be derived from a system clock that is

A random offset may be added to the timestamp clock on a per-

Corrected Text
--------------
The Timestamps option MAY appear in any data or <ACK> segment, adding

The timestamp clock MAY be derived from a system clock that is

A random offset MAY be added to the timestamp clock on a per-

Notes
-----
several "MAY"s were incorrectly written as non RFC 2119 "may"s

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7323 (draft-ietf-tcpm-1323bis-21)
--------------------------------------
Title               : TCP Extensions for High Performance
Publication Date    : September 2014
Author(s)           : D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed.
Category            : PROPOSED STANDARD
Source              : TCP Maintenance and Minor Extensions
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: t petch <[email-masked]>
Date: Sun, 26 Dec 2021 11:06:21 +0000

> "TCP Extensions for High Performance".

One AD once said that a MAY is the same as a MAY NOT and therefore is 
pointless.  Makes sense to me.  I find it hard to come up with a 
situation where 'MAY' has any value.

Tom Petch

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
> .
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 26 Dec 2021 15:39:54 +0100

On 26. Dec 2021, at 12:06, t petch <[email-masked]> wrote:
> 
> One AD once said that a MAY is the same as a MAY NOT and therefore is pointless.  Makes sense to me.  I find it hard to come up with a situation where 'MAY' has any value.

A MAY for one party means that the other party MUST be able to handle the allowed behavior.
(I.e., not crash, not delete all your files, MAYbe even do something meaningful with the first party’s behavior.)

Not at all pointless, if used correctly.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 Dec 2021 07:08:41 +0100

> On 2021-12-27, at 06:16, Yaakov Stein <[email-masked]> wrote:
> 
> In any case, the same RFC uses the normative "MAY" in several other places, 
> so these are probably mistakes.
> 
> For example, 
>   The three-byte Window Scale option MAY be sent in a <SYN> segment by a TCP.
> and
>   This option MAY be sent in an initial <SYN> segment.
>  
> So why 
>   A random offset may be added to the timestamp clock on a per-connection basis.
> ?
> Is this may to be considered weaker than the other two?

Is this an interoperability “MAY”, i.e., does the peer need to be prepared for this behavior?  The other two clearly are, while this seems like local matter.

Grüße, Carsten

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 27 Dec 2021 07:16:55 +0200

For example,
  The three-byte Window Scale option MAY be sent in a <SYN> segment by a
TCP.
and
  This option MAY be sent in an initial <SYN> segment.

So why
  A random offset may be added to the timestamp clock on a per-connection
basis.
?
Is this may to be considered weaker than the other two?

At first I wondered if there were some good reason for not capitalizing,
i.e., weakening the MAY even further,
but I couldn't come up with any reasonable explanation.

Y(J)S

On Sun, Dec 26, 2021 at 4:39 PM Carsten Bormann <[email-masked]> wrote:

> pointless.  Makes sense to me.  I find it hard to come up with a situation
> where 'MAY' has any value.
>
> (I.e., not crash, not delete all your files, MAYbe even do something
> meaningful with the first party’s behavior.)
>

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 27 Dec 2021 09:34:06 +0200

None of the three cases I called out will cause interop problems, but they
open potential security or privacy issues.

But the lack of interop concerns did not dictate capitalization in other
cases, such as

  A TSecr value received in a segment MAY be used to update
  the averaged RTT measurement

which is a purely local matter.

Y(J)S

On Mon, Dec 27, 2021 at 8:08 AM Carsten Bormann <[email-masked]> wrote:

> Is this an interoperability “MAY”, i.e., does the peer need to be prepared
> for this behavior?  The other two clearly are, while this seems like local
> matter.
>
> Grüße, Carsten
>
>
>

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 27 Dec 2021 09:51:45 -0800

> The Timestamps option may appear in any data or <ACK> segment, adding

This implies that receivers MUST NOT treat segments with missing or present timestamps as an error.

> The timestamp clock may be derived from a system clock that is

This implies that receivers MUST NOT treat timestamps that look like the current time as an error, e.g., they MUST NOT assume the timestamp starts at a random offset.

> A random offset may be added to the timestamp clock on a per-

This implies the converse of the previous, i.e., that the receiver MUST NOT treat timestamps that don’t appear “close” to their current value as an error.

This is why RFCs MUST (IMO) indicate a rationale whenever keywords are used - especially for wiggle-words (MAY, SHOULD and their converses), noting particularly where exceptions are known appropriate.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Dec 26, 2021, at 11:34 PM, Yaakov Stein <[email-masked]> wrote:
> 
> None of the three cases I called out will cause interop problems, but they open potential security or privacy issues.
> 
> But the lack of interop concerns did not dictate capitalization in other cases, such as 
> On Mon, Dec 27, 2021 at 8:08 AM Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
> > On 2021-12-27, at 06:16, Yaakov Stein <[email-masked] <mailto:[email-masked]>> wrote:
> >

---

From: t petch <[email-masked]>
Date: Tue, 28 Dec 2021 09:20:57 +0000

> This implies that receivers MUST NOT treat segments with missing or present timestamps as an error.

I struggle to see why this does not come under the general presumption 
of being liberal in what you accept.  If anything, it is a MUST or 
SHOULD for the receiver and no MAY is needed.

Tom Petch

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 28 Dec 2021 09:17:05 -0800

Hi, Tom,

> On Dec 28, 2021, at 1:20 AM, t petch <[email-masked]> wrote:
> 
> I struggle to see why this does not come under the general presumption of being liberal in what you accept.  If anything, it is a MUST or SHOULD for the receiver and no MAY is needed.

It could, but being conservative in what you do could argue for not varying behavior as a sender.

Additionally, many previously liberal receiver behaviors have been declared deliberate indicators of an attack because some receivers may incur extra work as a result.

Like all 2119 language, it could have been written as a converse, e.g., about the receiver this time. I don’t disagree that MAYs often can be more easily understood as converse MUST NOTs, but there are exceptions and we have no style guide on this issue AFAICT.

Joe