Subject: Re: [clue] Fwd: Comments on CLUE Framework

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 11 Oct 2013 11:56:37 -0700

Mary,
I'm updating the framework according to this discussion.  But there are a few things still open:

1.       For your comment number 2, you offered to take a pass at moving some information out of the Introduction into a new section or into the overview.  That would be very helpful to me, thanks.

2.       You offered to create a new ascii diagram based on an old one from section 5 of the -02 version

3.       Using All Caps for defined terms - personally I agree with you I prefer the terms as lower case (both as an editor and as a reader).  Does anybody else have input to this?

Mark

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Wednesday, August 28, 2013 5:59 PM
To: Christian Groves
Cc: CLUE
Subject: Re: [clue] Fwd: Comments on CLUE Framework

HI Christian,

Thanks for your comments - my responses are below [MB2].

Mary.

On Tue, Aug 27, 2013 at 10:48 PM, Christian Groves <[email-masked]<mailto:[email-masked]>> wrote:
Hello Mary,

Please see my responses below.

Regards, Christian

On 28/08/2013 1:53 AM, Mary Barnes wrote:
Hi folks,

In reviewing the FW in order to tease out specific security threats that a CLUE solution must address, I came up with a set of comments that I would like the WG to consider. Below is the thread of discussion. Additional feedback (both agreeing with the proposal or not - with details if you don't agree) from the WG is necessary in order for Mark to include these changes. As noted, I will provide some concrete text to go along with a couple of the suggestions. Please send feedback no later than Sept. 3rd CoB. No responses will be interpreted as support for the changes.

Of course, there will be an opportunity to provide comments on the updated version of the document as well later, but it's always helpful to get that feedback before incorporating changes.

Regards,
Mary
--as an individual

---------- Forwarded message ----------
From: *Mary Barnes* <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
Date: Tue, Aug 27, 2013 at 10:18 AM
Subject: Re: Comments on CLUE Framework
To: "Duckworth, Mark" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
Cc: Paul Kyzivat <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>

Thanks for the response. I have a few responses below [MB]. I will forward the comments to the list to get feedback from the WG.

Mary.

On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Hi Mary,

    Thanks for the good suggestions. In general, all your suggestions
    make sense to me.

    More comments below.

    Mark
    *From:*Mary Barnes [mailto:[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>]
    *Sent:* Wednesday, August 21, 2013 2:23 PM
    *To:* Duckworth, Mark
    *Cc:* Paul Kyzivat
    *Subject:* Comments on CLUE Framework

    So, here are the comments I have on the framework based on my
    re-read to tease out specifics for the security requirements. One
    major thing I noticed is that some of the structural concerns I
    have are with regards to some of the bigger changes made between
    the -08 and -09. Again, I looked at diffs after the various
    revisions were submitted and thought the content was okay at the
    time. But, as I'm now re-reading from beginning to the end (for
    the first time in a long time), there are some areas that I really
    stumbled over and I think some more reorganization/editorial work
    is needed before we could forward this doc for publication. Having
    been a gen-art reviewer for a decade, I think similar issues would
    be raised on the document by other directorate reviewers (and ADs)
    if we don't make a few changes. I wanted to vet these with you
    prior to posting to the WG mailing list.

    Paul - I'm reviewing this from the perspective that was discussed
    on WG chairs mailing list with regards to doing multiple reviews
    as part of the PROTO process.

    Mary.

    Comments:

    ===========

    Major:

    -------

    1) The abstract needs some beefing up, including setting some
    context. Per my comment 3 below, I think it's important to
    highlight that the protocol outlined in this document augments and
    does not replace SIP O/A. I would suggest to update the text in
    the Abstract something like the following. :

    OLD:

         This document offers a framework for a protocol that enables

        devices in a telepresence conference to interoperate by specifying

        the relationships between multiple media streams.

    NEW:

    This document defines a framework for a protocol to enable devices
    in a telepresence conference to interoperate. The protocol enables
    communication of information about multiple media streams so a
    sending system, receiving system or intermediate system can make
    reasonable decisions about transmitting, selecting and rendering
    the media streams. This protocol is used in addition to SIP
    signaling for setting up a telepresence session.
    */[Duckworth, Mark] sounds good./*
/*[CNG] CLUE is point to point, (i.e. sent from one endpoint and terminated at another)*/ so there is no intermediate system from a CLUE perspective. I would strike the text regarding intermediate system.
[MB2] My understanding was that intermediate system is something line an MCU or conference focus.   However, I think you are correct in that sending system and receiving system are sufficient. I also double checked and we don't use the term intermediate system in the requirements or use cases expect in the Heterogeneous system use case when it's talking about transcoding.  [/MB2]

    2) Introduction: I really stumbled over the level of detail that
    the document jumps into in the Introduction (which is before any
    terminology). It goes from a high level description of the
    problem, highlighting that this document provides a framework
    based on the use cases and requirements, directly to the
    statement: "Conceptually distinguished are Media Providers and
    Media Consumers". I also think the level of detail does not belong
    in the introduction. To me that's more overview/motivation.
    Previously, the introduction provided some text as to what is in
    the remainder of the document. I think some of the old text needs
    to be pulled back into this introduction and the text starting
    with the "Conceptually" paragraph might serve very well in a
    "Motivation" section just prior to the overview (after the
    terminology section). I also think the "Conceptually" sentence
    could be replaced with text that provides a better introduction to
    the section, perhaps linking the term "consumer" to "receiver" and
    "provider" to "sender" that are mentioned in the abstract text I
    suggested above. Maybe something like the following:

    OLD:

    Conceptually distinguished are Media Providers and Media Consumers.

    NEW:

    This document introduces the term Media Provider to represent the
    entity that is sending the media and Media Consumer to represent
    the entity that is receiving the media.
    */[Duckworth, Mark] sounds good. But it will take some work to

    figure out detailed changes between introduction and overview, and
    bringing back some old text./*

[MB] Yeah, I know. I can make a pass at that if you would find that helpful. [/MB]
[CNG] OK in theory, I'll wait for the concrete text.

    *//*

    3) The fact that SIP and SDP offer/answer are used for basic
    session setup as well as when needed during the session (as
    described in detail in solution documents) isn't highlighted early
    enough or often enough. Given we've had lots of folks thinking we
    were trying to invent something new entirely, I think it's really
    important for this be quite explicit early on. I think this
    relates to additional text that should be in the introduction. I
    think something like the following will be sufficient:

    NEW:

    This document identifies the protocols necessary to achieve the
    functionality per the use cases and requirements. The basic
    session setup for the use cases is based on SIP [RFC 3261] and SDP
    offer/answer [RFC 3264]. The details with regards to this
    signaling are provided in the solution documents. In addition to
    basic SIP & SDP offer/answer, CLUE specific signaling is required
    to exchange the information describing the multiple media streams.
    The details of this signaling and the information required to be
    exchanged is described in subsequent sections of this document.
    */[Duckworth, Mark] sounds good. We tried to say this about using

    SDP O/A, but not until the end of section 4. It does seem better
    to say it earlier./*
/*[CNG] I think we should also make it clear that whilst "SIP and SDP O/A" are mainly discussed it does not prevent CLUE from being used in networks where there are other call controls i.e. H.32x, WebRTC, what ever the future holds.... */
[MB2] I don't disagree with what you say but I don't think we should say anything about that given our charter, which limits the work to SIP. That's opening up the question as to how that will work, whether additional specification is required,etc.  [/MB2]

    Minor:

    --------

    1) General: I realize that at some point, someone changed all the
    terms to appear as formal names - e..g., capitalized. Personally,
    I prefer just having the terms all lower case as I find it easier
    to read that way. However, the RFC editor leaves the choice to the
    document editor, but it needs to be consistent. So, another pass
    is needed as I noticed a few that weren't caps that should be and
    some that were caps that shouldn't be. For example, in the
    "Conceptually" paragraph I refer to above, "Renderer" is in Caps,
    but it's not defined as a reserved word in the terminology and I'm
    assuming that the intent is to only have nouns in all caps? You
    will find it awkward if you try to change every occurrence of the
    reserved words as sometimes it just won't read right (which is
    another reason to just use lower case).
    */[Duckworth, Mark] I don't care either way. I think it was

    Stephan who first suggested capitals, in the old terminology
    document./*

[MB] Again, either way is okay. But, there are some places where it's not all caps. I also think using lower case is easier just from a basic editing standpoint as it's more natural IMHO to just type the words and not have to CAP. [/MB]
[CNG] It can be helpful to have capitalised terms to distinguish when you're talking about a entity Renderer vs a function "render".
    *//*

    2) Introduction: The text in the intro (3rd para) (that I'm
    suggesting to move to Motivation section) that starts with
    "Motivations" reads a little funky. I suggest to reword something
    like:

    OLD:
       Motivations for this document (and, in fact, for the existence ofthe CLUE protocol) include:

    NEW:

    The motivations for the framework outlined in this document include the following:
    */[Duckworth, Mark] sounds good/*
/*[CNG] OK*/

    3) Introduction: List item (1). I was going to suggest rewording
    (as it reads as if the endpoints described are only specific to
    this document), but it's not clear to me exactly what that item is
    trying to say. Can it be changed to something like the following
    and still mean what is intended? [As an aside "Media Renderer"
    isn't a reserved word - I think perhaps if you add a definition
    for "Renderer" that would help. I actually think that's probably
    necessary anyways as I think it's important to distinguish "Media
    Renderer" from "Media Consumer"].

    OLD:

    (1) Endpoints according to this document can, and usually do, have multiple Media Captures and Media Renderers, that is, for example,multiple cameras and screens.  While previous system designs were able to set up calls that would light up all screens and cameras

    (or equivalent), what was missing was a mechanism that can associate the Media Captures with each other in space and time.

    NEW:

    (1) Endpoints in telepresence systems typically have multiple Media Captures and Media Renderers, e.g., multiple cameras and screens.  While previous system designs were able to set up calls that would capture media using all cameras and display media on all screens, for example, there is no mechanism that can associate these Media Captures with each other in space and time.

    */[Duckworth, Mark] Yes, I think that says the intent better./*
/*[CNG] */I'd propose a slight reword "Endpoints in telepresence systems typically have multiple Media Capture and Media Render devices, e.g., multiple cameras and screens. ..."
[MB2] That sounds good to me. [/MB]

    4) Section 4, last two paragraphs. I'm really wondering how much
    needs to be said (if anything) about "legacy" in this document.
    This document is defining what we need for CLUE. The signaling
    solution document will of course get into how this works. But, I
    think we could just delete the next to last paragraph and condense
    the one on RTP to reference the WG RTP mapping mapping document
    */[Duckworth, Mark] okay/*
/*[CNG] I don't think one paragraph describing this fall back in the framework is too much. I think its helpful to explain fallback behaviour. */
[MB2] If you read it in the context of that section, it doesn't quite seem to fit. It leaves more questions than providing answers in my opinion.   It seems to be some leftover text from when the document had a lot more detail - e.g., the text about legacy devices is totally unnecessary as they aren't referenced elsewhere in the framework any longer.  I think perhaps the idea of fallback when the device doesn't support CLUE can be stated much more concisely.  I don't have a proposal right off, but will think about it. Unless someone else has suggestions.  [/MB2]

    5) Somewhat General. There was a diagram in Section 5 in the -02
    version that was dropped in the -03. I really think that more
    diagrams would help to understand this stuff.
    */[Duckworth, Mark] That was the precursor to this. The -02

    diagram doesn't really say much, but I could try to update it. The
    one below is a bit much to convert to ASCII./*

[MB] I can convert that to ascii art. I did all the diagrams in RFC 5239. This is just a tad more complicated than some of those. [/MB]
    *//*

    *//*

    6) Per my other email, I believe these should all be normative
    references and RFC 3264 needs to be added.

[CNG] ???
[MB2] Sorry, there was another email exchange that I hadn't yet sent to the list about making this document standards track and adding some more references.  I'll send that now. [/MB2]
_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

---

From: Mary Barnes <[email-masked]>
Date: Mon, 14 Oct 2013 08:40:38 -0500

Hi Mark,

I apologize for not getting my action items done sooner - I've been
traveling solid for the past 4 weeks.  Now that I'm back to a big screen, I
should be able to get these edits to you.   From a WG perspective, I don't
think any of this is normative, so I think it will be okay to submit the
changes and then the WG can provide any feedback on those changes as it's
hard to just review new text out of context (I will be pulling text from
earlier versions of the FW with slight modifications).

As mentioned previously, we would like to do a pre-WGLC on this document
very soon.  Given the closeness to the meeting, we should likely wait for
any changes based on discussion of issues in Vancouver.   We can then start
a 3 week review (since we will be overlapping with US thanksgiving).

Thanks for following up on this.

Mary.

On Fri, Oct 11, 2013 at 1:56 PM, Duckworth, Mark <[email-masked]
> wrote:

> Mary,****
>
> I’m updating the framework according to this discussion.  But there are a
> few things still open:****
>
> **1.       **For your comment number 2, you offered to take a pass at
> moving some information out of the Introduction into a new section or into
> the overview.  That would be very helpful to me, thanks.
>
[MB] I will get that to you within the next day or so. [/MB]

> ****
>
> **2.       **You offered to create a new ascii diagram based on an old
> one from section 5 of the -02 version
>
[MB] Ditto [/MB]

> ****
>
> **3.       **Using All Caps for defined terms – personally I agree with
> you I prefer the terms as lower case (both as an editor and as a reader).
> Does anybody else have input to this?****
>
> ** **
>
> Mark****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mary Barnes
> *Sent:* Wednesday, August 28, 2013 5:59 PM
> *To:* Christian Groves
> *Cc:* CLUE
>
> *Subject:* Re: [clue] Fwd: Comments on CLUE Framework****
>
> ** **
>
> HI Christian,****
>
> ** **
>
> Thanks for your comments - my responses are below [MB2].****
>
> ** **
>
> Mary.****
>
> ** **
>
> On Tue, Aug 27, 2013 at 10:48 PM, Christian Groves <
> [email-masked]> wrote:****
>
> Hello Mary,
>
> Regards, Christian****
> On 28/08/2013 1:53 AM, Mary Barnes wrote:****
>
> Hi folks,
>
> In reviewing the FW in order to tease out specific security threats that a
> CLUE solution must address, I came up with a set of comments that I would
> like the WG to consider. Below is the thread of discussion. Additional
> feedback (both agreeing with the proposal or not - with details if you
> don't agree) from the WG is necessary in order for Mark to include these
> changes. As noted, I will provide some concrete text to go along with a
> couple of the suggestions. Please send feedback no later than Sept. 3rd
> CoB. No responses will be interpreted as support for the changes.
>
> Of course, there will be an opportunity to provide comments on the updated
> version of the document as well later, but it's always helpful to get that
> feedback before incorporating changes.
>
> Regards,
> Mary
> --as an individual
>
> ---------- Forwarded message ----------****
>
> From: *Mary Barnes* <[email-masked] <mailto:
> [email-masked]>>
> Subject: Re: Comments on CLUE Framework****
>
> To: "Duckworth, Mark" <[email-masked] <mailto:
> [email-masked]>>
> Cc: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
>
>
> Thanks for the response. I have a few responses below [MB]. I will forward
> the comments to the list to get feedback from the WG.
>
> Mary.
>
> ****
>
> On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark <
> [email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Mary,
>
>     Mark****
>     *From:*Mary Barnes [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Subject:* Comments on CLUE Framework****
>
>
>
>     signaling for setting up a telepresence session.****
>
>     */[Duckworth, Mark] sounds good./*****
>
> /*[CNG] CLUE is point to point, (i.e. sent from one endpoint and
> terminated at another)*/ so there is no intermediate system from a CLUE
> perspective. I would strike the text regarding intermediate system.****
>
> [MB2] My understanding was that intermediate system is something line an
> MCU or conference focus.   However, I think you are correct in that sending
> system and receiving system are sufficient. I also double checked and we
> don't use the term intermediate system in the requirements or use cases
> expect in the Heterogeneous system use case when it's talking about
> transcoding.  [/MB2]****
>
> ** **
>
>     the entity that is receiving the media.****
>
>     */[Duckworth, Mark] sounds good. But it will take some work to****
>
>
>     figure out detailed changes between introduction and overview, and****
>
>     bringing back some old text./*****
>
>
>
> [MB] Yeah, I know. I can make a pass at that if you would find that
> helpful. [/MB]****
>
> [CNG] OK in theory, I'll wait for the concrete text.****
>
>
>     *//*****
>
>
>
>     exchanged is described in subsequent sections of this document.****
>
>     */[Duckworth, Mark] sounds good. We tried to say this about using****
>
>
>     SDP O/A, but not until the end of section 4. It does seem better****
>
>     to say it earlier./*****
>
> /*[CNG] I think we should also make it clear that whilst "SIP and SDP O/A"
> are mainly discussed it does not prevent CLUE from being used in networks
> where there are other call controls i.e. H.32x, WebRTC, what ever the
> future holds.... */****
>
> [MB2] I don't disagree with what you say but I don't think we should say
> anything about that given our charter, which limits the work to SIP. That's
> opening up the question as to how that will work, whether additional
> specification is required,etc.  [/MB2] ****
>
>
>     Minor:
>
>     --------
>
>     another reason to just use lower case).****
>
>     */[Duckworth, Mark] I don’t care either way. I think it was****
>
>
>     Stephan who first suggested capitals, in the old terminology****
>
>     document./*****
>
>
>
> [MB] Again, either way is okay. But, there are some places where it's not
> all caps. I also think using lower case is easier just from a basic editing
> standpoint as it's more natural IMHO to just type the words and not have to
> CAP. [/MB]****
>
> [CNG] It can be helpful to have capitalised terms to distinguish when
> you're talking about a entity Renderer vs a function "render".****
>
>     *//*****
>
>
>
>     OLD:****
>        Motivations for this document (and, in fact, for the existence
> ofthe CLUE protocol) include:****
>
>
>
>     NEW:
>
>
>     The motivations for the framework outlined in this document include
> the following:****
>
>     */[Duckworth, Mark] sounds good/*****
>
> /*[CNG] OK*/****
>
>
>     (1) Endpoints according to this document can, and usually do, have
> multiple Media Captures and Media Renderers, that is, for example,multiple
> cameras and screens.  While previous system designs were able to set up
> calls that would light up all screens and cameras
>
>     (or equivalent), what was missing was a mechanism that can associate
> the Media Captures with each other in space and time.
>
>     NEW:
>
>
>     (1) Endpoints in telepresence systems typically have multiple Media
> Captures and Media Renderers, e.g., multiple cameras and screens.  While
> previous system designs were able to set up calls that would capture media
> using all cameras and display media on all screens, for example, there is
> no mechanism that can associate these Media Captures with each other in
> space and time.
>
>       ****
>
>     */[Duckworth, Mark] Yes, I think that says the intent better./*****
>
> /*[CNG] */I'd propose a slight reword "Endpoints in telepresence systems
> typically have multiple Media Capture and Media Render devices, e.g.,
> multiple cameras and screens. ..."****
>
> [MB2] That sounds good to me. [/MB] ****
>
> ** **
>
>
>     the one on RTP to reference the WG RTP mapping mapping document****
>
>     */[Duckworth, Mark] okay/*****
>
> /*[CNG] I don't think one paragraph describing this fall back in the
> framework is too much. I think its helpful to explain fallback behaviour. */
> ****
>
> [MB2] If you read it in the context of that section, it doesn't quite seem
> to fit. It leaves more questions than providing answers in my opinion.   It
> seems to be some leftover text from when the document had a lot more detail
> - e.g., the text about legacy devices is totally unnecessary as they aren't
> referenced elsewhere in the framework any longer.  I think perhaps the idea
> of fallback when the device doesn't support CLUE can be stated much more
> concisely.  I don't have a proposal right off, but will think about it.
> Unless someone else has suggestions.  [/MB2]****
>
>
>     diagrams would help to understand this stuff.****
>
>     */[Duckworth, Mark] That was the precursor to this. The -02****
>
>
>     diagram doesn’t really say much, but I could try to update it. The****
>
>     one below is a bit much to convert to ASCII./*****
>
>
>
> [MB] I can convert that to ascii art. I did all the diagrams in RFC 5239.
> This is just a tad more complicated than some of those. [/MB]****
>
>     *//*
>
>     *//*****
>
>
>
> ****
> [CNG] ???****
> [MB2] Sorry, there was another email exchange that I hadn't yet sent to
> the list about making this document standards track and adding some more
> references.  I'll send that now. [/MB2] ****
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue****
>
> ** **
>