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

From: Paul Kyzivat <[email-masked]>
Date: Sun, 27 Oct 2013 12:47:20 -0400

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"

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

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

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.

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.

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.

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.

	Thanks,
	Paul (as individual)