Re: [tsvwg] New Version Notification - draft-ietf-tsvwg-rfc4960-bis-07.txt

[Gorry Fairhurst <[e-mail]>]

Thanks For the new revision. I have looked and the new text addresses my comments. You noted some unaddressed comments, please see response and suggestions below:

(14)

This didn't quite make sense to me:
"The Gap Ack Blocks SHOULD be
   isolated.  This means that the TSN just before each Gap Ack Block and
   the TSN just after each Gap Ack Block have not been received. By
   definition, all TSNs acknowledged by Gap Ack Blocks are greater than
   the value of the Cumulative TSN Ack."
- Please consider if you can make the SHOULD clearer and the following sentence.
MT: What do you think is not clear. The second sentence make it as clear as possible to me...
GF: I think maybe this would benefit from some rewording. I think the word ‘isolated’ has multiple ways it can be read. I am still not quite sure what was intended? Unique or not? Is this anywhere near?...

Each Gap Ack Block SHOULD identify a unique non-overlapping range that has not been received.

(17)

"  An endpoint SHOULD NOT send a DATA chunk with no user data part."
- Why not? What is the negative impact of not following this recommendation in 6.2?
MT: The problem is in the socket layer. When using a connection oriented socket
(like a 1-to-1 style socket), a receive call returning 0 means that the
peer is not sending anything anymore and not that a user message of length
0 has been received. For UDP (not connection oriented), this is not a problem.
GF: Could we say something like this then?:

" An endpoint SHOULD NOT send a DATA chunk with no user data part. (This avoids the API returning a zero-length message.)“

(19)

I wonder what the requirement really is here...
This comes after a normative requirement to use a CRC32c, but I am not clear
what action is needed in this recommendation:
"   Any hardware implementation SHOULD be done in a way that is
   verifiable by the software."
- Is this intended to somehow utilise appendix C?
MT:I guess it means that if the hardware does not tell you that the CRC is correct, you still need to be able to do a verification in software. Intel cards have this feature" for small SCTP packets: they don't report that the CRC is correct, and the software will do the computation and make the final decision. And Intel got it wrong over and over again...

GF: I see, I expect the text can be clearer, and avoid being misread as hardware verification?... How about: 

Any hardware implementation SHOULD permit alternative verification of the CRC in software.

(26)

Appendix A contains normative text. I appreciate that ECN could be optional, but I am less than happy to see normative text in an appendix. Could this be moved to the body of the specification?
Or be removed? I don't recall that ECN was really tested in interops.
The reason it was put in an Appendix was that people were not sure if it is right
approach.
If you look at https://tools.ietf.org/html/draft-stewart-tsvwg-sctpecn-05#section-4.1
you see that chunks are defined differently. However, that document was never accepted as a WG document.

MT: Right now: leaving it as it is.
GF: OK, please do discuss this within the WG, and decide one approach to accept, or remove this text to another ID. It could also be an  appropriate time to revisit a spec for SCTP with ECN as a working group topic? However, that might not be best for a .bis document, ... please think.

Gorry

> On 14 Jul 2020, at 00:06, [e-mail] wrote:
> 
> 
> A new version (-07) has been submitted for draft-ietf-tsvwg-rfc4960-bis:
> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc4960-bis-07.txt
> 
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/
> 
> Diff from previous version:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc4960-bis-07
> 
> Please note that it may take a couple of minutes from the time of submission
> until the diff is available at tools.ietf.org.
> 
> IETF Secretariat.
>