Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
RFC 6525

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. 

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?

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?

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

- 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?