Source: http://sandbox.ietf.org/doc/draft-ietf-clue-signaling/ballotpopup/629928/
Timestamp: 2019-01-24 04:10:20
Document Index: 130318718

Matched Legal Cases: ['§2', '§4', '§5', '§4', '§5', '§5', '§5']

Ballot for draft-ietf-clue-signaling
Discuss (2018-11-19)
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 1.3.6.1.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.
Comment (2018-11-19)
Please consider using the RFC 8174 version of the BCP 14 boilerplate.
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"?
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 4.4.1.1
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.
[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 4.5.2.2
(Also in 4.4.1.1) 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 4.5.4.2
group then the call is now CLUE-enabled; negotiation of the data
channel and subsequently the CLUE protocol begin.
nit: begins
Section 4.5.4.4
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.)
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"?
: 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
I guess technically this also doesn't require that he CONFIGURE parsed
correctly and was accepted, which is arguably a bug.
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
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?
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?
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.
Comment (2018-11-20)
Thanks for the work on this. I have some substantive and editorial 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
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?
- 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
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.
Comment (2018-11-21)
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.
https://mozphab-ietf.devsvcdev.mozaws.net/D4099
>      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?