Subject: Re: [clue] comments on draft-ietf-clue-framework-12

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 1 Nov 2013 06:59:45 -0700

Hi Paul,
Thanks for the feedback. I particularly appreciate feedback on the topic of normative language and RFC 2119 keywords, because this area is new to me.
My comments inline below.
I'd like to see Stephan's comments too, as he made most of the updates related to the RFC 2119 keywords.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Sunday, October 27, 2013 12:47 PM
> To: CLUE
> Subject: [clue] comments on draft-ietf-clue-framework-12
> 
> While preparing for the meeting I reviewed the framework document again.
> I have a number of comments. These are all quite detail-oriented, rather
> than conceptual. I see no reason to discuss these at the meeting - it should
> be possible to deal with them all via email.
> 
> General observation: This version introduced a lot of new normative
> language. While some of it seems appropriate, some is not. Normative
> language should only be used for things that are actionable. I'll call out the
> specific points where I see this below.
> 
> 
> Section 5 says:
> 
>     This CLUE exchange MUST be followed by an SDP offer answer exchange
>     that not only establishes those aspects of the media that have not
>     been "negotiated" over CLUE, but has also the side effect of
>     setting up the media transmission itself, involving potentially
>     security exchanges, ICE, and whatnot.
> 
> I think this is a bit too strong. While it is *likely* that another O/A exchange
> will be needed, I don't think it is mandatory. If it turns out that the SDP
> already in effect is sufficient, then no new O/A is needed.
> A degenerate case of this is when nothing is configured.
> 
> I suggest replacing "MUST be" by "will usually be"

[Duckworth, Mark] That seems okay to me.

> Later in the section:
> 
>     For example, voice-activated screen switching, signaled over the
>     CLUE channel, ought not to lead to heavy-handed mechanisms like SIP
>     re-invites.  However, in other cases, after the CLUE negotiation an
>     additional offer/answer exchange becomes necessary.  For example,
>     if both sides decide to upgrade the call from a single screen to a
>     multi-screen call and more bandwidth is required for the additional
>     video channels compared to what was previously negotiated using
>     offer/answer, a new O/A exchange is REQUIRED.
> 
> This seems fine except that the normative language is inappropriate.
> There is nothing normative here. The new O/A exchange is triggered by
> circumstances, not rules. So I suggest simply reverting the change from
> -11 to -12 that introduced "REQUIRED".

[Duckworth, Mark] That seems okay to me.

> Later in the section:
> 
>     The operation of the renderer
>     inside the Consumer is unspecified in that it can choose to ignore
>     some information provided by the Provider, and/or not render media
>     streams available from the Provider (although it MUST follow the
>     CLUE protocol and, therefore, MUST gracefully receive and respond
>     (through a Configure) to the Provider's information).  All CLUE
>     protocol mechanisms are OPTIONAL in the Consumer in the sense that,
>     while the Consumer MUST be able to receive (and, potentially,
>     gracefully acknowledge) CLUE messages, it is free to ignore the
>     information provided therein.  Obviously, this is not a
>     particularly sensible design choice in almost all conceivable
>     cases.
> 
> IIUC it's still not settled whether a Configure MUST be sent in response to an
> Advertisement. So "(although it MUST ..." is suspect. It can be left for now,
> but may need to be updated later. Or we could just remove it now. I also
> question the use of OPTIONAL in the normative sense. If something is to be
> said about that, it might be something about "mandatory to implement,
> optional to use".

[Duckworth, Mark] "MUST follow the CLUE protocol" seems correct, but maybe redundant. I agree we are not sure yet if that means is must send a configure msg, so that might have to change.
Your suggestion "mandatory to implement, optional to use" might be a better way of stating the intent of the second sentence in the paragraph.

> Still later:
> 
>     A CLUE-implementing device interoperates with a device that does
>     not support CLUE, because the non-CLUE device does, by definition,
>     not understand the offer of a CLUE channel in the initial
>     offer/answer exchange and, therefore, will reject it. This
>     rejection MUST be used as the indication to the CLUE-implementing
>     device that the other side of the communication is not compliant
>     with CLUE, and to fall back to behavior that does not require CLUE.
> 
> Again, the MUST seems inappropriate. It is not something that needs to be
> dictated. The CLUE device has no option to follow CLUE in this case.

[Duckworth, Mark] That seems okay to me.

> Section 6:
> 
>     o  Coordinates can either be in real, physical units (millimeters),
>        have an unknown scale or have no physical scale.  Systems which
>        know their physical dimensions (for example professionally
>        installed Telepresence room systems) MUST always provide those
>        real-world measurements.  Systems which don't know specific
>        physical dimensions but still know relative distances MUST use
>        'unknown scale'.
> 
> I question "MUST" here. What bad things happen if the MUSTs are violated.
> Why not "SHOULD"? I guess it comes down to what it means for for a system
> to "know" something. I guess it would be possible for a system to "know"
> this but wish to hide that knowledge.

[Duckworth, Mark] Stephan said in general we should avoid using "SHOULD", so that's what we did. It's fine with me if we change this one to SHOULD or even MAY.

> ISTM what is key is that there are benefits to providing this information, and
> negative consequences (to interoperability) from not providing it. So one
> SHOULD provide this information unless the desire to hide it is more
> important than the potential value of providing it.
> 
> Section 7.3:
> 
>     If an Advertisement does not include Simultaneous Transmission
>     Sets, then the Provider MUST be able to provide all Capture Scenes
>     simultaneously.  If multiple capture Scene Entries are in a Capture
>     Scene then the Consumer chooses at most one Capture Scene Entry per
>     Capture Scene for each media type.
> 
> I'm not sure what this is trying to say. If I read the first sentence in the
> context with the prior paragraph I conclude that there is a default
> simultaneous set that lists all the scenes in the advertisement.
> 
> But when I read the 2nd sentence, then I conclude that something weaker is
> being implied - that by default simultaneity is required between any arbitrary
> choice of a single CSE from each scene.
> 
> If the latter is intended, then I think the point needs to be made more
> clearly. Perhaps the algorithm for defining the default simultaneous sets
> could be specified.

[Duckworth, Mark] Good point. The intent is the second thing you said. I'll make a note to clarify this in the next version.

> Section 10:
> 
>     For each Capture the Consumer wants to receive, it configures one
>     or more of the encodings in that capture's encoding group.  The
>     Consumer does this by telling the Provider, in its Configure
>     Message, parameters such as the resolution, frame rate, bandwidth,
>     etc. for each Capture Encodings for its chosen Captures.  Upon
>     receipt of this Configure from the Consumer, common knowledge is
>     established between Provider and Consumer regarding sensible
>     choices for the media streams and their parameters.  The setup of
>     the actual media channels, at least in the simplest case, is left
>     to a following offer-answer exchange.  Optimized implementations
>     MAY speed up the reaction to the offer-answer exchange by reserving
>     the resources at the time of finalization of the CLUE handshake.
> 
> I don't think this is accurate when Encodings are represented in SDP. I won't
> attempt to wordsmith a revision here - it may require a substantial rewrite.

[Duckworth, Mark] I think we should fix this paragraph after the protocol documents become more stable. I'll make a note of it.

> 	Thanks,
> 	Paul (as individual)