Subject: Re: [clue] WGLC of CLUE Framework now started - my comments

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Dec 2014 15:22:30 -0500

I reviewed the -19 version front to back, with the exception of the 
examples in section 12. Here are the things I noted along the way:

Nit: Section 4 is "Overview & Motivation", and section 5 is "Overview of 
the Framework/Model". It seems odd to have two overviews. Perhaps 
section 5 could be "Description of the Framework/Model".

Section 3:

    The terms defined below are used throughout this document and
    companion documents and they are normative.

What does it mean for this terminology to be normative? We do have 
normative language that uses these terms, but then it is that language 
that is normative, not the term definitions.

    CLUE-capable device: A device that supports the CLUE data channel
    [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.ietf-clue-
    protocol] and the principles of CLUE negotiation, and wishes to
    upgrade the call to CLUE-enabled status.

I'm slightly bothered by "wishes to upgrade". That doesn't seem to 
include the case where the call is already CLUE-enabled. How about:

    CLUE-capable device: A device that supports the CLUE data channel
    [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.ietf-clue-
    protocol] and the principles of CLUE negotiation, and seeks
    CLUE-enabled calls.

In the def of Global View:

    Global View: A set of references to one or more Capture Scene Views
    of the same media type that are defined within scenes of the same
    advertisement.  A Global View is a suggestion from the Provider to
    the Consumer for which CSVs provide a complete representation of
    the simultaneous captures provided by the Provider, across multiple
    scenes.

I think a tweak to this might be clearer:

    Global View: A set of references to one or more Capture Scene Views
    of the same media type that are defined within scenes of the same
    advertisement.  A Global View is a suggestion from the Provider to
    the Consumer for one set of CSVs that provide a useful
    representation of all the scenes in the advertisement.

I think Plane of Interest:

    Plane of Interest: The spatial plane containing the most relevant
    subject matter.

can be further clarified. s/plane/plane within a scene/

Section 5:

I'm struggling to understand the following paragraph:

    Second, it MAY, but is not necessarily REQUIRED to, use the
    information provided to tailor the SDP it is going to send during
    the following SIP offer/answer exchange, and its reaction to SDP it
    receives in that step.  It is often a sensible implementation
    choice to do so, as the representation of the media information
    conveyed over the CLUE channel can dramatically cut down on the
    size of SDP messages used in the O/A exchange that follows.
    Spatial relationships associated with the Media can be included in
    the Advertisement, and it is often sensible for the Media Consumer
    to take those spatial relationships into account when tailoring the
    SDP.

This seems to me to say that the consumer can use the advertisement to 
reduce the size of the sdp, which isn't really true. I think the problem 
is that this text doesn't distinguish between what is done by providers 
and consumers.

For a provider, it may well be infeasible to send SDP covering every 
encoding in the advertisement. It could potentially reduce the size of 
SDP to a more manageable size by only offering those encodings that are 
configured. BUT, as we have things structured now a consumer needs to 
see the encodings in the SDP to decide what to configure. So this 
potential can't be realized.

For a consumer the potential is not to reduce the size of SDP, but 
rather to reduce the number of encodings it must set up resources to 
receive. It probably doesn't want to receive encodings that it doesn't 
intend to use. I think this is the key point to make in this paragraph.

(These comments also apply the the following paragraph.)

Section 6:

I think another bullet should be added to the beginning of the list:

o  Each scene has a distinct coordinate system, unrelated to the
    coordinate systems of other scenes.

Section 7.1.1.3:

It might be helpful to point out that typically a video capture 
represents a capture volume that is defined by a pyramid connecting the 
point of capture to the area of capture.

Section 7.2:

I find the following slightly confusing:

    The MCC indicates that one or more Single Media Captures are
    contained in one Media Capture.

I find "contained" a little vague. How about:

    The MCC indicates that one or more Single Media Captures are
    multiplexed (temporally and/or spatially) in one Media Capture.

