Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
RFC 6525
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
(Wesley Eddy; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
This is a good document describing in clear terms a useful extension. I think it would have been valuable for authors defining protocols that run over SCTP, implementers writing code to implement such protocols and operators who deploy them to add text to the document describing the impact that this new feature has on existing protocols (like IPFIX for which SCTP is a mandatory transport) or future protocols that will use SCTP as transport.
(David Harrington; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
I asked Ari Keränen to review this document, and he had a few comments:
The SSN & TSN abbreviations are never opened (with the abbreviation).
4.1. Outgoing SSN Reset Request Parameter
This field holds the length in bytes of the parameter; the value
MUST be 16 + 2 * N.
Could clarify what is "N" (the number of streams, I suppose).
5.1.1. Sender Side Procedures for the RE-CONFIG Chunk
any request by the application for such service SHOULD be responded
to with an appropriate error indicating the peer SCTP stack does not
support the re-configuration extension.
Should this be made more explicit on what error to send?
8.2. Six New Parameter Types
What is the IANA rule for making new assignments in this registry?
(Peter Saint-Andre; former steering group member) No Objection
In Section 5.1.2:
A1: The sender MUST stop assigning new SSNs to new user data
provided by the upper layer for the affected streams and queue
it. This is because it is not known whether the receiver of the
request will accept or deny it and moreover, a lost request
might cause an out-of-sequence error in a stream that the
receiver is not yet prepared to handle.
Do the first and third instances of "it" refer to "new user data"? If so, for clarity I suggest changing them to "such data".
In Section 5.1.3:
B2: If the sender wants all incoming streams to be reset no Stream
Numbers SHOULD be put into the Incoming SSN Reset Request
Parameter.
I suggest "Stream Numbers SHOULD NOT". Also, why would an application override this SHOULD NOT?
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) No Objection
The following phrase is used a couple of times in s4.*: This optional field, if included maybe use 2119 language: This OPTIONAL field, Also in s4.4: Either both optional fields Maybe: Either both OPTIONAL fields
(Stephen Farrell; former steering group member) No Objection
- A reference for SCTP on 1st use would be better. - section 7 typo: s/application must/applications must/ ? (And is that a 2119 "must"?) - I can use this to add up to 2^16 new streams? Wouldn't that be a good DoS vector? Maybe add text that implementations might either have a max-new-streams setting or else that they should react to adding lots of streams?
(Stewart Bryant; former steering group member) No Objection