Subject: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt

From: Mary Barnes <[email-masked]>
Date: Fri, 6 Jun 2014 10:35:09 -0500

Hi all,

As discussed at the interim meeting, this is a two week pre-WGLC review for
the framework document:
http://www.ietf.org/id/draft-ietf-clue-framework-15.txt

The objective of this pre-WGLC review is for folks to take a fresh look at
the document and re-review the entire document. Right now, there are just a
couple outstanding issues:
- #35 (consistency with the data model document)
- audio issue (that still needs to be detailed by John Leslie)
- issues reflected by editor's notes in the document for which we will open
new tickets

This review is intended to ensure that there are no other outstanding
issues so that once we close the above open issues the document is ready
for WGLC.

Note, reviews that provide a general summary and then separate the major
and minor issues from the editorial nits, something like the following,
would be quite helpful.

Summary: (e.g., Needs Work, Almost Ready, Ready, etc)

Major issues:

Minor Issues:

Editorial nits:

Please review and send any comments to the mailing list no later than
Friday, June 20th, 2014.

Thanks,
Mary.

---

From: Christian Groves <[email-masked]>
Date: Tue, 17 Jun 2014 17:04:15 +1000

Hello,

In summary I think its fairly good although the audio issue is still a 
worry.

My comments:

Issues
=========
Cl.3 Advertisement: " the formatting of the media streams it can send" 
can probably be deleted as we removed the encoding information.

Cl.3 Capture Encoding: How critical is the use of RTP for a capture 
encoding? I would think anything defined to carry media would be 
appropriate, obviously RTP is the most used example. So perhaps we can 
change that to: ".... to a Media Consumer, e.g. via RTP."

Cl.3 Capture Scene: Is it really a region containing one or more capture 
devices? The scene may not actually contain the capture device. I would 
think it would be more appropriate to say something like "a structure 
representing the region captured by one or more media captures..."

Cl.3 General: Do we need a term to describe when multiple Capture Scenes 
are used to give an overall "picture" of the endpoint, i.e. GCSE?

Cl.3 Media Consumer/Media Provider - Should this say MCU?

Cl.3 Model: Is this definition needed or valid in the current CLUE 
framework? The use of "model" in the draft doesn't appear to reflect 
this definition.

Cl.3 Render: A rendered video may be as a result of multiple media. I 
propose "... a representation from media..."

Cl.3 Single Media Capture: "i.e. audio capture, video capture" don't 
really represent a single capture they represent a "single capture 
type". I think it would be more correct to say "i.e. an audio capture 
from a single microphone, a video capture from a single camera."

Cl.5 para.2: Rather than say "formatting of the media streams" it should 
say something like "media stream encodings"?

Cl.5 para.3: Is this really a MUST? It is conceivable that a CLUE 
channel is only established later in the call. Either we could have 
"SHOULD" or say something like "MUST occur when a CLUE channel is 
established in the call".

Cl.5 para.5: Is there a double definition of "media capture"? In this 
paragraph it says that a media capture describes the content. Whereas 
the definition in cl.3 says " Media Capture: a source of Media, such as 
from one or more Capture Devices or constructed from other Media 
streams." There's nothing about description of content here.

Cl.5 para.6: " A Consumer chooses which Media Captures it wants to 
receive from each Capture Scene." A Consumer doesn't have to choose any 
MCs from a scene. I'd suggested replace "each" with "the", i.e. 
"...receive from the Capture Scenes."

Cl.5 para.7 : "...media attributes of the Encodings" (and following 
text). This can be deleted as these are not contained in the 
Advertisement any more.

Cl.5 fig.1 : Does this need to be updated to remove maxBandWidth or at 
least move it to the encoding group level? Also does the global CSE need 
to be added as a box like the STS?

Cl.5 pg.13 para.1: "Voice Activated Stream Switching" via updated CLUE 
signalling is that something we've decided for CLUE?

Cl.5 pg.13 para.2: Do we need the sentence " Obviously, this is not a
    particularly sensible design choice in almost all conceivable
    cases."?

