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