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.

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.