Cl.7.1.1.8 : There's the note regarding the different types of 
presentation. Is there any interest for values beyond "image" and "slides"?

Cl.7.3 para.6 & 7: Earlier in the draft it says that there is no spatial 
relationship between scenes. However this paragraph is a little "fuzzy" 
implying there may be relationship between scenes. Whilst physically 
there may a relationship a consumer has no way of knowing this. The 
default behaviour will not be to associate scenes.

Cl.9.1 para.3 : "The parameter of an Individual Encoding represent the 
maximum values", is this the case now? As the individual encoding 
parameter are now defined by SDP they could mean anything, not just 
maximum values. I think this paragraph needs to be updated to reflect this.

Cl.9.2: There is no explicit mention of whether individual encodings of 
multiple media types i.e. audio and video can belong to a single group.

Cl.10 para.2: I don't see the "special" handling outlined in this 
paragraph. A consumer would have a separate CLUE channel with each 
provider and treat the associations differently?

Cl.10 Pg.39 para.2: ", and includes the encoding parameter values" 
should be deleted. A configure doesn't respond with these values. Also 
in the paragraph below the text regarding parameters should be deleted also.

Cl.11 Para 1: Do we need the text about new industry and future 
directions? Can't we just mention how the framework is extensible?

Cl.11 bullet 3: New codecs should be added to SDP not CLUE. We could 
remove this bullet.

Cl.13 : How much do you have to input to get a mention? (hint)

Editorial
=========
General: I think the draft would read better if constructions such as 
"is sending" and "is receiving" are changed to "sends" and "receives", 
i.e. cl.4 para.2 "represents the entity that sends the media". "is not 
supporting" => "does not support"

General: Defined terms "Provider", "Advertisement" etc. should have 
there first character capitalized.

Cl.1 Para.1 : References to CLUE drafts can be updated to RFCs.

Cl.3 AudioCapture: ". Denoted as ACn in the examples in this document."

Cl.3 Font: "In going towards <the> back..."

Cl.4 (1): The first part of the sentence talks about the past, so I 
suggest changing "... for example, there was no mechanism..."

Cl.4 (2): Consistency "...are multiple capturing and rendering..." or 
"...are multiple capture and render..."

Cl.7.1.1 Para.1: "... for the benefit of the Consumer <of> the 
Advertisement message" or "A Provider can use the Media Capture 
Attributes in an Advertisement to describe the Capture for the benefit 
of the Consumer".

Cl.7.1.1.7 Reword " The Description attribute is a human-readable 
description (which could be in multiple languages) of the Capture." 
Otherwise it reads that the capture could be in multiple languages not 
the description. (Similar comment to cl.7.3.2)

Cl.8 Pg.33 Para.2 : "...are shown in Table 1" => "... are shown in Table 5."

Cl.9 "...please refer to section 4" => "...please refer to section 5"?

Cl.10 para.4: "As a general outline, <a> Consumer..."

Regards, Christian

On 7/06/2014 1:35 AM, Mary Barnes wrote:
> Hi all,
>
> As discussed at the interim meeting, this is a two week pre-WGLC 
> review for the framework document:
> The objective of this pre-WGLC review is for folks to take a fresh 
> look at the document and re-review the entire document. Right now, 
> there are just a couple outstanding issues:
> - issues reflected by editor's notes in the document for which we will 
> open new tickets
>
> issues so that once we close the above open issues the document is 
> ready for WGLC.
>
> Note, reviews that provide a general summary and then separate the 
> major and minor issues from the editorial nits, something like the 
> following, would be quite helpful.
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Mary Barnes <[email-masked]>
Date: Thu, 19 Jun 2014 09:11:08 -0500

Hi all,

Note that this pre-WGLC ends tomorrow. So far, we've only had one set of
review comments posted to the mailing list.

Mary.

On Fri, Jun 6, 2014 at 10:35 AM, Mary Barnes <[email-masked]>
wrote:

> Hi all,
>
> As discussed at the interim meeting, this is a two week pre-WGLC review
> for the framework document:

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 20 Jun 2014 11:37:35 -0700

Thanks Christian.

