Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Section 11.2 of the IANA considerations lists an actual OID value to use for the "sip.clue" media feature tag, but the IANA last call review indicates that the decimal value for sip.clue will be assigned at registration, so it is incorrect to claim that it will be 188.8.131.52.8.4.29. Squatting on the next available codepoint like this is quite risky and I really want to discourage this practice. We had a lot of trouble in TLS recently with *three* different extensions attempting to use the same codepoint, which was not fun to resolve.
Please consider using the RFC 8174 version of the BCP 14 boilerplate. Section 3 The "sip.clue" media feature tag SIP [RFC3840] indicates support for CLUE in SIP [RFC3261] calls. nit: I think there's a missing word or three here; maybe "for SIP"? Section 4.3 The restrictions on CLUE-controlled media always apply to "m=" lines in an SDP offer or answer, even if negotiation of the data channel in [...] I'm not entirely sure I understand what "the restrictions" are, here. Unless this is supposed to just be the general requirements for how they are (not) sent? Section 184.108.40.206 Each <encID> (in encodingIDList) in a CLUE ADVERTISEMENT message SHOULD represent an Encoding defined in SDP; the specific Encoding referenced is a CLUE-controlled "m=" line in the most recent SDP sent ^^^^^^^^^^^^^^^ by the sender of the ADVERTISEMENT message with a label value corresponding to the text content of the <encID>. Is this "most recent SDP Offer/Answer"? (Similarly in the following paragraph.) I'm also not sure why these are SHOULD- instead of MUST-level requirements, modulo the non-atomicity mentioned in the final paragraph of the section. Section 4.5.1 [I will leave it to Adam to check that the "initial offer" terminology is being used in the consensus manner, since I haven't been tracking what manner that is.] Section 220.127.116.11 (Also in 18.104.22.168) Am I reading this correctly that with the initial offer, we are talking about negotiating media lines with labels that correspond to CLUE Encoding names that have not yet been present in any CLUE messages (that is, we're doing it "blind")? Section 22.214.171.124 group then the call is now CLUE-enabled; negotiation of the data channel and subsequently the CLUE protocol begin. nit: begins Section 126.96.36.199 o The CLUE protocol enters an unrecoverable error state as defined in Section 6. of [I-D.ietf-clue-protocol], either the 'MP- TERMINATED' state for the Media Provider or 'MC-TERMINATED' for the Media Consumer. The MP-TERMINATED and MC-TERMINATED states do not seem to exist in the -17 of the protocol document. (I'm assuming this is essentially editorial in nature and doesn't need to be part of the DISCUSS section.) Section 5.1 The primary implication of this is that a device may receive an SDP with a CLUE Encoding for which it does not yet have Capture [...] presumably this is "SDP Offer/Answer" as well? 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. [...] Is this "choose not to move", "choose to not move", or "chose whether or not to move"? Section 5.2 : an implementation MUST NOT send a specific CLUE Capture Encoding unless its most recent SDP exchange contains an active media channel for that Encoding AND the far end has sent a CLUE CONFIGURE message specifying a valid Capture for that Encoding. nit: "far end" is perhaps a bit informal; "peer" or "MC" might be alternatives. I guess technically this also doesn't require that he CONFIGURE parsed correctly and was accepted, which is arguably a bug. Section 8 With the successful initial SDP Offer/Answer exchange complete Alice and Bob are also free to negotiate the CLUE data channel. This is illustrated as CLUE DATA CHANNEL ESTABLISHED. Once the data channel is established CLUE protocol negotiation begins. In this case Bob chose to be the DTLS client (sending a=active in his SDP answer) and hence is the CLUE Channel Initiator and sends a CLUE OPTIONS message describing his version support. On receiving that message Alice sends her corresponding CLUE OPTIONS RESPONSE. My understanding was that the DTLS connection was a prerequisite for setting up the CLUE data channel (so I would have been less confused if the note about DTLS client was in the first paragraph). There are some instances of "CLUE channel" in this section that might be better as "CLUE data channel". Is it normal for the mid of the CLUE data channel to be changing around in the various SDP snippets shown in these examples? Section 12 This attack can be prevented by ensuring that the media recipient intends to receive the media packets. As such all CLUE-capable devices MUST support key negotiation and receiver intent assurance 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. Should these normative requirements be placed somewhere in the main body of this (or some other) document in addition to their necessity being described in the security considerations here? Section 14.2 Should-ietf-rtcweb-data-channel be a normative reference? (It seems like it should be so at least in draft-ietf-clue-datachannel, which is not on this week's telechat.) I think that RFC 3840 should be normative here, though, since you have to use it to enable CLUE. There's probably others, though I'd be inclined to consider at least the core SIP and SDP specs as "basic specifications" (per https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/) that do not need to be normative.
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. §188.8.131.52: "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"?
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.
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.
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?