This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. This document describes the usage of SDP for out-of-band data channel negotiation. Abstract in- band -> in-band our-of- band -> out-of-band 1. Introduction prtocols -> protocols 5.1.1 DCMAP Attribute Syntax ... 'maxtime-opt' parameter may be present -> ... 'maxtime-opt' parameter MAY be present 5.1.5 Max-retr Parameter If the max-retr parameter is not present, then the maximal number of retransmissions is determined as per the generic SCTP retransmission rules as specified in [RFC4960]. The is no maximum number of retransmissions of a user message or chunk. I would suggest to use something like If the max-retr parameter and the max-time parameter are not present, then reliable transmission is performed as specified in [RFC4960]. 5.1.6 Max-time Parameter If the max-time parameter is not present, then the generic SCTP retransmission timing rules apply as specified in [RFC4960]. This also doesn't really fit, since the retransmission timing rules specify when the next retransmission is performed. There is no 'deadline'. So I would suggest to use something like: If the max-retr parameter and the max-time parameter are not present, then reliable transmission is performed as specified in [RFC4960]. 6.6.1 Offerer Processing of the SDP Answer immediately re-uses the SCTP stream: Don't you need to wait until the stream reset procedure is finished? 6.2. Negotiating Data Channel Parameters so Both MUST NOT be present -> so both MUST NOT be present General 'a SDP' versus 'an SDP'