Section 7.2.1.2:

    SoundLevel - This indicates that the content of the MCC is
    determined by a sound level detection algorithm. For example: the
    loudest (active) speaker is contained in the MCC.

I'm bothered by "For example". Does that mean some other algorithm might 
be used, for example the quietest capture? I don't think it is an 
example - it is part of the definition.

Section 7.2.1.3:

In Table 4 there are two Capture Scene #3s. I presume the latter one 
should be #5.

Section 9.3 says:

    Each Media Capture, including MCCs, MAY be associated with one or
    more Encoding Groups. To be eligible for configuration, a Media
    Capture MUST be associated with at least one Encoding Group, ...

Why does this say "or more"..."at least"???
IIUC it should say:

    Each Media Capture, including MCCs, MAY be associated with one
    Encoding Group. To be eligible for configuration, a Media
    Capture MUST be associated with an Encoding Group, ...

Section 10:

The following:

    A Configure Message does not include
    references to Capture Scenes or Capture Scene Views.

is *mostly* right. When configuring an MCC you can reference Capture 
Scenes and Scene Views as part of specifying a subset of the MCC captures.

Section 15:

    In
    addition, the media is based on RTP and thus existing RTP security
    mechanisms, such as DTLS/SRTP, MUST be supported.

I'm troubled by "such as ... MUST". I suggest:

    In
    addition, the media is based on RTP and thus existing RTP security
    mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported.

Then:

    defined in the
    CLUE data model [ref].

needs the reference filled in.

Also, in:

    Thus, this information SHOULD not be used to

should s/SHOULD not/SHOULD NOT/

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Tue, 16 Dec 2014 00:20:42 +0200

Hi Paul,

On your proposal 
"Section 15:

    In  addition, the media is based on RTP and thus existing RTP security
    mechanisms, such as DTLS/SRTP, MUST be supported.

    In   addition, the media is based on RTP and thus existing RTP security
    mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported"

I think that the current text is OK, we do not mandate a specific RTP
security mechanism maybe 
    In  addition, the media is based on RTP and thus existing RTP security
    Mechanisms see RFC7201 MUST be supported.

Roni

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 15 December, 2014 10:23 PM
> To: [email-masked]
> Subject: Re: [clue] WGLC of CLUE Framework now started - my comments
> 
examples in
> section 12. Here are the things I noted along the way:
> 
the
> Framework/Model". It seems odd to have two overviews. Perhaps section 5
> could be "Description of the Framework/Model".
> 
> Section 3:
> 
that is
> normative, not the term definitions.
> 
> I'm slightly bothered by "wishes to upgrade". That doesn't seem to include
the
> case where the call is already CLUE-enabled. How about:
> 
is that this
> text doesn't distinguish between what is done by providers and consumers.
> 
encoding in
> the advertisement. It could potentially reduce the size of SDP to a more
> manageable size by only offering those encodings that are configured. BUT,
as
> we have things structured now a consumer needs to see the encodings in the
> SDP to decide what to configure. So this potential can't be realized.
> 
> For a consumer the potential is not to reduce the size of SDP, but rather
to
> reduce the number of encodings it must set up resources to receive. It
probably
> doesn't want to receive encodings that it doesn't intend to use. I think
this is the
> key point to make in this paragraph.
> 
> It might be helpful to point out that typically a video capture represents
a
> capture volume that is defined by a pyramid connecting the point of
capture to
> the area of capture.
be
> used, for example the quietest capture? I don't think it is an example -
it is part
> of the definition.
should be
> #5.
Scenes
> and Scene Views as part of specifying a subset of the MCC captures.
> 
> Section 15:
> 
>     In
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Dec 2014 17:41:54 -0500

>      Mechanisms see RFC7201 MUST be supported.

RFC7201 is informational. I don't know what a requirement to support it 
means.

ISTM that we will have serious trouble in a security review if we don't 
make some specific mechanism MTI. That doesn't mean it is mandatory to 
use, but at least it will ensure an interoperable secure solution.

	Thanks,
	Paul