Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11

From: "Rob Hansen (rohanse2)" <[email-masked]>
Date: Mon, 21 Aug 2017 02:40:27 +0000

Hi Adam,

Thanks again for the very detailed review. In most cases I've incorporated your suggestions straightforwardedly. There are a few that may warrant further discussion in the group as a whole though, though, or where I've failed to find something in the protocol document.

Section 4.5.4.3: "Note that this is distinct from cases where the CLUE protocol negotiation fails, or an error occurs in the CLUE protocol; see [I-D.ietf-clue-protocol] for details of media and state preservation in this circumstance." -- I carefully scrubbed the CLUE protocol document to try to determine what this is referring to. Please change it to "see [I-D.ietf-clue-protocol] section X.Y.Z", but replacing "X.Y.Z" with the section that provides the details you allude to.

[Rob] I believe when I wrote this the plan was that call preservation actions in the event of a protocol error/failure would be addressed as part of the protocol document, but that this section had not yet been written, and that remains the case. Simon, is this something you have planned, or can you point me at the relevant section?

BLOCKER: Compare the normative statements in paragraph 2 of Section 5.3:

    Generally, implementations that receive messages for which they have
    incomplete information SHOULD wait until they have the corresponding
    information they lack before sending messages to make changes related
    to that information.  For example, an answerer that receives a new
    SDP offer with three new "a=sendonly" CLUE "m=" lines for which it
    has received no CLUE Advertisement providing the corresponding
    capture information SHOULD include corresponding "a=inactive" lines
    in its answer, and SHOULD make a new SDP offer with "a=recvonly" when
    and if a new Advertisement arrives with Captures relevant to those
    Encodings.

With the normative statements in section 4.5.2.2:

    If the initial offer contained "a=recvonly" CLUE-controlled media
    lines the recipient SHOULD include corresponding "a=sendonly" CLUE-
    controlled media lines for accepted Encodings
    ...
    If the initial offer contained "a=sendonly" CLUE-controlled media
    lines the recipient MAY include corresponding "a=recvonly" CLUE-
    controlled media lines

5.3 says "SHOULD set a=inactive" in the exact same circumstances 4.5.2.2 says "SHOULD set a=sendonly". Please pick one expected behavior and make sure both sections agree. Ideally, you would refactor this so that the normative statement is made in only one location.

[Rob] I don't think these sections are in conflict - the quoted paragraph from section 5.3 is referring to cases where the SDP offer includes "a=sendonly" lines, whereas the section in 4.5.2.2 saying "SHOULD set a=sendonly" is talking about that the SDP *answer* including "a=sendonly" lines in response to the offerer's "a=recvonly" lines. It's the paragraph below that corresponds to the quoted 5.3 paragraph, which says that the SDP *answer* MAY include "a=recvonly" in its response or "MAY" wait, and then references section 5.3, which is where the quoted paragraph with recommendation that implementations should wait and send a subsequent SDP is included. We ended up with this approach because, even though in most cases implementations should wait until they receive the information about the encodings and their contents via the CLUE channel, there are some valid use-cases where implementations will know this up-front and hence can avoid the need for multiple SDP exchanges.

General, but surfaced in section 8: The procedures described in this document virtually guarantee that every CLUE call that is established will result in glare (response code 491) behavior. This might cause the operations folks some heartburn, as it means that their error counts will spike once CLUE is deployed. Further, without fairly advanced analysis of the callflow, this will make it impossible to distinguish "expected" CLUE-induced 491s from the oddball actual glare conditions usually signaled by 491. Has any consideration been given to avoiding this situation (e.g., by having the called party wait on the order of one second before attempting to negotiate its encodings)?

[Rob] I definitely agree that glare is much more likely at the start of a CLUE call. There was quite a bit of discussion in the group on the pros and cons of introducing an asymmetry into the call messaging to avoid (or reduce the frequency) of glare, and how best to do so, but the final conclusion in the end was not to do so and to rely on SIP's mechanisms to resolve it.

Section 10: It is rather unusual to include authors in the acknowledgements section. For each of Rob Hansen, Paul Kyzivat, and Christian Groves, I suggest removing the individual's name from either the Acknowledgements section or from the authors list.

[Rob] The authors list hasn't really been updated since the initial stages. Looking at other docs like the framework one I can see they've been revised a fair bit. For now I've left the authors as-is and removed the duplicate names from the acknowledgements, but will reach out to Paul and Roni for guidance here.

