Reviewer: Joerg Ott Review result: Almost Ready 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@xxxxxxxx if you reply to or forward this review. Please see the comments below. Best, Jörg Reviewing this document for tsv-art, I don't see any any transport-specific issues in the document, but a bunch of other (smaller) issues and nits came up. I am not sure that that the reference to a "SIP User Agent" as an entity is strictly correct here. SIP User Agents are defined in RFC 3261 to carry out SIP transactions. Just speaking about "User Agents" may be more accurate. But this is just a side note. Section 3.2.3 defines behaviour in a negative way, i.e., via MUST NOT statements, excluding all but one possibility. This could be problematic in the future if another option gets added to SCTP usage, which would then implicitly be allowed. It would be better if the behaviour was defined i a positive way, i.e., using MUST. Sect. 3.2.5, 2nd para: use "MUST" instead of "must" since this appears to be normative, so RFC 2119 wording should be used. Sect. 3.2.7, 1st para: this appears t be normative language and thus should use the RFC 2119 keywords. Sect. 3.3.1.1, table 1 + 2nd para after table 1: the text in the 2nd para defines the value for the "application usage"; this should also be reflected in table 1 since it seems that only one application usage is defined. Sect. 3.3.1.2.: this again appears to be normative, so RFC 2119 language should be used. What does the sentence "A CLUE entity can choose any valid SCTP port value." mean in this context? Is a "valid SCTP port" value that of a previously established SCTP connection within the context of the SIP session? If such a match is desired it should be specified or a reference to a peer document (draft-ietf-mmusic-sctp-sdp-26?) should be provided. Sect. 3.3.2: NOTE statement: It is ok to have a note but this still is somewhat normative. It should also be specified what happens if the values _are_ set by the peer. What is the error handling? Ignore? Reject the connection setup? Figure 1 is a nice example. But it would be even better if a complete example with the SDP for the data channel setup (in the previous or the same offer/answer exchange) be given. Makes life easier for readers and implementers. Editorial: Don't just copy the first paragraph(s) from the introduction to create an abstract. 3.2.2, 2nd para, 3rd line: "what" -> "which" Sect. 3.3.1: the ref to the clue-signalling draft is missing a link (all other refs have one). Fix the formatting of table 2 to avoid letter breaking from words.
