Subject: [clue] Ben Campbell's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Nov 2018 10:26:52 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-clue-signaling-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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"?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Nov 2018 14:34:21 -0500

> non-CLUE device? Is this a realistic use case? (I'm not saying it's not; I'm

If the non-clue device is audio-only then you will get an audio call. If 
it is an audio/video device then you will get a basic audio/video call.

This can be entirely reasonable. For instance, if you have a 
clue-capable device on your desktop, you can use it for all of your 
calls. If the call is being originated from a clue-based conference 
room, inviting multiple clients, somebody in their car can be included 
in the call.

>   guidance one way or the other.)

This doesn't have to be from a prior session. The initial call may be an 
offerless invite (e.g., from a 3pcc controller). If the caller indicates 
support for clue then the callee can respond with an offer of a clue 
session.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Nov 2018 13:39:27 -0600

> On Nov 20, 2018, at 1:34 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> If the non-clue device is audio-only then you will get an audio call. If it is an audio/video device then you will get a basic audio/video call.
> 
> This can be entirely reasonable. For instance, if you have a clue-capable device on your desktop, you can use it for all of your calls. If the call is being originated from a clue-based conference room, inviting multiple clients, somebody in their car can be included in the call.

Okay, that makes sense. I wasn’t thinking about “desktop” CLUE devices, I guess.

> This doesn't have to be from a prior session. The initial call may be an offerless invite (e.g., from a 3pcc controller). If the caller indicates support for clue then the callee can respond with an offer of a clue session.
> 

To be clear, I was wondering if remembering past sessions was an _additional_ way to “know” a peer is clue capable. In particular, if it’s not a good idea it would be worth mentioning that, because I suspect implementors might get creative in that particular direction.

Thanks!

Ben.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Nov 2018 15:15:15 -0500

> To be clear, I was wondering if remembering past sessions was an _additional_ way to “know” a peer is clue capable. In particular, if it’s not a good idea it would be worth mentioning that, because…

There isn't any real harm in doing this. The worse that will happen is 
that the clue stuff is included in the offer and then rejected in the 
answer. So I have no problem with implementors getting "creative" here.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Nov 2018 14:19:19 -0600

> On Nov 20, 2018, at 2:15 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> There isn't any real harm in doing this. The worse that will happen is that the clue stuff is included in the offer and then rejected in the answer. So I have no problem with implementors getting "creative" here.

Okay. I am fine leaving things as is, unless the authors see value in mentioning the possibility.