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

[Ben Campbell <[e-mail]>]

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