Subject: [clue] Fwd: Comments on CLUE Framework

From: Mary Barnes <[email-masked]>
Date: Tue, 27 Aug 2013 10:53:05 -0500

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]>
Date: Tue, Aug 27, 2013 at 10:18 AM
Subject: Re: Comments on CLUE Framework
To: "Duckworth, Mark" <[email-masked]>
Cc: Paul Kyzivat <[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]
> 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]]
> *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.*****
>
> ** **
>
> 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]

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

> **
>
> ** **
>
> 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 of the CLUE protocol) include:****
>
> NEW: ****
>
> ** **
>
> The motivations for the framework outlined in this document include the following:****
>
> ** **
>
> *[Duckworth, Mark] sounds good*
>
> ** **
>
> 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.*
>
> ** **
>
> 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*
>
> ** **
>
> 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. ****
>
> ** **
>
> ** **
>
> Nits:****
>
> -----****
>
> 1)  Section 4, next to the last paragraph - starting with "Legacy
> devices": ****
>
>    "here in" -> "herein"****
>
> ** **
>
> 2) Section 6.1.1.  I think it would be really helpful to indent the text
> that goes along with the attribute name.  Several of the descriptions go
> beyond one paragraph and it would be much more readable if the attribute
> name was easier to pick out. ****
>
> ** **
>
> 3) Section 6.1.1.  Language attribute.  Add a space between "multilingual"
> and "and/or accessible". ****
>
> ** **
>
> 4) Section 6.2.2. 4th paragraph (beginnning with "When the room at site A
> shown") add "is" between "A" and "shown"****
>
> ** **
>
> 5) Section 11.2. 1st paragraph.  It would help to add an explicit section
> reference since I believe the previous section being reference is 11.1.1 is
> several pages back.  ****
>
> ** **
>

H

---

From: Christian Groves <[email-masked]>
Date: Wed, 28 Aug 2013 13:48:35 +1000

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
>
> From: *Mary Barnes* <[email-masked] 
> <mailto:[email-masked]>>
> To: "Duckworth, Mark" <[email-masked] 
> <mailto:[email-masked]>>
> Cc: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
>
>
> On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark 
> <[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]>]
>     *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:
>
>     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.

>     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./*
>
[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:
>
>     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.... */
>
>     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. ..."

>       
>
>     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. */
>
>     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] ???

---

From: Mary Barnes <[email-masked]>
Date: Wed, 28 Aug 2013 16:58:58 -0500

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:

>> 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
>> 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
>>
>> From: *Mary Barnes* <[email-masked] <mailto:mary.ietf.barnes@
>> **gmail.com <[email-masked]>>>
>> To: "Duckworth, Mark" <[email-masked] <mailto:Mark.Duckworth@
>> **polycom.com <[email-masked]>>>
>> Cc: Paul Kyzivat <[email-masked] <mailto:[email-masked]>**>
>>
>>
>> On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark <
>> [email-masked] <mailto:Mark.Duckworth@**polycom.com<[email-masked]>>>
>> wrote:
>>
>>     Hi Mary,
>>
>>     *From:*Mary Barnes [mailto:mary.ietf.barnes@**gmail.com<[email-masked]>
>>     <mailto:mary.ietf.barnes@**gmail.com <[email-masked]>>]
[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]

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

>> 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]
>>
>>     (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.
>>
>>
[MB2] That sounds good to me. [/MB]

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

>>     references and RFC 3264 needs to be added.
[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]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 29 Aug 2013 10:00:35 -0500

I apologize if this is a duplicate, but I don't see this in the archives.
 We got an email from the AMS guys this morning and there was email lost
yesterday between 3.30pm PST and 8.55pm PST. So, I'm thinking this was one
of them.

Mary.

---------- Forwarded message ----------
From: Christian Groves <[email-masked]>
Date: Wed, Aug 28, 2013 at 6:49 PM
Subject: Re: [clue] Fwd: Comments on CLUE Framework
To: Mary Barnes <[email-masked]>
Cc: CLUE <[email-masked]>

Hello Mary,

Please see my reply below.

Regards, Christian
..snip..

>     /*[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.... */
>
[CNG] I appreciate CLUE is chartered to specify how CLUE works with SIP. I
don't think anyone wants to preclude the widespread use of CLUE so I think
it is worthwhile to specify that CLUE can only be used with SIP. If its a
question of addition specification etc. I think we can simply some text
saying that we're not working on them: e.g. "Whilst "SIP and SDP O/A" are
discussed it does not prevent CLUE from being used in networks where there
are other call controls however the use of these is not considered nor
described by the framework."