I agree with pretty much all this.  Later (next week I hope) I can give specific responses and suggestions for framework updates to address all these points.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Tuesday, June 17, 2014 3:04 AM
> To: [email-masked]
> Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt
> 
> Hello,
> 
> In summary I think its fairly good although the audio issue is still a worry.
> 
> My comments:
> 
> Issues
> =========
> Cl.3 Capture Encoding: How critical is the use of RTP for a capture encoding? I
> would think anything defined to carry media would be appropriate, obviously
> RTP is the most used example. So perhaps we can change that to: ".... to a
> Media Consumer, e.g. via RTP."
> 
> Cl.3 Model: Is this definition needed or valid in the current CLUE framework?
> The use of "model" in the draft doesn't appear to reflect this definition.
> 
> Cl.3 Single Media Capture: "i.e. audio capture, video capture" don't really
> represent a single capture they represent a "single capture type". I think it
> would be more correct to say "i.e. an audio capture from a single
> microphone, a video capture from a single camera."
> 
> Cl.5 para.2: Rather than say "formatting of the media streams" it should say
> something like "media stream encodings"?
> 
> Cl.5 para.3: Is this really a MUST? It is conceivable that a CLUE channel is only
> established later in the call. Either we could have "SHOULD" or say something
> like "MUST occur when a CLUE channel is established in the call".
> 
> Cl.5 para.5: Is there a double definition of "media capture"? In this paragraph
> it says that a media capture describes the content. Whereas the definition in
> cl.3 says " Media Capture: a source of Media, such as from one or more
> Capture Devices or constructed from other Media streams." There's nothing
> about description of content here.
> 
> Cl.5 para.6: " A Consumer chooses which Media Captures it wants to receive
> from each Capture Scene." A Consumer doesn't have to choose any MCs
> from a scene. I'd suggested replace "each" with "the", i.e.
> Cl.5 para.7 : "...media attributes of the Encodings" (and following text). This
> can be deleted as these are not contained in the Advertisement any more.
> 
> Cl.5 fig.1 : Does this need to be updated to remove maxBandWidth or at least
> move it to the encoding group level? Also does the global CSE need to be
> added as a box like the STS?
> 
> Cl.7.1.1.8 : There's the note regarding the different types of presentation. Is
> there any interest for values beyond "image" and "slides"?
> 
> Cl.7.3 para.6 & 7: Earlier in the draft it says that there is no spatial relationship
> between scenes. However this paragraph is a little "fuzzy"
> implying there may be relationship between scenes. Whilst physically there
> may a relationship a consumer has no way of knowing this. The default
> behaviour will not be to associate scenes.
> 
> Cl.10 para.2: I don't see the "special" handling outlined in this paragraph. A
> consumer would have a separate CLUE channel with each provider and treat
> the associations differently?
> 
> should be deleted. A configure doesn't respond with these values. Also in
> the paragraph below the text regarding parameters should be deleted also.
> 
> Cl.11 Para 1: Do we need the text about new industry and future directions?
> Can't we just mention how the framework is extensible?
> 
> General: I think the draft would read better if constructions such as "is
> sending" and "is receiving" are changed to "sends" and "receives", i.e. cl.4
> para.2 "represents the entity that sends the media". "is not supporting" =>
> "does not support"
> 
> General: Defined terms "Provider", "Advertisement" etc. should have there
> first character capitalized.
> 
> Cl.4 (1): The first part of the sentence talks about the past, so I suggest
> changing "... for example, there was no mechanism..."
> 
> Cl.4 (2): Consistency "...are multiple capturing and rendering..." or "...are
> multiple capture and render..."
> 
> Cl.7.1.1 Para.1: "... for the benefit of the Consumer <of> the Advertisement
> message" or "A Provider can use the Media Capture Attributes in an
> Advertisement to describe the Capture for the benefit of the Consumer".
> 
> Cl.7.1.1.7 Reword " The Description attribute is a human-readable description
> (which could be in multiple languages) of the Capture."
> Otherwise it reads that the capture could be in multiple languages not the
> description. (Similar comment to cl.7.3.2)
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 26 Jun 2014 13:22:23 -0700

