Subject: [clue] Comments on draft-ietf-clue-signaling-05

From: Christian Groves <[email-masked]>
Date: Tue, 17 Mar 2015 14:07:22 +1100

Hello Rob, all,

Here are my comments on the signalling draft:

Cl.1 2nd para: "As the CLUE Framework [I-D.ietf-clue-framework] defines 
a manner in which the media provider expresses their maximum encoding 
capabilities..." - Perhaps we need to clarify this as CLUE only 
indicates the maxgroup bandwidth?

Cl.4.1 2nd para: "Currently only support for a single CLUE group is 
specified." We should add "Offer or Answer" just to clarify the scope.

Cl.4.2 2nd para: "if a device wishes to use the CLUE protocol on the 
data channel it
    MUST include a CLUE group in the SDP and include the "mid" of the "m"
    line for the data channel in that group." I thought we agreed that 
this wouldn't be the case and instead the use of 
draft-ietf-mmusic-data-channel-sdpneg-01 would indicate the use of CLUE 
in the datachannel?

Cl.4.4.1 para 4: "...specifying <that> the capture <is> to be used..."

Cl.4.4.1.2 para 2: "If a device does not feel there is...",  Perhaps we 
should remove "feel", I don't think AI has come so far that CLUE devices 
will have feelings? :-) We could simplify "If there is no benefit to...".

Cl.4.5.2.1 and Cl.4.5.3: This needs to be updated based on my comment on 
Cl.4.2 above.

Cl.4.5.3.1 para 3: " If either side of the call wishes to add additional 
CLUE-controlled "m" line<s> to..." Missing <s>

Cl.4.5.4.2 para 1: "A CLUE-capable device that receives an initial SDP 
offer from a non-CLUE device SHOULD include a new data channel "m" line 
and corresponding CLUE group in any subsequent offers it sends, to 
indicate that it is CLUE-capable." why is this a should? If the sender 
doesn't give any indication that it supports CLUE why would the receiver 
offer a data channel?

Cl.4.5.4.3 para 1: Again the text would need to be updated based on Cl.4.2.

Cl.4.5.4: I think we need some more focus on release on CLUE controlled 
media/CLUE data channel. For example:
A media provider could simply remove the CLUE data channel by sending an 
SCTP reset on the CLUE data channel. Is this enough to indicate 
disabling CLUE? Must a SDP O/A precede this? Should the media provider 
send an updated Advertisement removing the captures before sending the 
SDP O/A removing the CLUE channel? Should it stop sending media before 
this?

Cl.5.1 para 4: "The current state of the CLUE participant or CLUE media 
provider/
    consumer state machines" I suggest slightly different wording to 
make it clear we're talking about the CLUE participant's state, i.e. 
"The current state of the CLUE participant <and its> CLUE media 
provider/consumer state machines..."

Cl.5.1 para 6: These states don't match the current protocol version 
draft-ietf-clue-protocol-03

Cl.7.2.1: Spelling "generarlly" + I don't understand the second sentence 
as written. Seems like it needs to be broken up.

Cl.7.2.3: The reference to section 7.2 of the BUNDLE draft doesn't seem 
valid. 9.2?

Cl.8 1st para under figure. Change we change "basilar" to "basic"?

Cl.8 and 9: The text needs to be updated to incorporate 
draft-ietf-mmusic-data-channel-sdpneg-01 and also to align with the 
latest ietf-mmusic-sctp-sdp. i.e. a=sctp-port<:>5000, <UDP>/DTLS/SCTP etc.

Cl.10: Is this still an open issue? I think we can close this.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Mar 2015 10:44:42 -0400

On 3/16/15 11:07 PM, Christian Groves wrote:

> disabling CLUE?

Since reset is also used in the case of errors, IMO receiving one should 
not be considered an indication of a desire cease use of clue. Rather I 
think that should be signaled in a more explicit manner, via a new O/A 
that rejects the clue channel.

> Must a SDP O/A precede this?

Precede or follow? If we said that an *intention* to cease clue use be 
signaled first in SDP, then the reset that follows will be known to not 
signal an error. If the reset comes first, then it is ambiguous whether 
it is an error that will be corrected, or intentional.