Section 8: "In this case Bob is the Channel Initiator..." this isn't clear (and, in fact, it's counterintuitive to me) -- perhaps there should be some text indicating *why* Bob is the Channel Initiator.

[Rob] I've made explicit that, when the SCTP over DTLS channel is negotiated, Bob ends up the client and hence the Channel Initiator. However, when I went to double-check that that was how the initiator role was assigned, I can't actually find anything in the protocol or datachannel document that defines who ends up with the Initiator role. That definitely seems like something that we need to fix... (unless I've just failing to find it). Simon, is this something you're planning to address?

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: 03 June 2017 01:15
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AD Review: draft-ietf-clue-signaling-11

CLUE working group --

I have completed my AD review for the CLUE signaling document. The document is generally in good shape, but I think we'll need another revision before putting it in front of the IETF for last call (especially due to the apparent incomplete removal of support for specifying multiple CLUE groups per session).

Most of my comments below are feedback that the document authors should treat as normal last call comments. The feedback that I consider to block progressing the document, in my role as AD, is explicitly marked with the prefix "BLOCKER", and these will need to be resolved in a new version of the document before progressing it further. Note that it is entirely possible that something I have marked "BLOCKER" may stem from an error on my part; so recognize that these are not demands for change, as much as a need to have things either fixed in the document or explained to me.

Title: The rule of thumb is that all but a small handful of well-known acronyms need to be expanded in titles and abstracts. I recognize that "CLUE" is a bit tortured, as acronyms go, but the title of this document is, broadly speaking, opaque. Please change it to something meaningful, such as "Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)"

BLOCKER: General: It is clear from reading this version of the document that earlier versions contained the notion of multiple "a=group:CLUE" 
lines in a single SDP description. This version appears to have tried to remove all related text, but there are still enough mentions that talk about CLUE groups in a way that implies that there can be multiples so as to cause confusion. These need to be cleaned up. I call the specific instances out on a section-by-section basis below. I'm mentioning it up here since it's really only one blocker issue with a bunch of instances.

General: The _protocol_ document has a host of different terms for each kind of CLUE message (e.g., "ADVERTISEMENT," "ADV," and "advertisement" 
for the same operation). This document exacerbates the situation by introducing yet more variations, such as "Advertisement" and "Configure". Please coordinate with draft-ietf-clue-protocol to use a consistent set of names for these operations between the two documents.

Introduction: The convention I see in this document is to write defined terms with initial caps; please replace "encoding group" with "Encoding Group."

Section 3: Please add a reference to RFC3840 (e.g.: 'The "sip.clue" 
media feature tag [RFC3840] indicates...")

Section 4.2: "Presence of the data channel in a CLUE group..." implies there can be more than one group. Replace "a" with "the."

Section 4.3: ...its "mid" value MUST be included in a CLUE group' 
implies there can be more than one group. Replace "a" with "the."

Section 4.4.1: "...in a CLUE group as defined above." implies there can be more than one group. Replace "a" with "the."

Section 4.4.1: '..."m=" lines in the same CLUE group in the SDP message...' very strongly implies there can be more than one group. 
Rephrase, perhaps along the lines of "...CLUE-controlled "m=" lines in the SDP message..."

4.4.2: 'These "m=" lines are CLUE-controlled and hence MUST include their "mid" in the CLUE group corresponding to the CLUE group of the Encoding they wish to receive.' is getting pretty explicit about the presence of multiple CLUE groups. Fix.

4.5.2.1, first sentence: Replace "If the recipient is a CLUE-capable..." 
with "If the recipient of an offer is a CLUE-capable..."

BLOCKER: Section 4.5.2.2: For avoidance of doubt, this section should clearly indicate what the answer should do with CLUE-controlled lines that it has no intention of receiving (for sendonly) or sending (for recvonly). I believe the expectation here is to set the port to zero (rather than, e.g., setting the direction to inactive). The document should explicitly state this behavior: if implementations make different choices between port-zero and inactive and don't expect the other behavior, you can end up with incompatibilities.

Section 4.5.3.1, paragraph 2: My recollection is that telling implementors not to send media is frequently misinterpreted to mean that they don't have to send/receive RTCP either. This causes all kinds of grief. It will probably head off issues if this section is phrased more like "...MAY choose not to send RTP on the non-CLUE-controlled channels (although RTCP is still sent and received as normal) during the period..."

Section 4.5.4.1: 'Subsequent offer/answer exchanges MAY add additional "m=" lines...' -- this should probably also mention "and activate inactive ones."

Section 4.5.4.1: 'Subsequent offer/answer exchanges MAY also deactivate "m=" lines for CLUE-controlled media.' -- again, the interpretation of "deactivate" may be different between implementors. Please be clear about whether this means "a=inactive", port=0, or both.

Section 4.5.4.1: The final paragraph talks about "deactivating" non-CLUE media. Again, this should be explicit about what is meant.

Section 4.5.4.2: 'If, in an ongoing non-CLUE call, an SDP offer/answer exchange completes with both sides having included a data channel "m=" 
line in their SDP and with the "mid" for that channel in corresponding CLUE groups..." implies that there can be more than one CLUE group. Fix.

Section 4.5.4.3: "...include the data channel in a matching CLUE group..." implies there can be more than one group. Replace "a matching" 
with "the."

Section 4.5.4.3: "Any active "m=" lines still included in a CLUE group..." implies there can be more than one group. Replace "a" with "the."

Section 4.5.4.3: "Note that this is distinct from cases where the CLUE protocol negotiation fails, or an error occurs in the CLUE protocol; see [I-D.ietf-clue-protocol] for details of media and state preservation in this circumstance." -- I carefully scrubbed the CLUE protocol document to try to determine what this is referring to. Please change it to "see [I-D.ietf-clue-protocol] section X.Y.Z", but replacing "X.Y.Z" with the section that provides the details you allude to.

BLOCKER: Compare the normative statements in paragraph 2 of Section 5.3:

    Generally, implementations that receive messages for which they have
    incomplete information SHOULD wait until they have the corresponding
    information they lack before sending messages to make changes related
    to that information.  For example, an answerer that receives a new
    SDP offer with three new "a=sendonly" CLUE "m=" lines for which it
    has received no CLUE Advertisement providing the corresponding
    capture information SHOULD include corresponding "a=inactive" lines
    in its answer, and SHOULD make a new SDP offer with "a=recvonly" when
    and if a new Advertisement arrives with Captures relevant to those
    Encodings.

With the normative statements in section 4.5.2.2:

    If the initial offer contained "a=recvonly" CLUE-controlled media
    lines the recipient SHOULD include corresponding "a=sendonly" CLUE-
    controlled media lines for accepted Encodings
    ...
    If the initial offer contained "a=sendonly" CLUE-controlled media
    lines the recipient MAY include corresponding "a=recvonly" CLUE-
    controlled media lines

5.3 says "SHOULD set a=inactive" in the exact same circumstances 4.5.2.2 says "SHOULD set a=sendonly". Please pick one expected behavior and make sure both sections agree. Ideally, you would refactor this so that the normative statement is made in only one location.

Section 7 appears to be oddly silent on the use of RTCP MUX. I suspect that the intention is that CLUE will generally multiplex RTCP when using BUNDLE? I would expect this to be called out.

Section 7 offers that the use of BUNDLE has the advantage of reducing the number of ICE candidates that need to be collected. This is true only in the case that some m= section are marked as bundle-only; this, in turn, implies that a bundled offer is going to contain one or more m= sections that will fail if the remote endpoint does not implement BUNDLE. This interacts particularly badly with the text in section 4.5.1 that allows, under certain circumstances, that 'the initial offer MAY contain "m=" lines for CLUE-controlled media.', since you can end up with the whole CLUE session falling apart if the bundle-only lines are not chosen carefully. This is a relatively complicated issue that I wouldn't expect impementors to get correct without some guidance on the use of bundle-only, and in particular its interaction with CLUE-controlled lines. Please add text to Section 7 that discusses these issues.

Section 8: Please insert a page break before the ladder diagram so that the entity names don't appear on a page by themselves.

Section 8: "In this case Bob is the Channel Initiator..." this isn't clear (and, in fact, it's counterintuitive to me) -- perhaps there should be some text indicating *why* Bob is the Channel Initiator.

General, but surfaced in section 8: The procedures described in this document virtually guarantee that every CLUE call that is established will result in glare (response code 491) behavior. This might cause the operations folks some heartburn, as it means that their error counts will spike once CLUE is deployed. Further, without fairly advanced analysis of the callflow, this will make it impossible to distinguish "expected" CLUE-induced 491s from the oddball actual glare conditions usually signaled by 491. Has any consideration been given to avoiding this situation (e.g., by having the called party wait on the order of one second before attempting to negotiate its encodings)?

Section 8 contains the following text:

    Bob also sends his SDP answer as part of SIP 200 OK 2.  Alongside his
    original audio, video and CLUE "m=" lines he includes two active
    recvonly "m= "lines and a zeroed "m=" line for the third.

This should probably be qualified to indicate that these are the same m-sections as were present in the offer (as opposed to creating new sections).

Section 8: Replace "Having received this Alice..." with "Having received this offer, Alice..."

Section 9: "From the lack of the data channel and grouping framework..." 
-- it should be noted that implementations that end up in communication with normal non-CLUE WebRTC implementations might get a datachannel but no CLUE group. The quoted text implies that the presence or absence of a datachannel can be used to determine CLUE support, which might cause implementors to rely on that exclusively. Please change the text to indicate that the CLUE group should be used as the sole determinant of CLUE support (at least, as far as SDP signaling is concerned).

Section 10: It is rather unusual to include authors in the acknowledgements section. For each of Rob Hansen, Paul Kyzivat, and Christian Groves, I suggest removing the individual's name from either the Acknowledgements section or from the authors list.

Section 11.2: "This specification registers a new media feature tag in the SIP [RFC3264] tree..." This should cite RFC3261 for SIP rather than RFC3264.

Section 11.2: Please indicate "[email-masked]" as the contact for this registration.

BLOCKING: Section 12 indicates that no security mechanisms are mandatory 
to use "due to the issues addressed in [RFC7202]." This vastly 
misconstrues the intent and text of RFC7202, which (roughly speaking) 
says "we don't mandate security for RTP in general because it is used in 
a vast and varied array of applications." CLUE is a very specific, very 
narrow application of RTP that does not suffer from the generality that 
makes a one-size-fits-all solution for RTP infeasible. In fact, RFC7202 
is quite clear that its guidance applies exclusively to RTP, and not to 
protocols that *use* RTP: "Documents that define an interoperable class 
of applications using RTP are subject to [RFC3365], and thus need to 
specify MTI security mechanisms." If there are specific arguments put 
forth in RFC7202 that the working group believes also apply to this 
document, please reiterate them here. The current citation to RFC7202 is 
problematic, though, since it says the opposite of what this security 
section implies.

If I understand it correctly, though, the argument to put forth here is 
that implementations MAY choose not to secure legacy 
(non-CLUE-controlled) media lines because SIP was specified prior to 
RFC3365, and was therefore not bound by its requirements; and, as a 
consequence, many existing SIP endpoints are incapable of using 
DTLS-SRTP. This rationale is orthogonal to the guidance in RFC7202, and 
should not cite it.

The use of "DTLS" to refer to "DTLS-SRTP" is also confusing, as they are 
different things.

I propose changing the paragraph as follows:

    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.  As specified in
    [I-D.ietf-clue-framework], all CLUE-controlled RTP streams 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 SRTP.

Section 12: "To prevent this, SIP signaling SHOULD always be encrypted 
using TLS..." While I agree with the statement, I think it's a bit 
outside the purview of this document to specify this. Suggest: "...SIP 
signaling used to set up CLUE sessions SHOULD..."

/a

---

From: Roni Even <[email-masked]>
Date: Thu, 24 Aug 2017 12:53:35 +0000

Hi Rob,
Read your response looks good to me and agree with your analysis
As for section 4.5.4.3 I think that section 6 of the protocol with the state machine is the right reference
Roni

> From: clue [mailto:[email-masked]] On Behalf Of Rob Hansen
> (rohanse2)
> Sent: יום ב 21 אוגוסט 2017 05:40
> To: Adam Roach; [email-masked]
> Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11
> 
> Hi Adam,
> 
> Thanks again for the very detailed review. In most cases I've incorporated
> your suggestions straightforwardedly. There are a few that may warrant
> further discussion in the group as a whole though, though, or where I've
> failed to find something in the protocol document.
> 
> 
> Section 4.5.4.3: "Note that this is distinct from cases where the CLUE protocol
> negotiation fails, or an error occurs in the CLUE protocol; see [I-D.ietf-clue-
> protocol] for details of media and state preservation in this circumstance." -- I
> carefully scrubbed the CLUE protocol document to try to determine what this
> is referring to. Please change it to "see [I-D.ietf-clue-protocol] section X.Y.Z",
> but replacing "X.Y.Z" with the section that provides the details you allude to.
> 
> [Rob] I believe when I wrote this the plan was that call preservation actions in
> the event of a protocol error/failure would be addressed as part of the
> protocol document, but that this section had not yet been written, and that
> remains the case. Simon, is this something you have planned, or can you
> point me at the relevant section?

> 5.3 says "SHOULD set a=inactive" in the exact same circumstances 4.5.2.2
> says "SHOULD set a=sendonly". Please pick one expected behavior and make
> sure both sections agree. Ideally, you would refactor this so that the
> normative statement is made in only one location.
> 
> [Rob] I don't think these sections are in conflict - the quoted paragraph from
> section 5.3 is referring to cases where the SDP offer includes "a=sendonly"
> lines, whereas the section in 4.5.2.2 saying "SHOULD set a=sendonly" is
> talking about that the SDP *answer* including "a=sendonly" lines in response
> to the offerer's "a=recvonly" lines. It's the paragraph below that corresponds
> to the quoted 5.3 paragraph, which says that the SDP *answer* MAY include
> "a=recvonly" in its response or "MAY" wait, and then references section 5.3,
> which is where the quoted paragraph with recommendation that
> implementations should wait and send a subsequent SDP is included. We
> ended up with this approach because, even though in most cases
> implementations should wait until they receive the information about the
> encodings and their contents via the CLUE channel, there are some valid use-
> cases where implementations will know this up-front and hence can avoid
> the need for multiple SDP exchanges.
> 
> 
> General, but surfaced in section 8: The procedures described in this
> document virtually guarantee that every CLUE call that is established will
> result in glare (response code 491) behavior. This might cause the operations
> folks some heartburn, as it means that their error counts will spike once CLUE
> is deployed. Further, without fairly advanced analysis of the callflow, this will
> make it impossible to distinguish "expected" CLUE-induced 491s from the
> oddball actual glare conditions usually signaled by 491. Has any consideration
> been given to avoiding this situation (e.g., by having the called party wait on
> the order of one second before attempting to negotiate its encodings)?
> 
> [Rob] I definitely agree that glare is much more likely at the start of a CLUE
> call. There was quite a bit of discussion in the group on the pros and cons of
> introducing an asymmetry into the call messaging to avoid (or reduce the
> frequency) of glare, and how best to do so, but the final conclusion in the
> end was not to do so and to rely on SIP's mechanisms to resolve it.
> 
> 
> Section 10: It is rather unusual to include authors in the acknowledgements
> section. For each of Rob Hansen, Paul Kyzivat, and Christian Groves, I suggest
> removing the individual's name from either the Acknowledgements section
> or from the authors list.
> 
> [Rob] The authors list hasn't really been updated since the initial stages.
> Looking at other docs like the framework one I can see they've been revised
> a fair bit. For now I've left the authors as-is and removed the duplicate
> names from the acknowledgements, but will reach out to Paul and Roni for
> guidance here.
> 
> 
> Section 8: "In this case Bob is the Channel Initiator..." this isn't clear (and, in
> fact, it's counterintuitive to me) -- perhaps there should be some text
> indicating *why* Bob is the Channel Initiator.
> 
> [Rob] I've made explicit that, when the SCTP over DTLS channel is negotiated,
> Bob ends up the client and hence the Channel Initiator. However, when I
> went to double-check that that was how the initiator role was assigned, I
> can't actually find anything in the protocol or datachannel document that
> defines who ends up with the Initiator role. That definitely seems like
> something that we need to fix... (unless I've just failing to find it). Simon, is
> this something you're planning to address?
> 
> 
> 
> I have completed my AD review for the CLUE signaling document. The
> document is generally in good shape, but I think we'll need another revision
> before putting it in front of the IETF for last call (especially due to the
> apparent incomplete removal of support for specifying multiple CLUE groups
> per session).
> 
> Most of my comments below are feedback that the document authors
> should treat as normal last call comments. The feedback that I consider to
> block progressing the document, in my role as AD, is explicitly marked with
> the prefix "BLOCKER", and these will need to be resolved in a new version of
> the document before progressing it further. Note that it is entirely possible
> that something I have marked "BLOCKER" may stem from an error on my
> part; so recognize that these are not demands for change, as much as a need
> to have things either fixed in the document or explained to me.
> 
> Title: The rule of thumb is that all but a small handful of well-known acronyms
> need to be expanded in titles and abstracts. I recognize that "CLUE" is a bit
> tortured, as acronyms go, but the title of this document is, broadly speaking,
> opaque. Please change it to something meaningful, such as "Session Signaling
> for Controlling Multiple Streams for Telepresence (CLUE)"
> 
> BLOCKER: General: It is clear from reading this version of the document that
> earlier versions contained the notion of multiple "a=group:CLUE"
> lines in a single SDP description. This version appears to have tried to remove
> all related text, but there are still enough mentions that talk about CLUE
> groups in a way that implies that there can be multiples so as to cause
> confusion. These need to be cleaned up. I call the specific instances out on a
> section-by-section basis below. I'm mentioning it up here since it's really only
> one blocker issue with a bunch of instances.
> 
> General: The _protocol_ document has a host of different terms for each
> kind of CLUE message (e.g., "ADVERTISEMENT," "ADV," and "advertisement"
> for the same operation). This document exacerbates the situation by
> introducing yet more variations, such as "Advertisement" and "Configure".
> Please coordinate with draft-ietf-clue-protocol to use a consistent set of
> names for these operations between the two documents.
> 
> Introduction: The convention I see in this document is to write defined terms
> with initial caps; please replace "encoding group" with "Encoding Group."
> 
> Section 4.2: "Presence of the data channel in a CLUE group..." implies there
> can be more than one group. Replace "a" with "the."
> 
> Section 4.4.1: "...in a CLUE group as defined above." implies there can be
> more than one group. Replace "a" with "the."
> 
> Section 4.4.1: '..."m=" lines in the same CLUE group in the SDP message...'
> very strongly implies there can be more than one group.
> 4.4.2: 'These "m=" lines are CLUE-controlled and hence MUST include their
> "mid" in the CLUE group corresponding to the CLUE group of the Encoding
> they wish to receive.' is getting pretty explicit about the presence of multiple
> CLUE groups. Fix.
> 
> BLOCKER: Section 4.5.2.2: For avoidance of doubt, this section should clearly
> indicate what the answer should do with CLUE-controlled lines that it has no
> intention of receiving (for sendonly) or sending (for recvonly). I believe the
> expectation here is to set the port to zero (rather than, e.g., setting the
> direction to inactive). The document should explicitly state this behavior: if
> implementations make different choices between port-zero and inactive and
> don't expect the other behavior, you can end up with incompatibilities.
> 
> Section 4.5.3.1, paragraph 2: My recollection is that telling implementors not
> to send media is frequently misinterpreted to mean that they don't have to
> send/receive RTCP either. This causes all kinds of grief. It will probably head
> off issues if this section is phrased more like "...MAY choose not to send RTP
> on the non-CLUE-controlled channels (although RTCP is still sent and received
> as normal) during the period..."
> 
> Section 4.5.4.1: 'Subsequent offer/answer exchanges MAY add additional
> "m=" lines...' -- this should probably also mention "and activate inactive
> ones."
> 
> Section 4.5.4.1: 'Subsequent offer/answer exchanges MAY also deactivate
> "m=" lines for CLUE-controlled media.' -- again, the interpretation of
> "deactivate" may be different between implementors. Please be clear about
> whether this means "a=inactive", port=0, or both.
> 
> Section 4.5.4.1: The final paragraph talks about "deactivating" non-CLUE
> media. Again, this should be explicit about what is meant.
> 
> Section 4.5.4.2: 'If, in an ongoing non-CLUE call, an SDP offer/answer
> exchange completes with both sides having included a data channel "m="
> line in their SDP and with the "mid" for that channel in corresponding CLUE
> groups..." implies that there can be more than one CLUE group. Fix.
> 
> Section 4.5.4.3: "...include the data channel in a matching CLUE group..."
> implies there can be more than one group. Replace "a matching"
> with "the."
> 
> Section 4.5.4.3: "Any active "m=" lines still included in a CLUE group..." implies
> there can be more than one group. Replace "a" with "the."
> 
> Section 4.5.4.3: "Note that this is distinct from cases where the CLUE protocol
> negotiation fails, or an error occurs in the CLUE protocol; see [I-D.ietf-clue-
> protocol] for details of media and state preservation in this circumstance." -- I
> carefully scrubbed the CLUE protocol document to try to determine what this
> is referring to. Please change it to "see [I-D.ietf-clue-protocol] section X.Y.Z",
> but replacing "X.Y.Z" with the section that provides the details you allude to.
> 
> 
> 5.3 says "SHOULD set a=inactive" in the exact same circumstances 4.5.2.2
> says "SHOULD set a=sendonly". Please pick one expected behavior and make
> sure both sections agree. Ideally, you would refactor this so that the
> normative statement is made in only one location.
> 
> 
> Section 7 appears to be oddly silent on the use of RTCP MUX. I suspect that
> the intention is that CLUE will generally multiplex RTCP when using BUNDLE? I
> would expect this to be called out.
> 
> Section 7 offers that the use of BUNDLE has the advantage of reducing the
> number of ICE candidates that need to be collected. This is true only in the
> case that some m= section are marked as bundle-only; this, in turn, implies
> that a bundled offer is going to contain one or more m= sections that will fail
> if the remote endpoint does not implement BUNDLE. This interacts
> particularly badly with the text in section 4.5.1 that allows, under certain
> circumstances, that 'the initial offer MAY contain "m=" lines for CLUE-
> controlled media.', since you can end up with the whole CLUE session falling
> apart if the bundle-only lines are not chosen carefully. This is a relatively
> complicated issue that I wouldn't expect impementors to get correct without
> some guidance on the use of bundle-only, and in particular its interaction
> with CLUE-controlled lines. Please add text to Section 7 that discusses these
> issues.
> 
> Section 8: Please insert a page break before the ladder diagram so that the
> entity names don't appear on a page by themselves.
> 
> Section 8: "In this case Bob is the Channel Initiator..." this isn't clear (and, in
> fact, it's counterintuitive to me) -- perhaps there should be some text
> indicating *why* Bob is the Channel Initiator.
> 
> General, but surfaced in section 8: The procedures described in this
> document virtually guarantee that every CLUE call that is established will
> result in glare (response code 491) behavior. This might cause the operations
> folks some heartburn, as it means that their error counts will spike once CLUE
> is deployed. Further, without fairly advanced analysis of the callflow, this will
> make it impossible to distinguish "expected" CLUE-induced 491s from the
> oddball actual glare conditions usually signaled by 491. Has any consideration
> been given to avoiding this situation (e.g., by having the called party wait on
> the order of one second before attempting to negotiate its encodings)?
> 
> 
> This should probably be qualified to indicate that these are the same m-
> sections as were present in the offer (as opposed to creating new sections).
> 
> 
> -- it should be noted that implementations that end up in communication
> with normal non-CLUE WebRTC implementations might get a datachannel
> but no CLUE group. The quoted text implies that the presence or absence of
> a datachannel can be used to determine CLUE support, which might cause
> implementors to rely on that exclusively. Please change the text to indicate
> that the CLUE group should be used as the sole determinant of CLUE support
> (at least, as far as SDP signaling is concerned).
> 
> Section 10: It is rather unusual to include authors in the acknowledgements
> section. For each of Rob Hansen, Paul Kyzivat, and Christian Groves, I suggest
> removing the individual's name from either the Acknowledgements section
> or from the authors list.
> 
> Section 11.2: "This specification registers a new media feature tag in the SIP
> [RFC3264] tree..." This should cite RFC3261 for SIP rather than RFC3264.
> 
> to use "due to the issues addressed in [RFC7202]." This vastly misconstrues
> the intent and text of RFC7202, which (roughly speaking) says "we don't
> mandate security for RTP in general because it is used in a vast and varied
> array of applications." CLUE is a very specific, very narrow application of RTP
> that does not suffer from the generality that makes a one-size-fits-all
> solution for RTP infeasible. In fact, RFC7202 is quite clear that its guidance
> applies exclusively to RTP, and not to protocols that *use* RTP: "Documents
> that define an interoperable class of applications using RTP are subject to
> [RFC3365], and thus need to specify MTI security mechanisms." If there are
> specific arguments put forth in RFC7202 that the working group believes also
> apply to this document, please reiterate them here. The current citation to
> RFC7202 is problematic, though, since it says the opposite of what this
> security section implies.
> 
> If I understand it correctly, though, the argument to put forth here is that
> implementations MAY choose not to secure legacy
> consequence, many existing SIP endpoints are incapable of using DTLS-SRTP.
> This rationale is orthogonal to the guidance in RFC7202, and should not cite it.
> 
> Section 12: "To prevent this, SIP signaling SHOULD always be encrypted using
> TLS..." While I agree with the statement, I think it's a bit outside the purview
> of this document to specify this. Suggest: "...SIP signaling used to set up CLUE
> sessions SHOULD..."
> 
> /a
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Aug 2017 14:21:44 -0500

> As for section 4.5.4.3 I think that section 6 of the protocol with the state machine is the right reference

I don't see anything in section 6 of -protocol (or the state machine it 
contains) dealing with "media preservation" or "state preservation" in 
the face of CLUE protocol negotiation failures or errors. I agree that 
this would be a good place to discuss such things, but right now, it 
appears to be left ambiguous whether (e.g.) a CLUE setup failure has any 
impact on the media.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Aug 2017 19:29:33 -0500

Thanks! Responses inline.

> [Rob] I believe when I wrote this the plan was that call preservation actions in the event of a protocol error/failure would be addressed as part of the protocol document, but that this section had…

Simon is on vacation for (I think) at least another week or so; but I 
agree that this may need some coordination. See also my earlier response 
to Roni.

> [Rob] I don't think these sections are in conflict - the quoted paragraph from section 5.3 is referring to cases where the SDP offer includes "a=sendonly" lines, whereas the section in 4.5.2.2 sayi…

Ah, okay. I see what you're getting at here. I think the problem, then, 
is that the language in 5.3 isn't really normative per se (or, rather, 
it shouldn't be normative), as much as it is illustrative. (This is 
reinforced by the phrasing "For example...") I would propose:

     For example, an answerer that receives a new
     SDP offer with three new "a=sendonly" CLUE "m=" lines for which it
     has received no CLUE Advertisement providing the corresponding
     capture information would typically include corresponding "a=inactive"
     lines in its answer, and make a new SDP offer with "a=recvonly" only
     when and if a new Advertisement arrives with Captures relevant to
     those Encodings.

