Subject: [tsvwg] [Technical Errata Reported] RFC3168 (6494)

From: RFC Errata System <[email-masked]>
Date: Wed, 24 Mar 2021 13:29:00 -0700 (PDT)

The following errata report has been submitted for RFC3168,
"The Addition of Explicit Congestion Notification (ECN) to IP".

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

--------------------------------------
Type: Technical
Reported by: Joe Touch <[email-masked]>

Section: Header

Original Text
-------------
Updates: 2474, 2401, 793 

Corrected Text
--------------
Updates: 2474, 2401, 793, 791

Notes
-----
This is the first standards-track RFC to assign the two unused bits of the IP TOS byte to ECN. Granted it was suggested in RFC2481, but that was experimental and unable to update RFC791 because it would create a downref.

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. 

--------------------------------------
RFC3168 (draft-ietf-tsvwg-ecn-04)
--------------------------------------
Title               : The Addition of Explicit Congestion Notification (ECN) to IP
Publication Date    : September 2001
Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 24 Mar 2021 21:58:00 +0000

Joe,

I previously wondered myself whether RFC3168 updates RFC791 {Note 1}.
I came to the conclusion that the authors considered that RFC3168 
updated RFC2474 (which in turn updated RFC791). Otherwise, there would 
be no reason for RFC2474 to be in the updates header as well.

There is an appendix in RFC3168 on the history of the IPv4 ToS octet:
     https://tools.ietf.org/html/rfc3168#section-22
It shows (to me) that RFC3168 was considered to be the latest update in 
the long ancestral line of the ToS octet, rather than directly updating 
RFC791:

If it is decided that RFC3168 updates RFC791, then I think RFC3168 ought 
not to also say that it updates RFC2474.

Bob

{Note 1}: When I submitted the erratum to RFC3168 that added RFC2003 to 
the Updates header:
https://www.rfc-editor.org/errata/eid2660

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Black, David" <[email-masked]>
Date: Wed, 24 Mar 2021 22:11:47 +0000

Bob,

> not to also say that it updates RFC2474.

Hmm - if one applies the RFC 2474 and RFC 3168 updates to RFC 791 in ascending order of RFC number, the intended result is obtained.

I still think it's useful for RFC 3168 to continue to update RFC 2474 to say that the 2-bit CU (Currently Unused) field introduced in that RFC (and not present under that name in RFC 791) is now the ECN Field in addition to updating RFC 791 directly.  I'd be more inclined to agree that RFC 2474 doesn't need to be updated if that RFC hadn't introduced a new name for that field.

Thanks, --David
(author of both RFC 2474 and RFC 3168)

-----Original Message-----
From: Bob Briscoe <[email-masked]> 
Sent: Wednesday, March 24, 2021 5:58 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Black, David; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Subject: Re: [tsvwg] [Technical Errata Reported] RFC3168 (6494)

[EXTERNAL EMAIL] 

Joe,

Bob

---

From: Joseph Touch <[email-masked]>
Date: Wed, 24 Mar 2021 15:13:16 -0700

Hi, Bob,

> On Mar 24, 2021, at 2:58 PM, Bob Briscoe <[email-masked]> wrote:
> 
> Joe,
> 
> I came to the conclusion that the authors considered that RFC3168 updated RFC2474 (which in turn updated RFC791). Otherwise, there would be no reason for RFC2474 to be in the updates header as well.

Agreed; unfortunately, RFC2474 updating RFC791 is an errata (it wasn’t noted at original publication).

This all makes it very hard to trace “what updates what”, e.g., using my rfc-what-i-mean script, which isn’t able to track changes that are noted in errata.

(It begs whether that “updates” line ought to allow for post-publication revision)

> It shows (to me) that RFC3168 was considered to be the latest update in the long ancestral line of the ToS octet, rather than directly updating RFC791:
> 
> If it is decided that RFC3168 updates RFC791, then I think RFC3168 ought not to also say that it updates RFC2474.

OK, fair enough. I do think that leaving this as a cascading “updates” is unfortunate, though.

Feel free to reject the update...

Joe

> Bob
> 
> {Note 1}: When I submitted the erratum to RFC3168 that added RFC2003 to the Updates header:

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 24 Mar 2021 22:59:56 +0000

Joe,

> (It begs whether that “updates” line ought to allow for post-publication revision)

[BB] If it helps, the RFC Index picks up all the errata concerning 
updates, obsoletes, etc.

I suspect the idea of updating the header block of a published RFC would 
result in "the system says no".
But the grey area at the top of HTMLized RFCs could include corrected 
Updates and/or Obsoletes headers. It already adds "Updated by".

Bob

---

From: Martin Duke <[email-masked]>
Date: Wed, 24 Mar 2021 16:57:40 -0700

I'm leaning towards reject based on this discussion.

Joe, perhaps if your script also checked
https://www.rfc-editor.org/rfc/inline-errata/rfc3168.html, and similar
URLs, it would catch these problems?

On Wed, Mar 24, 2021 at 4:00 PM Bob Briscoe <[email-masked]> wrote:

> updated RFC2474 (which in turn updated RFC791). Otherwise, there would be
> no reason for RFC2474 to be in the updates header as well.
> > This all makes it very hard to trace “what updates what”, e.g., using my
> rfc-what-i-mean script, which isn’t able to track changes that are noted in
> errata.
> >
> >> If it is decided that RFC3168 updates RFC791, then I think RFC3168
> ought not to also say that it updates RFC2474.
> >>> This is the first standards-track RFC to assign the two unused bits of
> the IP TOS byte to ECN. Granted it was suggested in RFC2481, but that was
> experimental and unable to update RFC791 because it would create a downref.
> >>>
> >>> Instructions:
> >>> -------------

---

From: Joseph Touch <[email-masked]>
Date: Wed, 24 Mar 2021 16:58:27 -0700

Hi, Bob,

> On Mar 24, 2021, at 3:59 PM, Bob Briscoe <[email-masked]> wrote:
> 
> Joe,
> 
> [BB] If it helps, the RFC Index picks up all the errata concerning updates, obsoletes, etc.

That’s an EXCELLENT reason to then allow the “updates 791” to stay for RFC3186, IMO.

Joe

---

From: Joseph Touch <[email-masked]>
Date: Wed, 24 Mar 2021 17:05:38 -0700

Hi, Martin,

> On Mar 24, 2021, at 4:57 PM, Martin Duke <[email-masked]> wrote:
> 
> Joe, perhaps if your script also checked https://www.rfc-editor.org/rfc/inline-errata/rfc3168.html <https://www.rfc-editor.org/rfc/inline-errata/rfc3168.html>, and similar URLs, it would catch these problems?

Errata have no common format; I parse rfc-index.txt, which lists UPDATES from errata but does not do transitive closure.

E.g., if I put in RFC791, I get:
RFC0791
RFC2474
RFC6864

I suppose I could make it transitive in the forward direction….

Joe