Hi Christian,
Thanks for the detailed review.  Responses inline.

I plan to submit the next framework draft revision tomorrow, as I will be on vacation all next week.

Mark

> In summary I think its fairly good although the audio issue is still a worry.
[Duckworth, Mark] I think we worked that out, according to recent discussion on the list that confirms Paul Coverdale's proposal is the right way to go.

> can probably be deleted as we removed the encoding information.
[Duckworth, Mark] I agree

> Media Consumer, e.g. via RTP."
[Duckworth, Mark] I thought the scope was limited to RTP.  If Paul and Mary agree that RTP should be just an example here, that is okay with me.

> representing the region captured by one or more media captures..."
[Duckworth, Mark] I agree

> are used to give an overall "picture" of the endpoint, i.e. GCSE?
[Duckworth, Mark] I don't think we need a new term in section 3.

> Cl.3 Media Consumer/Media Provider - Should this say MCU?
[Duckworth, Mark] I think MCU is a type of middle box.  This is described in section 4.  I don't think this definition needs to change.

> The use of "model" in the draft doesn't appear to reflect this definition.
[Duckworth, Mark] I suggest we remove this definition.

> propose "... a representation from media..."
[Duckworth, Mark] I agree

> microphone, a video capture from a single camera."
[Duckworth, Mark] ok

> something like "media stream encodings"?
[Duckworth, Mark] I agree

> like "MUST occur when a CLUE channel is established in the call".
[Duckworth, Mark] How about replace "MUST" with "typically"?

> about description of content here.
[Duckworth, Mark] how about "A Media Capture (MC), such as audio or video, has attributes to describe the content a Provider can send."

> "...receive from the Capture Scenes."
[Duckworth, Mark] I agree

> can be deleted as these are not contained in the Advertisement any more.
[Duckworth, Mark] I agree.  The next paragraph also has "maximum video coding performance measured in macroblocks/second", which I think should also be removed.

> added as a box like the STS?
[Duckworth, Mark] Yes, I agree

> signalling is that something we've decided for CLUE?
[Duckworth, Mark] I think the refers to the case where a Consumer can send a new configure message asking for a different video capture using an already defined encoding from SDP, without needing another SDP O/A because nothing changes at the SDP level.  If the consumer makes this choice based on audio information, that could be "voice activated screen switching"

>     particularly sensible design choice in almost all conceivable
[Duckworth, Mark] I don't mind removing this.  Does anybody else think it should remain?

> there any interest for values beyond "image" and "slides"?
[Duckworth, Mark] in the data model, there should be a way to extend presentationType with more values.  I don't know how this is done in XML to be backward compatible.

> behaviour will not be to associate scenes.
[Duckworth, Mark] I don't see anything that implies a relationship between scenes.  Which sentences specifically do you mean?

> maximum values. I think this paragraph needs to be updated to reflect this.
[Duckworth, Mark] I think this whole paragraph should be deleted.

> multiple media types i.e. audio and video can belong to a single group.
[Duckworth, Mark] The data model restricts an encoding group to a particular media type.

> the associations differently?
[Duckworth, Mark] I don't understand your point.  Do you think this paragraph is unnecessary?
 
> the paragraph below the text regarding parameters should be deleted also.
[Duckworth, Mark] I agree

> Can't we just mention how the framework is extensible?
[Duckworth, Mark] I agree we could remove that sentence.

> Cl.11 bullet 3: New codecs should be added to SDP not CLUE. We could
[Duckworth, Mark] I agree

> Cl.13 : How much do you have to input to get a mention? (hint)
[Duckworth, Mark] I've been meaning to update this section

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Jun 2014 20:22:52 -0400

I apologize for being late with my own pre-WGLC review comments on this. 
I ended up spending a lot more time on it than I allotted. (And I 
procrastinated.) Also, I know there are some overlaps between my 
comments and Christians. I've left them in because it is easier than 
removing them and I may have some different nuances.

And here I am speaking as an individual, not a chair.

References:

There is no separate section for References. They are found at the end 
of the "Changes since last version" section. I assume this is a bug.

Section 1:

