Re: [clue] FW: New Version Notification for draft-even-clue-swithed-use-cases-00.txt

Hi Roni,
I mentioned during the weekly call that I had some comments. Thanks for your patience in getting them to you.
Best,
Allyn

I think your draft is really useful and well put. I just have two comments which I'll illustrate in comments on Section 3.

1.	You are including both composition and switched captures as if they are similar or can be treated similarly. I don't think that's the case.
2.	I feel that sometimes a solution is included in the description of the issue and I think it is preferable that the use cases are just the description of the issue, and possible solutions can be stated separately.

Section 3
I think the statement of the issue is quite good and well put - the consumer wants to have better control over what it is sent.
Similarly your bulleted examples are also helpful and descriptive.

Here are my specific comments on the use case list -

   The above examples represent part of the possible cases where the
   consumer wants control over the content of the media captures and of
   cases where the consumer provides more information to the provider
   about his hardware and software capabilities.

I think the wording is a bit too specific. It's not only that the consumer "wants control over the content of the media captures", it's more that the consumer wants to specify which media captures are offered - which I think is a bit different. So I would say something more like

	the consumer wants more control over the captures it receives

The statement "consumer provides more information to the provider about his hardware and software capabilities" is a bit too narrow. Perhaps the consumer wants to specify its layout. Also, this is a more a statement of a solution - for the consumer to provide more information about his abilities is a solution to a problem, rather than a statement of the problem. I would suggest not including this sentence.

1.	The provider offers multiple mixed captures.  Currently the only
      attribute has a Boolean value.  The provider would like to
      provide more information about the mixes content allowing the
      consumer to select a relevant one.

I think the problem is stated, but so is the solution - the problem is that the consumer wants to select among multiple offered mixed captures. A mechanism is needed. "The provider would like to provide more information about the mixes content" is a particular solution. For example, another particular solution is that the provider chooses; another is that the provider sends a ranking number for each offered composition.. There are countless approaches in addition to the one offered here. So, I would suggest leaving out this sentence.

   2.   The provider would like to offer only media captures that are
        useful to the consumer.  The simple case is based on the number
        of available monitors for main video.

Why does the provider want to offer only media captures that are useful to the consumer? This isn't how the model thus far is specified. Rather, the provider wants to offer what it can, and leave it up to the consumer to take what it wants. Maybe you were referring to a desire to optimize the announcement? When and why?

I'm not so sure what the second sentence means, but I think it means that you want the provider to make its offer based on the number of monitors that the consumer has? But that wouldn't make sense..since the consumer can use more streams than it has monitors,  so I guess I don't know what it means??

   3.   The consumer will provide more information about his preferences
        for example the total number of monitors that can be used
        dynamically for all types of media (number of speakers, number
        of monitors for main or presentation video, the number of
        simultaneous video streams that the consumer can decode ...).
        The provider will advertise relevant CSEs that he can support to
        address these preferences.  It may be more than one option.

This item is a proposal for a solution to the issues being described. As such I don't think it should be in this document as it currently describes itself as a description of use cases.

   4.   The MCU will offer mixed media captures (one or more) in one or
        more CSEs.  The consumer want to select how many sources are in
        each mixed capture and how the layout should look.  This will
        allow each consumer to create a personal layout if the MCU
        allows this functionality.  The MCU is doing the actual mix in
        the case.

By "mixed media captures", do you mean composed captures? If so, I believe that there has been a decision in the WG, discussed most recently during the interim meeting, not to work on the topic of compositions in detail - the process of composing and decomposing. I think that your second sentence relates to compositions and how they are formed.

So, I think this item should not be included in this document. 

   5.   The MCU will offer multiple media captures in one or more CSEs.
        The consumer want to select who will be seen in each mixed
        capture knowing the number of maximum media streams that can
        compose the mix.  This use cases adds to the previous one the
        ability to control the policy by which streams are added or
        removed from a mix.

As in #4, I think it was decided not delve into the process of composing and decomposing mixes. I believe this is work that does not need to be done in CLUE, and someone could start the work somewhere else if desired.
Thus, this item should be removed from the list.

6.	 The MCU will offer multiple switched media captures in one or
        more CSEs.  The consumer wants to define a switching policy for
        each of the switched streams.

Point of clarification what is a switching policy for each switched stream? You mean a policy like VAD, for example?  We haven't discussed yet how the policy for choosing switched content happens. Up to now it's the provider who decides. Now, are you suggesting that the consumer wants to specify the basis for choosing content of a switched capture?
   7.   The MCU will offer multiple switched and mixed media captures in
        one or more CSEs.  The consumer would like to define the layouts
        topology.

I think this is a restatement - if there is a switched capture the consumer needs to know where to put it.
If there is more than one composed capture, there needs to be a way of selecting between them.
Again, I think that saying the "consumer would like to define the layouts topology" is going too far toward a solution in a description of the use cases. Very likely this is a possible solution, but there are others.
So I think this item could be removed, or restated. 

Again, the consumer defining the layouts topology is a solution to a problem, not the use case.

   9.   The consumer would like to get multiple media captures and
        create his own views.  The media capture may be a switched
        stream.  The information available to the consumer should
        include the identity of the stream and its spatial information
        (example left camera from TPRoom1).  The information should be
        available when a switch occurs.

What do mean by identity of the stream? Roster info? I thought that roster info was considered conference control and not being handled by CLUE?

Otherwise, this item  seems like this is more a less a statement of the issue of switched captures not having enough spatial information for rendering. As such, it could be dstate like that, as a description of an issue, and moved further up in the list?

   10.  The consumer would like to define layouts to the provider to be
        used for the media captures.  The consumer accepts a mixed or
        switched stream in each sub-window.  The maximum number of
        switched streams will be the number of sub-windows.  The
        consumer will need to know who is the current stream in a mixed
        capture including his spatial information.

I'm not clear what this is saying, and whether it's use case, problem statement or solution proposal.

-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni even
Sent: Monday, June 11, 2012 7:20 AM
To: clue@ietf.org
Subject: [clue] FW: New Version Notification for draft-even-clue-swithed-use-cases-00.txt

Hi,
I submitted a document that list some use cases where using the switched and mixed attributes for media capture will not provide enough information.
This was my action item from the Interim meeting in Stockholm. 

I noticed a typo in the document name after I submitted it Thanks Roni Even

________________________________________
From: internet-drafts@ietf.org [internet-drafts@ietf.org]
Sent: Monday, June 11, 2012 17:13
To: Roni even
Subject: New Version Notification for draft-even-clue-swithed-use-cases-00.txt

A new version of I-D, draft-even-clue-swithed-use-cases-00.txt has been successfully submitted by Roni Even and posted to the IETF repository.

Filename:        draft-even-clue-swithed-use-cases
Revision:        00
Title:           CLUE switched and mixed captures use cases
Creation date:   2012-06-11
WG ID:           Individual Submission
Number of pages: 7

Abstract:
   This document describes multi stream use cases using switched and
   mixed streams.  This document present the cases when using the
   switched and mixed attributes with Boolean values may not provide the
   best results.

The IETF Secretariat
_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue