I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication. It's well written, and, while I have a few minor comments, they are only of the most minor sort. -- Section 3.1 -- As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams realizing a WebRTC data channel must be associated with the same SCTP association. In addition, both SCTP streams realizing the WebRTC data channel must use the same SCTP stream identifier value. These rules also apply to a CLUE data channel. I don't know that it matters a lot, but this seems to be an odd way of saying that because a CLUE data channel is a WebRTC data channel, a CLUE data channel behaves like and has the same rules as a WebRTC data channel. I think I might word it more straightforwardly that way, something like this: NEW Because a CLUE data channel is a special case of a WebRTC data channel [I-D.ietf-rtcweb-data-channel], a CLUE data channel behaves like a WebRTC data channel and abides by the same rules. In particular, the SCTP streams realizing a WebRTC data channel must be associated with the same SCTP association, and both SCTP streams realizing the WebRTC data channel must use the same SCTP stream identifier value. END Worded that way, it also supports the many other times in the document that you point out things that rtcweb-data-channel says that affect CLUE data channel behaviour. But, as I said, I don't know that it matters a lot, so... just a suggestion. -- Section 3.2.3 -- I think I'd move (or copy) the citation of [I-D.ietf-clue-protocol] to Section 1, where "CLUE protocol" is first mentioned. -- Section 3.3.1.1 -- CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless it is known that UDP/DTLS/SCTP will not work Are there other reasons to transport over TCP other than "knowing that UDP/DTLS/SCTP will not work"? If so, OK. If not, then I think you really mean "MUST NOT ... unless ...." -- References -- I don't think RFC 3264 is normative. -- Barry