In the following:

    The signaling details and data model are provided
    in subsequent documents.

ISTM that the documents aren't "subsequent", in that there is no natural 
ordering relationship among them. I suggest "separate" (or "companion") 
documents. E.g.,

    Companion documents describe signaling details [reference] and
    the data model. [reference]

(These documents aren't currently in the references.)

Section 3:

Re Capture Device:

    Capture Device: A device that converts audio and video input into
    an electrical signal, in most cases to be fed into a media encoder.

This definition only applies to audio and video. (E.g., it excludes 
real-time text.) The grouping taxonomy defines it as:

    a physical entity performing a Media Capture transformation.

Re Capture Encoding:

Can we relate this directly to the grouping taxonomy? The taxonomy 
already does so, saying it is

    a term to describe an Encoded Stream

I'm not certain this is quite right - I think the description is of more 
than the Encoded stream - maybe a "Source RTP Stream". Whatever we 
decide, we should ensure that the fw and the taxonomy are updated to be 
consistent.

Re Endpoint: I think we could align better with the taxonomy. (We are 
pretty close.)

Re Front:

    Front: the portion of the room closest to the cameras.  In going
    towards back you move away from the cameras.

Do we need this? It is only referenced once, in the definition of 
spatial relationships.

Also, unless all the cameras are placed on the same side of the room it 
is not unique. (There is a separate Front for each camera.)

Re MCU:

The taxonomy now has what seems to be a good definition of MCU. Can we 
refer to that one? We may have to specialize the definition for our 
purposes - requiring that it support CLUE. (That might mean we need to 
have a different name, such as CLUE MCU.)

Re Media Capture:

Our definition differs from the taxonomy in a significant way. Ours 
describes it as a form of "data" while the taxonomy describes it as a 
process. I'm not quite sure what to recommend for aligning these. I 
suspect one or the other needs to be renamed.

Re Media Consumer:

    Media Consumer: an Endpoint or middle box that receives Media
    streams

I think "Media Streams" is too general here. I suggest:

    Media Consumer: an Endpoint or middle box that is capable of
    receiving Media Encodings.

Re Media Provider:

Similar to above I suggest:

    Media Provider: an Endpoint or middle box that is capable of
    sending Media Encodings.

Re Multiple Content Capture:

This is limited to audio and video. Couldn't we potentially have an MCC 
for switched or mixed real-time text? How about:

    Multiple Content Capture: A Capture that mixes and/or switches
    other Captures of a single type. (E.g. all audio or all video.)
    Particular Media Captures may or may not be present in the
    resultant Capture Encoding depending on time or space.  Denoted as
    MCCn in the example cases in this document.

Instead of just mentioning that MCCn may be used in examples, shouldn't 
we actually define MCC as an abbreviation?

Re Stream:

Can we relate this to the taxonomy? I think this corresponds to both a 
"Source RTP Stream" and a "Received RTP Stream".

Re Middlebox:

This term isn't defined but it is used. I think it deserves a definition.

Section 4:

The following:

    ... In a few circumstances, a CLUE Endpoint middlebox
    includes only Consumer or Provider functionality, such as
    recorder-type Consumers or webcam-type Providers. ...

I *think* this should say "Endpoint *or* middlebox".

Section 5:

The following:

    This Advertisement and Configure MUST occur during call initiation
    but MAY also happen at any time throughout the call, whenever there
    is a change in what the Consumer wants to receive or (perhaps less
    common) the Provider can send.

seems overly restrictive. This need not occur during *call* initiation. 
It is possible to initiate a call, but not enable clue until later. How 
about:

    This Advertisement and Configure MUST occur once use of CLUE has
    been enabled in a call, but MAY also happen at any time throughout
    the call, whenever there is a change in what the Consumer wants to
    receive or (perhaps less common) the Provider can send.

Figure 1 doesn't include the Global Capture Scene Entry List.

Section 6 says:

    X increases from Camera-Left to Camera-Right
    Y increases from front to back

(Also see my comment on the definition of "Front".)

Defining the coordinates relative to a camera is problematic since there 
can be multiple cameras. (Consider case where we have cameras facing the 
audience and others facing speakers in front of the audience.)

I'm not sure we can say anything better than that the X,Y coordinates 
should be chosen to be sensible for the set of captures to be offered. 
Perhaps an example where all the cameras point in generally the same 
direction would get the point across.

Section 7.1.1:

Isn't mono/stereo now gone as a capture attribute?

Section 7.1.1.2:

Perhaps we should say that the Point on Line of Capture actually defines 
not just the axis, but a vector indicating the direction of capture?

Section 7.1.1.3:

I guess some restructuring is needed to limit area of capture to video.

Section 7.1.1.5:

Didn't we agree to remove this. (That it will be handled as part of an 
encoding.)

