Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20

From: Christian Groves <[email-masked]>
Date: Thu, 05 Feb 2015 12:16:30 +1100

Hello

Here are my last call comments:

1. Section 1 Introduction: I think it would be good to add a sentence to 
indicate that CLUE can be used in any multistream environment. It’s not 
just related to telepresence.

2. Section 4 1st para: "This section provides an overview of the 
functional elements defined in this document to represent a telepresence 
system". Like the above comment perhaps we could replace telepresence 
with multistream? The section talks about different types of systems, 
telepresence, webcam, multicast etc. CLUE can be applied to all of them.

3. Section 5 pg14 2nd para: "The Consumer in the Endpoint receives the
    information provided by the Provider, and can use it for two
    purposes" The paragraph only talks about using the information for 
constructing a Configure and for SDP. The provider can also use the 
information for rendering decisions. It would be good to clarify this.

4. Section 5 pg15 2nd para: It says all CLUE protocol mechanisms are 
optional in the consumer and that it is free to ignore the information. 
Whilst its true for the Advertisement I don't think this is generally 
true. It shouldn't ignore the Options message.

5. Section 7.1.1.3 3rd para: "If the Area of Capture is not specified, 
it means that whilst the Video Capture is not spatially related to any 
other Video Capture". Is this true? Captures in the one scene ARE 
spatially related. If the Area of capture is not included isn't the 
Provider just saying that it can't provide specific details on the relation?

6. Section 7.1.1.13: "This attribute is only applicable to video 
Captures and presentation streams with visual information." Could this 
also be applicable to audio captures? i.e. lyrics along with audio.

7. Section 7.2 Table 1: The table just lists "attributes" perhaps it 
should distinguish between "MCC attributes" and "MC attributes" to 
indicate the different scope. Also VCn should be aligned with the text 
below the table that indicates VC3.

8. Section 7.2.1.1 1st para: The actual number can be less "or equal to" 
the maximum.

9. Section 12.1.1 Pg45: I think it would be good to add 
"policy=SoundLevel" to MCC3 and MCC4 given that the descriptive text 
indicates this function.

10. Section 12.1.1 Pg48: I think we need to add some text to explain 
these parameters are not part of CLUE but are possible parameter that 
can be assigned to encodings via SDP? This is mentioned in section 
12.1.2. Maybe we should move the text to the start of the example 
section so that it applies to all sections.

11. Section 12.3.1 Table14: It would be good to add "AllowSubset=True" 
to MCC1 Just make it clear that the Provider allowed to choose.

12. Section 12.3.2 Table17: Incorrect table title, should be 
"Advertisement set to Endpoint F".

13. Section 12.3.3 Table 20: Incorrect table title, should be "...from 
Endpoints E to G"

14. Section 7.2.14 Allow subset choice: Do we need to specify a default 
behaviour if this is not included? We specify in other cases e.g. area 
of capture what it means if not included.

I've sent the purely editorial ones to the author.

Regards, Christian

On 23/01/2015 8:20 PM, Roni Even wrote:
>
> Hi,
>
> There were good reviews during the WGLC on the framework document.
>
> Mark updated the document to include all the issues that were 
> discussed in http://tools.ietf.org/html/draft-ietf-clue-framework-20
>
> In order to verify that all concerns were addressed we will have a 
> short WGLC till *February 4^th * and in there are no more open issues 
> we will send the document to publication.
>
> Mark noted the following changes from 19 to 20:
>
>      1. Define term "CLUE" in introduction.
>
>      2. Add MCC attribute Allow Subset Choice.
>
>      3. Remove phrase about reducing SDP size, replace with
>
>         potentially saving consumer resources.
>
>      4. Change example of a CLUE exchange that does not require SDP
>
>         exchange.
>
>      5. Language attribute uses RFC5646.
>
>      6. Change Member person type to Attendee.  Add Observer type.
>
>      7. Clarify DTLS/SRTP MUST be supported.
>
>      8. Change SHOULD NOT to MUST NOT regarding using xCard or
>
>         description information for authorization decisions.
>
>      9. Clarify definition of Global View.
>
>      10. Refer to signaling doc regarding interoperating with a
>
>         device that does not support CLUE.
>
>      11. Various minor editorial changes from working group last call
>
>         feedback.
>
>      12. Capitalize defined terms.
>
> Thanks
>
> Roni Even
>
> CLUE co-chair
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Feb 2015 12:18:59 -0500

