Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-rfc4960-bis-15

[[e-mail]]

> On 15. Oct 2021, at 00:53, Ines Robles via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Ines Robles
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-tsvwg-rfc4960-bis-15
> Reviewer: Ines Robles
> Review Date: 2021-10-14
> IETF LC End Date: 2021-10-14
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> This document describes the Stream Control Transmission Protocol (SCTP) and
> incorporates the specification of the chunk flags registry from RFC 6096 and
> the specification of the I bit of DATA chunks from RFC 7053. This document
> obsolotes RFC 4960, RFC 6069 and RFC 7053.
> 
> Some minor nits found.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> Page 10: Primary Path:....destination and source address -> destination and
> source transport address?
No. For an association the port numbers are fixed. No text change.
> 
> Page 16: Section 2.5.7: "...currently perceived reachability..." -> Which
> mechanisms are used to perceive reachability?
Just changed the sequence of sentences to make this clear. The new text reads:

The SCTP path management function monitors reachability through heartbeats
when other packet traffic is inadequate to provide this information and advises
the SCTP user when reachability of any transport address of the peer endpoint
changes.
The path management function chooses the destination transport address
for each outgoing SCTP packet based on the SCTP user's instructions and the
currently perceived reachability status of the eligible destination set.
> 
> Page 18: "... for ABC..." => "... for Appropriate Byte Counting (ABC)..."?
Yes, fixed.
> 
> Page 42: "... send a HEARTBEAT..." -> ... send a HEARTBEAT (HB)..."
Fixed.
> 
> Page 55, Figure 3: "generate Cookie" -> "generate State Cookie"?.
>                                   "start init timer" -> "start T1-init timer"?
>                                   "start cookie timer" -> "start T1-cookie
>                                   timer"?
Fixed.
> 
> Page 58, Section 5.1: In the section A) , should be added the creation of the
> TCB?
Yes, fixed.
> 
> Page 66, Section 5.2: "... this endpoint. , the endpoint processes..." ->
> "...this endpoint. Therefore, the endpoint processes..."?
Yes, fixed.
> 
> Page 76: "... ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-SENT." -> "...
> ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-SENT states."?
>         "... SHUTDOWN-PENDING, and SHUTDOWN-RECEIVED."->"... SHUTDOWN-PENDING,
>         and SHUTDOWN-RECEIVED states."?
Yes, fixed.
> 
> Page 77: "... indefinte ...." -> indefinite?
Fixed.
> Page 80: One of the reason for setting the I bit from RFC 7053 (Section 5.1. 
> Sender-Side Considerations) is not present in the draft, is this Ok? "The
> sending of an Outgoing SSN Reset Request Parameter or an SSN/TSN Reset Request
> Parameter is pending, if the association supports the Stream Reconfiguration
> extension defined in [RFC6525]."
You are correct. This was done intentionally:
* RFC 7053 does not use normative text for this, it just provides an incomplete
  list of conditions where setting the I bit is beneficial.
* The text omitted does refer to an SCTP extension, which is not covered in
  the base specification.
No text change.
> 
> Page 81: "...Gap Ack Block fields. , the endpoint"-> "Gap Ack Block fields.
> Therefore, the endpoint"?
Yes. Fixed.
> 
> Page 94: "...then IP fragmentation MUST be used. , an SCTP association can..."
> -> "...then IP fragmentation MUST be used. Therefore, an SCTP ..."?
Yes. Fixed.
> 
> Thanks for this document,
> 
> Ines.
> 
> 
>