Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)
draft-ietf-clue-signaling-15

I skimmed the document and I trust Ben and Adam to catch various SIP/RTP related issues, if any.

I agree that draft-ietf-rtcweb-data-channel should be a normative reference.

Thanks for the work on this. I have some substantive and editorial comments:

*** Substantive Comments ***

§2: Is there a reason not to use the new (preferred) boilerplate from RFC 8174? There are a lot of lower case instances of "must" and "should". These are ambiguous under the old boilerplate.

§4.4.1.1: "Each <encID> (in encodingIDList) in a CLUE ADVERTISEMENT message
SHOULD represent an Encoding defined in SDP..."

I started out asking why this was not a MUST. But after reading the discussion in §5.1 and elsewhere, I think the issue is too nuanced to be conveyed by a single normative keyword. Perhaps this should say something to the effect of "SHOULD converge to representing...". Or even "will eventually represent...but may not match for short time after encoding changes..."  (The same applies to the SHOULD in the following paragraph.)

§4.5.1: 

- What sort of user experience is expected when a CLUE device talks to a non-CLUE device? Is this a realistic use case? (I'm not saying it's not; I'm just asking.)

- "If the device has evidence that the receiver is also CLUE-capable,
for instance due to receiving an initial INVITE with no SDP but
including a "sip.clue" media feature tag,"

 Is it reasonable to remember CLUE support from previous sessions? I suspect the answer is  "no", due to SIP forking issues, but I think it's worth guidance one way or the other.)

§5.1: "A device with the CLUE Participant state machine in the ACTIVE state
MAY choose not to move from ESTABLISHED to ADV (Media Provider state
machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media 
Consumer state machine) based on the SDP state."

 I'm not sure what that means. Is the specific SDP state a reason for skipping the state transition specified in due-protocol? or is it saying that an endpoint can choose not to let SDP state trigger a CLUE state change when it normally would?


*** Editorial Comments ***

- General: This document does not follow the protocol draft's convention for naming message types. For example, this draft refers to ADVERTISEMENT while the protocol draft says  'advertisement'  (in single quotes). I don't have strong feelings which to use, but the two should be consistent.

§5: Is "CLUE channel" the same as the datachannel that carries the CLUE protocol?

§5.1: "Because of the constraints of SDP offer/answer and because new SDP
negotiations are generally more ’costly’ than sending a new CLUE
message..."
Why the 'scare quotes' around "costly"?

Thank you for resolving my Discuss (and comment!) points!
I assume the RFC Editor will fix the s/cdata hannel/data channel/.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4099



COMMENTS
S 12.
>      via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines.  All CLUE-
>      controlled RTP "m" lines must be secured and implemented using
>      mechanisms such as SRTP [RFC3711].  CLUE implementations MAY choose
>      not to require the use of SRTP to secure legacy (non-CLUE-controlled)
>      media for backwards compatibility with older SIP clients that are
>      incapable of supporting it.

It seems like you need more than support, you also need to require the
use of DTLS-SRTP, no?

I agree with Benjamin Kaduk's comment about considering whether draft-ietf-rtcweb-data-channel should be a normative reference for at least clue-signaling, but it's worth noting that draft-ietf-rtcweb-data-channel is a C238 draft in Missref at the RFC Editor, and was approved about the same time that DTLS 1.2 was published. I'm hoping that there's no reason to look at C238 drafts when we're doing IESG Evaluation for drafts that refer to them (directly or indirectly), but thought I should ask before CLUE comes out as RFCs.