Stream Control Transmission Protocol
draft-ietf-tsvwg-2960bis-05
Yes
(Lars Eggert)
(Magnus Westerlund)
No Objection
(Chris Newman)
(Cullen Jennings)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 05 and is now closed.
Lars Eggert Former IESG member
(was Discuss, Yes)
Yes
Yes
()
Unknown
Magnus Westerlund Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2007-05-17)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2007-05-19)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2007-05-23)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
()
Unknown