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

[Gorry Fairhurst <[e-mail]>]

On 25/10/2021 20:34, [e-mail] wrote:
> A new version (-16) has been submitted for draft-ietf-tsvwg-rfc4960-bis:
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-rfc4960-bis-16.txt
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-rfc4960-bis-16.html
>
> Sub state has been changed to AD Followup from Revised ID Needed
>
>
> 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-16
>
> IETF Secretariat.
>
Thank you for completing the many updates following the last round of 
reviews.

I've now read the latest version, and I think these changes seem 
appropriate.

I do however have a few further comments (and I thiunk I may understand 
how to address all), these might be resolved in the next revision, when 
ready to be published:


1. / the SCTP might delay/

- Could we replace /the SCTP/ by something such as /an SCTP 
implementation/.

2. / MAY be bundled up to the size indicated by the PMTU./

.. Need to clarify PMTU at IP level - I think this could be /MAY be 
bundled to form an SCTP packet that does not execeed the PMTU/.

3. /The value MUST NOT be smaller than 1500./

- As a Shepherd, I have a strong preference for RFC2119 requirements 
sentences to be complete, without the surrounding text. Could you please 
rephrase similar to:

/The Advertised Receiver Window Credit MUST NOT be smaller than 1500./

4. / Any existing association  MUST NOT be affected./

- Please make RFC2119 requirements sentences complete. Could this be 
something like (I'm unsure of the detail):

/Reception of a response containing an ABORT chunk response MUST NOT be 
affect any other existing association./

5. /Any Type-Length-Value fields MUST  come after the fixed-length 
fields defined in the previous section./

- Please make RFC2119 requirements sentences complete. I suggest a 
rephrase similar to:

/Any Type-Length-Value fields MUST be placed after the fixed-length 
fields. (The fixed-length fields are defined in the previous section.)/

6. /After sending out an INIT ACK chunk/ - several cases of /out/.

- Is the /out/ needed? This occurs several times, and I had not 
previously noticed. If this is something different to just sending, i.e. 
after some further checks then please explain or otherwise perhaps 
remove /out/.

7. Seems slightly garbled, please clarify.

/An implementation MAY make available its upper layer a mechanism to 
disable fragmentation./

Could this be something like:

/An SCTP implementation MAY provide a mechanism to the upper layer that 
disables fragmentationwhen sending DATA chunks./

8. /When in such a state, it MUST behave as an implementation that does 
not support fragmentation, i.e., it  MUST reject send calls that would 
result in sending SCTP packets that exceed the current PMTU/

- Please make RFC2119 requirements sentences complete. Could this be 
something like:

/When fragmentation of DATA chunks is disabeled, the SCTP stack MUST 
behave in the same way an implementation that does not support 
fragmentation, i.e., it

rejects calls that would result in sending SCTP packets that exceed the 
current PMTU./

9. /The sender SHOULD choose the size of the DATA chunks/

.. suggest...

/ The sender SHOULD choose a size of DATA chunk/

---

Best Wishes,

Gorry Fairhurst

(Document Shepherd for draft-ietf-tsvwg-rfc4960-bis)