> [Rob] I definitely agree that glare is much more likely at the start of a CLUE call. There was quite a bit of discussion in the group on the pros and cons of introducing an asymmetry into the call…

Sure. What I'd like to have positive confirmation on is: did the working 
group specifically consider the operational aspects of this decision? I 
agree that it works from a protocol perspective. I'm just worried that 
it will give operators unnecessary difficulty.

> [Rob] The authors list hasn't really been updated since the initial stages. Looking at other docs like the framework one I can see they've been revised a fair bit. For now I've left the authors as-…

Thanks. Either resolution makes sense to me, and I suspect that the 
current author list is correct.

> [Rob] I've made explicit that, when the SCTP over DTLS channel is negotiated, Bob ends up the client and hence the Channel Initiator. However, when I went to double-check that that was how the init…

The reason this seems counter-intuitve to me is that it is backwards 
from how RTCWEB (JSEP) works in the general case. To be clear, for 
datachannels, the TLS client is selected by the "a=setup" attribute; and 
JSEP implementations are required (MUST) to put "a=setup:actpass" in 
their offers, and expected (SHOULD) to put "a=setup:active" in their 
answers. The rationale here is: the way ICE ends up working, the 
answerer will have the first opportunity to send a packet, so this 
reduces overall setup time by ~1/2-RTT.

Of course, CLUE is free to do this however it wants [1]; but doing it 
opposite from RTCWEB is likely to confuse people beyond just me. I think 
you'd also need a reasonably good rationale, as a naïve analysis of CLUE 
is that doing it the way you currently have in your examples is 
generally going to impose an additional 1/2-RTT delay on datachannel 
establishment. But I freely admit that I haven't spent a lot of time 
thinking about the low-level details, and could be overlooking something.

/a

____
[1] Subject to the constraints in 
<https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-11>, sections 10 
- 11

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Aug 2017 10:29:43 -0400

> thinking about the low-level details, and could be overlooking something.

It does seem to me that this needs to be carefully aligned with RTCWEB 
because one of our goals was that interoperation with RTCWEB be 
possible. (That is why we chose data channels in the first place.)

	Thanks,
	Paul