I have just a few minor comments on this version:

Section 7.1.1.4:

    The capture point of a static Capture MUST NOT move for the life of
    the conference.

I don't think "conference" is the right word here. (The session might 
not be a conference.) Perhaps "CLUE session" would work, though it is 
not a defined term.

Section 7.1.1.11:

Again "conference is used where it might not be the right word. There 
could be only two endpoints in the call, even if there are several 
people at each end. And it is *possible* that there might be a Minute 
Taker even if there were only two people in the call. So again perhaps 
"session" or "CLUE session" would be better.

Section 7.2:

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

The "temporally and/or spatially" works for video. Is that right for 
audio? I guess "temporally" still applies, but does "spatially"? Maybe 
it could if you have a stereo audio capture. But if you just mix the few 
loudest speakers, what do you call that?

I don't have a suggestion about how to improve this. Does someone have a 
suggestion? If not then this may be as good as we can do.

	Thanks,
	Paul

On 1/23/15 4:20 AM, Roni Even wrote:
> Mark updated the document to include all the issues that were discussed
> in http://tools.ietf.org/html/draft-ietf-clue-framework-20
>
> In order to verify that all concerns were addressed we will have a short
> WGLC till *February 4^th * and in there are no more open issues we will
> send the document to publication.
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 12 Feb 2015 06:22:42 -0800

Thanks Christian.
My comments inline.
Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Wednesday, February 04, 2015 8:17 PM
> To: [email-masked]
> Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20
> 
> Hello
> 
> indicate that CLUE can be used in any multistream environment. It's not
[Duckworth, Mark] How about adding "This includes cases using multiple media streams that are not necessarily telepresence."

> telepresence, webcam, multicast etc. CLUE can be applied to all of them.
[Duckworth, Mark] How about "telepresence or multistream"?  The spatial size stuff can be useful for telepresence even without multistream.

> information for rendering decisions. It would be good to clarify this.
[Duckworth, Mark] I think you mean the consumer can use the information for rendering?  How about saying "... can use it for three purposes" and then add a sentence about rendering?

> true. It shouldn't ignore the Options message.
[Duckworth, Mark] I think it's okay the way it is.  The protocol document has the details.

> Provider just saying that it can't provide specific details on the relation?
[Duckworth, Mark] How about "If the Area of Capture is not specified, it means the Video Capture is spatially related to other Captures in the same Scene, but there is no detailed information on the relationship."

> also be applicable to audio captures? i.e. lyrics along with audio.
[Duckworth, Mark] I don't remember why that restriction was added.  Was that in your original proposal for this attribute?  It is okay with me to remove this sentence.

> below the table that indicates VC3.
[Duckworth, Mark] I agree

> 8. Section 7.2.1.1 1st para: The actual number can be less "or equal to"
[Duckworth, Mark] ok

> "policy=SoundLevel" to MCC3 and MCC4 given that the descriptive text
[Duckworth, Mark] ok

> section so that it applies to all sections.
[Duckworth, Mark] I can clarify this.

> to MCC1 Just make it clear that the Provider allowed to choose.
[Duckworth, Mark] ok

> "Advertisement set to Endpoint F".
[Duckworth, Mark] Thanks.  And there are two tables called 17.  I'll fix the numbering.

> 13. Section 12.3.3 Table 20: Incorrect table title, should be "...from
[Duckworth, Mark] ok

> of capture what it means if not included.
[Duckworth, Mark] It is not optional, so must be included.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Feb 2015 11:52:09 -0500

> [Duckworth, Mark] How about "If the Area of Capture is not specified, it means the Video Capture is spatially related to other Captures in the same Scene, but there is no detailed information on th…

Consider a scene containing two computer-generated powerpoint captures.

The advertiser *could* include specific area of capture information if 
it wants to indicate how they should be presented relative to one 
another. But lacking that they really have no spatial relationship to 
one another, and the implication is that the receiver should make its 
own decision about how to present them.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 12 Feb 2015 09:05:56 -0800

Hi Paul,
So are you saying we should not make any change in the framework about this?
Mark

> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, February 12, 2015 11:52 AM
> To: [email-masked]
> > [Duckworth, Mark] How about "If the Area of Capture is not specified, it
> means the Video Capture is spatially related to other Captures in the same
> Scene, but there is no detailed information on the relationship."
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Feb 2015 12:31:30 -0500

> So are you saying we should not make any change in the framework about this?

This is nit picking. I've made my point. I'll be satisfied with whatever 
you do.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Thu, 12 Feb 2015 20:24:35 +0200

Hi,
> [Duckworth, Mark] I don't remember why that restriction was added.  Was
that
> in your original proposal for this attribute?  It is okay with me to
remove this
> sentence.

Roni: This was discussed in IETF 90 and that was captured in the meeting
notes. Also mentioned  in Mark's email from September 5th, it was also
discussed in the pre-WGLC on draft 15 and I think that Christian was OK for
video only at the time.

Regards
Roni

> From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
> Sent: 12 February, 2015 4:23 PM
> To: Christian Groves; [email-masked]
> > 1. Section 1 Introduction: I think it would be good to add a sentence
> > to indicate that CLUE can be used in any multistream environment. It's
> > not just related to telepresence.
> [Duckworth, Mark] How about adding "This includes cases using multiple
media
> streams that are not necessarily telepresence."
> 
> > functional elements defined in this document to represent a
> > telepresence system". Like the above comment perhaps we could replace
> > telepresence with multistream? The section talks about different types
> > of systems, telepresence, webcam, multicast etc. CLUE can be applied to
all
> of them.
> [Duckworth, Mark] How about "telepresence or multistream"?  The spatial
size
> stuff can be useful for telepresence even without multistream.
> 
> [Duckworth, Mark] I think you mean the consumer can use the information
for
> rendering?  How about saying "... can use it for three purposes" and then
add a
> sentence about rendering?
> 
> [Duckworth, Mark] I think it's okay the way it is.  The protocol document
has
> the details.
means
> the Video Capture is spatially related to other Captures in the same
Scene, but
> there is no detailed information on the relationship."
> 
> [Duckworth, Mark] I don't remember why that restriction was added.  Was
that
> in your original proposal for this attribute?  It is okay with me to
remove this
> sentence.
> [Duckworth, Mark] Thanks.  And there are two tables called 17.  I'll fix
the
> numbering.
> > 14. Section 7.2.14 Allow subset choice: Do we need to specify a
> > default behaviour if this is not included? We specify in other cases
> > e.g. area of capture what it means if not included.
> > > short WGLC till *February 4^th * and in there are no more open
> > > issues we will send the document to publication.
> > >

---

From: Christian Groves <[email-masked]>
Date: Mon, 16 Feb 2015 23:39:25 +1100

Hello Mark,

Please see my replies below.

Regards, Christian

..snip..

> [Duckworth, Mark] How about adding "This includes cases using multiple media streams that are not necessarily telepresence."
[CNG] OK for me.
> [Duckworth, Mark] How about "telepresence or multistream"?  The spatial size stuff can be useful for telepresence even without multistream.
[CNG] OK
> [Duckworth, Mark] I think you mean the consumer can use the information for rendering?  How about saying "... can use it for three purposes" and then add a sentence about rendering?
[CNG] OK
> [Duckworth, Mark] I think it's okay the way it is.  The protocol document has the details.
[CNG] Then why don't we remove the sentence and really leave it up to 
the protocol document? I think we're really only talking about the 
Advertisement and even for that is it true. i.e. the Consumer shouldn't 
ignore the "allow subset choice" parameter.
> [Duckworth, Mark] How about "If the Area of Capture is not specified, it means the Video Capture is spatially related to other Captures in the same Scene, but there is no detailed information on th…
[CNG] OK.
> [Duckworth, Mark] I don't remember why that restriction was added.  Was that in your original proposal for this attribute?  It is okay with me to remove this sentence.
[CNG] Yes it was the original based on a comment I received. In 
hindsight I don't think I should have proposed it.
> ..snip..