Section 7.2.1.2:

The explanation of 'index' is pretty fuzzy. ISTM that the meaning really 
needs to be specified separately for each token. E.g., for SoundLevel N 
means the N'th most recent loudest speaker. For RoundRobin it is harder 
to describe.

Section 7.2.1.3:

I have read this several times, and while I know this is about site 
switching I cannot figure it out from the words written here. Even the 
example isn't helping me (and I don't think it should take an example to 
make it understandable.)

For instance, ISTM that the synchronization id and the policy can give 
conflicting criteria for what is included at each point in time. And 
also the max captures may define a composition policy that would violate 
the synchronization.

Section 7.3:

I have a question: Can a scene have captures that are not included in 
any CSE? If not, then there probably ought to be something that says 
that. If so, then there are other issues. If so, then presumably it 
should be possible to have scenes with no CSEs. (Did we have this 
discussion previously?)

I suggest that the following:

    ... A Capture Scene includes one
    or more Capture Scene entries, with each entry including one or
    more Media Captures. ...

be tweaked by: s/Media Captures/Media Captures of the same media type/

In the following:

    A provider MAY express spatial relationships between Captures that
    are included in the same Capture Scene.  However, there is not
    necessarily the same spatial relationship between Media Captures
    that are in different Capture Scenes.  In other words, Capture
    Scenes can use their own spatial measurement system as outlined
    above in section 6.

saying capture scenes *can* user their own spatial measurement system 
suggests the contrary is a possibility - that they may share a spatial 
measurement system. That isn't really true. We assume that each scene is 
spatially unrelated to every other scene. So I suggest revising this as:

    A provider MAY express spatial relationships between Captures that
    are included in the same Capture Scene.  However, there is no
    spatial relationship between Media Captures from
    different Capture Scenes.  In other words, Capture
    Scenes each use their own spatial measurement system as outlined
    above in section 6.

While reading this section I find Capture Scene *Entry* to be a poor 
name for what it represents. ISTM that each CSE selects a set of 
captures that, together, represent a view of the entire scene. (Some 
better than others.) I think a better name for this would be *Scene View*.

(I realize that while only a nomenclature change, this is a fundamental 
element we use in talking to one another and so is mentally hard to 
change. But I think we at least ought to consider it as making clue more 
understandable to outsiders. And of course we can consider other names.)

Making such a change would of course result in renaming a number of 
other things. I won't call those out specifically.

Section 7.3.3:

The following isn't quite right:

    ... Each item in this list is a set of one or more
    Capture Scene Entries of the same media type. ...

I can read this and think that CSEs are actually contained in this. It 
is important that what is included are *references* to CSEs defined in 
scenes. So I suggest:

    ... Each item in this list is a set of references to one or more
    of the Capture Scene Entries of the same media type that are
    defined within scenes of the same advertisement. ...

And, in line with my comment about the naming of CSE, I think we can 
find a more understandable name for this thing than Global CSE List. 
(IIRC the current name was my idea.)

I'm thinking *Global View* would work as the name for one element of 
this list. And then I guess the list of them would be *Global View List*.

