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

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 Oct 2021 10:48:42 +0100

On 25/10/2021 20:34, [email-masked] 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)

---

From: [email-masked]
Date: Fri, 29 Oct 2021 10:52:14 +0200

> On 26. Oct 2021, at 11:48, Gorry Fairhurst <[email-masked]> wrote:
> 
> 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:
Hi Gorry,

thank you very much for reading it again. Please see my answers in-line.

Best regards
Michael
> - Could we replace /the SCTP/ by something such as /an SCTP implementation/.
Done.
> .. 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/.
I will use the text you propose. However, please note that PMTU is the size of the SCTP packet including
the common header and the chunks, but NOT the IPv4 or IPv6 header. This is explained in Section 2.3.
> - 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:
> 
OK.
> - 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./
No. This is NOT what is intended.

We are in a situation, where a packet is received which triggers the sending of a packet containing an
ABORT chunk. The important point is that you do NOT change the state of any existing associations.
Some implementations sent an ABORT and closed the association, which was a bug.

So I'm open to improve the wording, but I think the above sentence is complete. 
> 
> 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.)/
OK.
> - 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/.
I don't think the 'out' is needed and therefore removed all instances of it.
> /An implementation MAY make available its upper layer a mechanism to disable fragmentation./
> 
> /An SCTP implementation MAY provide a mechanism to the upper layer that disables fragmentation when sending DATA chunks./
OK.
> 
> 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./
OK.
> / The sender SHOULD choose a size of DATA chunk/
OK.

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 29 Oct 2021 10:55:13 +0100

See just the final queries.

On 29/10/2021 09:52, [email-masked] wrote:
>> <snip>

> the common header and the chunks, but NOT the IPv4 or IPv6 header. This is explained in Section 2.3.
Fine - The new text was also trying to avoid re-stating how the packet 
was formed:-)
> So I'm open to improve the wording, but I think the above sentence is complete.

Aha I don't wish to change the meaning. I interpretted wrong, so that 
makes me think it would be great to just make this sentence say what is 
intended.

I would love to see text that this one sentence on its own says the 
condition under which the association is not affected.

Gorry

---

From: [email-masked]
Date: Fri, 29 Oct 2021 12:39:58 +0200

> On 29. Oct 2021, at 11:55, Gorry Fairhurst <[email-masked]> wrote:
> 
> Fine - The new text was also trying to avoid re-stating how the packet was formed:-)
>> 
> Aha I don't wish to change the meaning. I interpretted wrong, so that makes me think it would be great to just make this sentence say what is intended.
> 
> I would love to see text that this one sentence on its own says the condition under which the association is not affected.
Do you think replacing

A receiver of an INIT chunk with the a_rwnd value set to a value smaller than 1500 MUST
discard the packet and SHOULD send a packet in response containing an ABORT chunk and
using the Initiate Tag as the Verification Tag.
Any existing association MUST NOT be affected.

by

A receiver of an INIT chunk with the a_rwnd value set to a value smaller than 1500 MUST
discard the packet, SHOULD send a packet in response containing an ABORT chunk and using
the Initiate Tag as the Verification Tag, and MUST NOT change the state of any existing
association.

That makes the sentence very long, but if you prefer that, I'll change it.

Best regards
Michael