Subject: [tsvwg] [Errata Verified] RFC4960 (5202)

From: RFC Errata System <[email-masked]>
Date: Mon, 9 Jul 2018 18:31:43 -0700 (PDT)

The following errata report has been verified for RFC4960,
"Stream Control Transmission Protocol". 

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

--------------------------------------
Status: Verified
Type: Technical

Reported by: Nicholas Wilson <[email-masked]>
Date Reported: 2017-12-13
Verified by: Spencer Dawkins (IESG)

Section: 3.3.4.

Original Text
-------------
   The SACK also contains zero or more Gap Ack Blocks.  Each Gap Ack
   Block acknowledges a subsequence of TSNs received following a break
   in the sequence of received TSNs.  By definition, all TSNs
   acknowledged by Gap Ack Blocks are greater than the value of the
   Cumulative TSN Ack.

Corrected Text
--------------
   The SACK also contains zero or more Gap Ack Blocks.  Each Gap Ack
   Block acknowledges a subsequence of TSNs received following a break
   in the sequence of received TSNs.  By definition, all TSNs
   acknowledged by Gap Ack Blocks are greater than the value of the
   Cumulative TSN Ack.

   The sequence of Gap Ack Blocks MUST be an increasing sequence of
   ranges, non-intersecting, and with at least one TSN as a gap between
   each Block and between the Cumulative TSN Ack and the first Block.

Notes
-----
It seems clear that the Gap Ack sequence must be sent in its "canonical" form (monotonic non-overlapping ranges) but I can't find anywhere where this is actually stated.

It is implied (but not stated) by the following sentence on the next page, which implies that there is no freedom of choice in how the Gap Ack sequence is encoded:

    "For example, assume that ...
    then the parameter part of the SACK MUST be constructed as follows"

--------------------------------------
RFC4960 (draft-ietf-tsvwg-2960bis-05)
--------------------------------------
Title               : Stream Control Transmission Protocol
Publication Date    : September 2007
Author(s)           : R. Stewart, Ed.
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 10 Jul 2018 12:11:37 +0200

> On 10. Jul 2018, at 03:31, RFC Errata System <[email-masked]> wrote:
> 
Hi Spencer,

just to be clear:

This errata suggests two corrections:
(1) Ensure that the gap ack blocks are not overlapping.
(2) Ensure that the gap ack blocks are monotonic.

The result of the discussion (and therefore what has been included in
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.47)
is the following:
* The intention actually was to have the gap blocks isolated. So accepting (1)
  is OK.
* In some cases you blocks might not be monotonic. This is the same as with
  the handling of gap reports in TCP SACK. Therefore (2) is NOT OK.

Not sure if this covered by "Verified".

Best regards
Michael

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 13 Jul 2018 12:39:04 -0500

Hi, Michael,

>   the handling of gap reports in TCP SACK. Therefore (2) is NOT OK.

Right.

> Not sure if this covered by "Verified".

So, you're thinking "Held for document update"?

This case is slightly odd, because one correction is correct, so that's why
I marked the errata as "Verified", even though the other correction is not.
I'm happy to hear other opinions (I'm not an errata system wizard, and
haven't had an errata that fit this corner case previously).

If it seems more appropriate to people that I mark the errata as "Held for
document update", I'm happy to do that.

Just let me know.

Spencer

> > It seems clear that the Gap Ack sequence must be sent in its "canonical"
> form (monotonic non-overlapping ranges) but I can't find anywhere where
> this is actually stated.
> >
> > It is implied (but not stated) by the following sentence on the next
> page, which implies that there is no freedom of choice in how the Gap Ack
> sequence is encoded:
> >

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 13 Jul 2018 19:48:05 +0200

> On 13. Jul 2018, at 19:39, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Michael, 
> 
> On Tue, Jul 10, 2018 at 5:11 AM Michael Tuexen <[email-masked]> wrote:
> This case is slightly odd, because one correction is correct, so that's why I marked the errata as "Verified", even though the other correction is not. I'm happy to hear other opinions (I'm not an errata system wizard, and haven't had an errata that fit this corner case previously). 
> 
> If it seems more appropriate to people that I mark the errata as "Held for document update", I'm happy to do that.
> 
> Just let me know. 
Maybe "Held for document update" is more appropriate... I just want to
avoid that by stating "Verified" reader make the assumption that both
suggestions/comments are correct.

Best regards
Michael

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 13 Jul 2018 14:01:36 -0400

Spencer, I guess, you can also edit the errata and remove the second part (or at minimum at a comment). Maybe double-check with the secretary!

Or alternatively, you reject this errata which a comment that one part is incorrect, and submit a new errata with only the correct part…

Mirja

> Am 13.07.2018 um 13:48 schrieb Michael Tuexen <[email-masked]>:
>

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 13 Jul 2018 20:22:40 +0200

> On 13. Jul 2018, at 20:01, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
Both would work for me...

Best regards
Michael