If we did all that, then 7.3.3 would start out as:

    7.3.3. Global View List

    An advertisement can include an optional Global View List.
    Each item in this list is a Global View. Each Global
    View is a set of one or more references to Scene Views of the same
    media type, defined within scenes of the same advertisement.
    Each Global View is a suggestion from the Provider to the
    Consumer for some Scene Views that provide a complete view of the
    simultaneous captures provided by the provider, across the multiple
    scenes of the advertisement.  The Provider can include a Global
    View List to help a consumer to choose sets of captures appropriate
    to its capabilities or application. The choice of how to make these
    suggestions in the Global View List, for what represents all
    the scenes for which the provider can send media, is up to the
    provider.  This is very similar to how each Scene View represents a
    particular scene.

(But we would certainly add Global View to the definitions, and so part 
of the above might appear there rather than here.)

Section 8:

The following:

    ... If a
    Capture Scene is included in a Simultaneous Transmission Set, then
    all its Capture Scene Entries (of the corresponding media type) are
    included in the Simultaneous Transmission Set. ...

implies that there is some mechanism to determine the media type of the 
simultaneous transmission set. Currently it is only determined by the 
type of its entries. But if all the entries are scenes, then that isn't 
good enough. I can think of a variety of fixes for this. We should 
discuss how to fix this.

I find the following ambiguous or at least hard to understand:

    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.  Likewise, if there are no
    Simultaneous Transmission Sets and there is a global CSE list, then
    the Consumer chooses at most one set of CSEs of each media type,
    from the global CSE list.

It switches from what the provider MUST do (be able to provide all 
capture scenes simultaneously), to what the consumer does, which doesn't 
seem to be normative.

What is missing is a definition of what it means to be able to provide a 
capture scene. I think "be able to provide a capture scene" means: be 
able to simultaneously provide all of the captures in any single CSE of 
the scene.

If that is right, then the question is how to write that as a clear 
normative statement. Either we can try to come up with text that says 
the above, or else we could say that there is a default simultaneous 
transmission set and come up with an algorithm to derive it from the 
CSEs in the advertisement. (The algorithm is straightforward, but 
describing it in text is not.) Here is a cut at the text:

    If an Advertisement does not include Simultaneous Transmission
    Sets, then the Provider MUST be able to simultaneously provide
    all the captures from any one CSE of each media type from each
    capture scene.

Section 9.3:

I have some concerns with the first paragraph:

    Each Media Capture MAY be associated with at least one Encoding
    Group, which is used to instantiate that Capture into one or more
    Capture Encodings.  Typically MCCs are assigned an Encoding Group
    and thus become a Capture Encoding.  The Captures (including other
    MCCs) referenced by the MCC do not need to be assigned to an
    Encoding Group. This means that all the Media Captures referenced
    by the MCC will appear in the Capture Encoding according to any MCC
    attributes. This allows an Advertiser to specify Capture attributes
    associated with the Media Captures without the need to provide an
    individual Capture Encoding for each of the inputs.

The construction "MAY be associated with at least one" seems awkward, 
and doesn't not the key point that if a capture is to be eligible for 
configuration it MUST be associated with at least one. And then, 
"Typically MCCs are assigned an Encoding Group and thus become a Capture 
Encoding" implies that the assignment of the MCC to an encoding group 
*causes* to become a Capture Encoding, which isn't right. I think the 
following clarifies both of those points:

    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, which
    is used to instantiate that Capture into one or more Capture
    Encodings. When an MCC is configured all the Media Captures
    referenced by the MCC will appear in the Capture Encoding according
    to the attributes of the chosen encoding of the MCC. This allows an
    Advertiser to specify encoding attributes associated with the Media
    Captures without the need to provide an individual Capture Encoding
    for each of the inputs.

Section 10:

Some of the text in this section is out of date with changes we have 
made along the way. This is most obvious in:

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

This suggests that resolution, frame rate, bandwidth, etc. are specified 
as part of the Configure, which is no longer true.

(I have been getting a similar feeling in earlier sections, but in each 
case I could read it as ok, because "parameters" could mean other things.)

For the moment I'm not going to suggest a specific fix. It could be 
fixed "here" with some minor rewording. But if we want to fix it 
document wide then that should be done in a unified way.

And related to that is:

    In order to meaningfully create and send an initial Configure, the
    Consumer needs to have received at least one Advertisement from the
    Provider.