> Should the media provider
> SDP O/A removing the CLUE channel?

I don't think it matters. Once clue use ends you can assume there is no 
valid advertisement.

> Should it stop sending media before
> this?

I don't think it makes sense to enforce hard ordering here. There are 
unavoidable race conditions.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 Mar 2015 10:51:52 +1100

Hello Paul,

Please see below.

Regards, Christian

On 18/03/2015 1:44 AM, Paul Kyzivat wrote:
> Since reset is also used in the case of errors, IMO receiving one 
> should not be considered an indication of a desire cease use of clue. 
> Rather I think that should be signaled in a more explicit manner, via 
> a new O/A that rejects the clue channel.
[CNG] I agree. I think it would be good to document this.

> signaled first in SDP, then the reset that follows will be known to 
> not signal an error. If the reset comes first, then it is ambiguous 
> whether it is an error that will be corrected, or intentional.
[CNG] In the normal release case I think that it should precede. That 
seems to be the approach in draft-ietf-mmusic-msrp-usage-data-channel 
and draft-ietf-mmusic-data-channel-sdpneg. We should be consistent with 
these drafts.

> I don't think it matters. Once clue use ends you can assume there is 
> no valid advertisement.
[CNG] I agree and again I think it would be good to cover this aspect in 
the draft.
> unavoidable race conditions.
[CNG] I don't think we can enforce hard ordering due to error conditions 
etc. however I do think it is worthwhile to outline a recommended normal 
release sequence.
>
>     Thanks,
>     Paul
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Rob Hansen (rohanse2)" <[email-masked]>
Date: Mon, 23 Mar 2015 01:41:17 +0000

Hi Paul, Christian,

See inline.

Rob

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 17 March 2015 23:52
To: [email-masked]
Subject: Re: [clue] Comments on draft-ietf-clue-signaling-05

Hello Paul,

Please see below.

Regards, Christian

On 18/03/2015 1:44 AM, Paul Kyzivat wrote:
>> Cl.4.5.4: I think we need some more focus on release on CLUE 
>> controlled media/CLUE data channel. For example:
>> A media provider could simply remove the CLUE data channel by sending 
>> an SCTP reset on the CLUE data channel. Is this enough to indicate 
>> disabling CLUE?
>

[Rob] Section 4.5.4.3 seeks to address this; do you think more detail is needed or is what is present sufficient?
[Rob] Makes sense.
[CNG] I agree and again I think it would be good to cover this aspect in 
the draft.
[Rob] Section 4.5.4.3 defines that once the SDP negotiation completes the call is no longer CLUE enabled, all CLUE-controlled media must stop and no more CLUE messages can be sent. Do you think that's sufficient, or do you think additional detail is needed?
[CNG] I don't think we can enforce hard ordering due to error conditions 
etc. however I do think it is worthwhile to outline a recommended normal 
release sequence.
[Rob] It's analogous to removing an m-line, whether there's a similar race condition on whether the updated SDP is handled first or the media is stopped first. Is there a recommended order for that? Currently the behaviour of the CLUE media is undefined until the SDP completes; could definitely add something recommending what the sender does during this period.

---

From: Christian Groves <[email-masked]>
Date: Tue, 24 Mar 2015 11:31:26 +1100

Hello Rob,

Please see my replies below.

Regards, Christian

> [Rob] Section 4.5.4.3 seeks to address this; do you think more detail is needed or is what is present sufficient?
[CNG] Section 4.5.4.3 doesn't cover the SCTP reset aspect. I guess i'd 
prefer to see a reformulation of the section as its written from the 
perspective that disabling CLUE is a by product. I'd prefer it to be 
more prescriptive. Something along the lines of:
"To release a CLUE session the endpoint:
- may send an updated Advertisement indicating that the captures are no 
longer available
- shall send an updated SDP O/A removing followed by a SSN reset to 
close the CLUE data channel according to section 
5.2.4/[draft-ietf-mmusic-data-channel-sdpneg-01].
- upon channel closure shall stop transmission of CLUE controlled media.
etc.

> [Rob] It's analogous to removing an m-line, whether there's a similar race condition on whether the updated SDP is handled first or the media is stopped first. Is there a recommended order for that…
[CNG] OK