Stream Control Transmission Protocol
RFC 4960
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Lars Eggert (was Discuss, Yes) Yes
(Magnus Westerlund; former steering group member) Yes
(Chris Newman; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
1. The header of the document on the front page should mention that this document obsoletes RFC 2960 and RFC 4460 when approved. 2. The Network Management Considerations section says: A MIB for SCTP is defined in [RFC3873]. As this document succeeds in time RFC3873 it would be useful replace this statment with: The MIB module for SCTP defined in [RFC3873] applies for the version of the protocol specified in this document.
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
The suggested SCTP protocol parameter values defined in Section 15. Please add a forward pointer to Section 15 on the first occurrence of the use of a protocol parameter defined there. It will help the reader find the default values for these parameters. Based on Gen-ART Review by Vijay K. Gurbani: In Section 1.3.1 consider replacing "against security attacks" with "against synchronization attacks". The term "security" is too broad, and I believe that you are trying to prevent the likelihood of TCP SYN attacks in SCTP. Please consider putting Section 1.5 somewhere in the beginning. Since the sub-sections that preceeded Section 1.5 use the abbreciations quite a bit, introducing the reader to the abbreviations early should help readability. In section 3.3.5, second paragraph, the text says that the parameter field contains an opaque data structure understood only by the sender. I think it will add more clarity to insert the following text at the end of the last paragraph in the section: OLD: The Sender-specific Heartbeat Info field should normally include information about the sender's current time when this HEARTBEAT chunk is sent and the destination transport address to which this HEARTBEAT is sent (see Section 8.3). NEW: The Sender-specific Heartbeat Info field should normally include information about the sender's current time when this HEARTBEAT chunk is sent and the destination transport address to which this HEARTBEAT is sent (see Section 8.3). This information is simply reflected back by the receiver in the HEARTBEAT ACK message (see Section 3.3.6). In Section 11.2.2, it is stated that "A widely implemented BSD Sockets API extension exists for applications to request IP security services...". Please provide a reference or drop the clause. Nit: S3, page 16: s/Section 6.10for/Section 6.10 for/ Nit: S3.3.2.1, under the IPv6 address parameter figure: s/128 bit/128 bits/ Nit: S4: s/description of all special cases should be found in the text/ /description of all special cases are found in the text/ Nit: S7.1, first bullet: s/layer otherwise/layer to do otherwise/
(Sam Hartman; former steering group member) (was Discuss) No Objection
Section 11.3 on fraud seems to have no place in this document. I don't think it adds to the document and found it long-winded. As an individual I recommend removing it.
(Tim Polk; former steering group member) (was Discuss) No Objection