It is now also necessary to have received an offer defining encodings of 
the captures of interest to the consumer. I think some rewording is 
required.

Section 12.1.1:

Area of Capture needs to come out for the audio captures, replaced by 
point of capture and point on line of capture.

More important, based on our audio discussions, does it make sense to 
provide separate audio captures for each camera? If not, what does make 
sense? Perhaps just a single mono audio, a single surround sound audio, 
and an audio for the presentation?

There is a reference to MCC5, which is not defined.

Section 12.2:

This says:

    A sane, basic, algorithm might be for the consumer to go through
    each Capture Scene in turn and find the collection of Video
    Captures that best matches the number of screens it has ...

But this doesn't say anything about CSEs - implying that ignoring them 
is sensible. It is *possible*, but explaining how to decide in that case 
is very complex. I would think for the purposes here we would want to 
recommend going through the CSEs looking for one that best exploits the 
locally available equipment.

Did the above mean to say "... go through each CSE in turn ..."?

Section 12.3.1:

Table 14 doesn't leave the consumer with much choice. For instance there 
is no choice that works for a consumer that can handle only one video 
stream.

ISTM that it would be better to merge tables 13 and 14, so that the 
consumer can have both one-encoding and two-encoding options.

Section 12.3.3:

The following appears after Table 20:

    Rather than considering what is displayed the CLUE concentrates
    more on what the MCU sends. The MCU doesn't know anything about
    the number of screens an endpoint has.

Something is wrong with this - "the CLUE" makes no sense. Should "the" 
be omitted, or was "this example" intended?

I also see a reference to section 7.3.2 that isn't linked (in the html) 
to the actual section. Perhaps it is by value rather than reference in 
the source???

Section 15:

There is a reference to "section x", that needs to be updated to 
reference to proper section.

THE END

	Thanks,
	Paul

On 6/6/14 11:35 AM, Mary Barnes wrote:
> The objective of this pre-WGLC review is for folks to take a fresh look
> at the document and re-review the entire document. Right now, there are
> just a couple outstanding issues:

---

From: Christian Groves <[email-masked]>
Date: Mon, 30 Jun 2014 12:49:36 +1000

Hello Mark,

Please see my comments below. Sorry for not being able to get back to 
you before the update.

Regards, Christian

..snip..
> [Duckworth, Mark] I don't think we need a new term in section 3.
[CNG] I see Paul has a comment about GCSEs.
> [Duckworth, Mark] I think MCU is a type of middle box.  This is described in section 4.  I don't think this definition needs to change.
[CNG] OK.
..snip

> [Duckworth, Mark] How about replace "MUST" with "typically"?
[CNG] Typically is good.
> [Duckworth, Mark] how about "A Media Capture (MC), such as audio or video, has attributes to describe the content a Provider can send."
[CNG] OK
> ..snip..
[CNG] OK, that clarifies the use.
..snip..
> [Duckworth, Mark] I don't see anything that implies a relationship between scenes.  Which sentences specifically do you mean?
[CNG] The sentence I'm referring to is "However, there is not 
necessarily the same spatial relationship between Media Captures that 
are in different Capture Scenes." "Not necessarily" to me means there 
may or may not be a spatial relationship between capture in different 
scenes.
> [Duckworth, Mark] I think this whole paragraph should be deleted.
[CNG] Fine by me.
> [Duckworth, Mark] The data model restricts an encoding group to a particular media type.
[CNG] Yes but you shouldn't have to look at the data model to find this 
out. I think the inclusion of a sentence to the effect that encoding 
groups are limited to a single media type would be beneficial.
> [Duckworth, Mark] I don't understand your point.  Do you think this paragraph is unnecessary?
[CNG] Yes, it doesn't seem to add alot. An endpoint or an MCU need to 
respond with a Configure based on the Advertisement and the MC capabilities.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Jun 2014 23:48:24 -0400

>> [Duckworth, Mark] The data model restricts an encoding group to a

Section 12.1.2 shows an encoding group that has both audio and video 
encodings, and discusses this as an alternative to having separate 
encoding groups. It is clearly saying this is intended.

	Thanks,
	Paul