Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt

From: Mary Barnes <[email-masked]>
Date: Wed, 9 Oct 2013 06:03:43 -0500

Hi Roberta,

Thank you for your review comments. I apologize for the delay in
responding. I've been traveling for the past 3+ weeks and seem to be
processing my emails LIFO.

My responses are below [MB].

Thanks,
Mary.

On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta <[email-masked]>
 wrote:

> Hi all,
>
> in the following some comments to the requirements draft.
>
>
>    - about the interworking telepresence systems
>    In the Introduction section (page 3, third paragraph), it is stated
>    that the purpose of the document is to provide requirements for enabling
>    interworking between *"SIP-based [RFC3261] telepresence systems"*. We
>    should describe/define here in a more precise way these systems, by saying
>    for example that they are "built upon" centralized SIP-based conferencing
>    systems as defined in RFC4353 (the "conference" definition in the following
>    refers to this RFC). We should explicitely mention that we are not dealing
>    with "signaling agnostic" frameworks, if this is the case, i.e. if we
>    leverage SIP as the only signaling protocol for the basic session
>    management.
>
> [MB] Good point.  How about something like the following change:
OLD:
   The purpose of this document is to describe the requirements for a
   specification that enables interworking between different SIP-based
   [RFC3261] telepresence systems, by exchanging and negotiating
   appropriate information.

NEW:
   The purpose of this document is to describe the requirements for a
   specification that enables interworking between different SIP-based
   [RFC3261] telepresence systems by exchanging and negotiating
   appropriate information.  In the context of these requirements and
related
   solutions, the SIP telepresence systems are expected to support the SIP
conferencing
   framework [RFC 4353] and SIP based conference control [RFC 4579] .

>
>
>
>    - about dictating architectural choices
>    In the Introduction section, "*It is not the intention of CLUE to
>    dictate telepresence architectural and implementation choices.*" I
>    would propose to erase "architectural choice" and to leave only
>    "implementation choice". The CLUE framework should provide some reference
>    architecture for SIP-based telepresence systems in order to let them
>    interoperate, so I would not say that CLUE is not intended to dictate
>    architectural choice.
>
> [MB] I agree. [/MB]

>
>    - "Endpoint" definition
>    "*Endpoints can be anything from multiscreen/multicamera rooms to
>    handheld devices.*"
>    I agree that talking about room/site *controllers*, or something
>    similar, it is more appropriate.
>
> [MB] I'll address this one in a separate email since it's come up in other
reviews, as well. [/MB]

>
>
>
>    - about the site characteristics that need to be shared
>    In the Problem statement section, page 6, last paragraph: "*Characteristics
>    may include number, placement, capture/render angle, resolution of
>    cameras and screens, spatial location and audio mixing parameters of
>    microphones. The telepresence multi-stream work seeks to describe the
>    sender situation in a way that allows the receiver to render it
>    realistically, though it may have a different rendering model than** the
>    sender; and for the receiver to provide information to the sender in
>    order to help the sender create adequate content for interworking"*.
>    The last sentence seems to make reference to some rendering features of the
>    receiver (render angles, resolution of screens) and that sounds a bit in
>    contrast with the CLUE philosophy, where the media provider does not care
>    about the rendering capabilities of the media consumer.
>
> [MB] Yes.  I agree - I think we can remove the last part of that sentence
and not lose anything as I think the "allows the receiver to render
realistically" is the important aspect.  [/MB]

>
>    -
>
>
> Minor issues:
>
>    - "*A telepresence session, requires*", comma to be removed
>
> [MB] Will fix. [/MB]

>
>    - must vs MUST: there are several "must" that are not capitalized
>
> [MB] I'll make a pass and ensure we are consistent with capitalizations.
[/MB]

On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta <[email-masked]>wrote:

>  Hi all,
>
> in the following some comments to the requirements draft.
>
>
>    - about the interworking telepresence systems
>    In the Introduction section (page 3, third paragraph), it is stated
>    that the purpose of the document is to provide requirements for enabling
>    interworking between *"SIP-based [RFC3261] telepresence systems"*. We
>    should describe/define here in a more precise way these systems, by saying
>    for example that they are "built upon" centralized SIP-based conferencing
>    systems as defined in RFC4353 (the "conference" definition in the following
>    refers to this RFC). We should explicitely mention that we are not dealing
>    with "signaling agnostic" frameworks, if this is the case, i.e. if we
>    leverage SIP as the only signaling protocol for the basic session
>    management.
>
>
>    - about dictating architectural choices
>    In the Introduction section, "*It is not the intention of CLUE to
>    dictate telepresence architectural and implementation choices.*" I
>    would propose to erase "architectural choice" and to leave only
>    "implementation choice". The CLUE framework should provide some reference
>    architecture for SIP-based telepresence systems in order to let them
>    interoperate, so I would not say that CLUE is not intended to dictate
>    architectural choice.
>
>
>    - "Endpoint" definition
>    "*Endpoints can be anything from multiscreen/multicamera rooms to
>    handheld devices.*"
>    I agree that talking about room/site *controllers*, or something
>    similar, it is more appropriate.
>
>
>    - about the site characteristics that need to be shared
>    In the Problem statement section, page 6, last paragraph: "*Characteristics
>    may include number, placement, capture/render angle, resolution of
>    cameras and screens, spatial location and audio mixing parameters of
>    microphones. The telepresence multi-stream work seeks to describe the
>    sender situation in a way that allows the receiver to render it
>    realistically, though it may have a different rendering model than**the sender; and for
>    the receiver to provide information to the sender in order to help the
>    sender create adequate content for interworking"*. The last sentence
>    seems to make reference to some rendering features of the receiver (render
>    angles, resolution of screens) and that sounds a bit in contrast with the
>    CLUE philosophy, where the media provider does not care about the rendering
>    capabilities of the media consumer.
>
>
> Minor issues:
>
>    - "*A telepresence session, requires*", comma to be removed
>    - must vs MUST: there are several "must" that are not capitalized
>
>
> Regards,
>
> Roberta
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 10 Oct 2013 16:16:08 +1100

Hello,

Please see my comments below.

Regards, Christian

On 9/10/2013 10:03 PM, Mary Barnes wrote:
> On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>       * about the interworking telepresence systems
>         In the Introduction section (page 3, third paragraph), it is
>         stated that the purpose of the document is to provide
>         requirements for enabling interworking between /"SIP-based
>         [RFC3261] telepresence systems"/. We should describe/define
>         here in a more precise way these systems, by saying for
>         example that they are "built upon" centralized SIP-based
>         conferencing systems as defined in RFC4353 (the "conference"
>         definition in the following refers to this RFC). We should
>         explicitely mention that we are not dealing with "signaling
>         agnostic" frameworks, if this is the case, i.e. if we leverage
>         SIP as the only signaling protocol for the basic session
>         management.
>
>    solutions, the SIP telepresence systems are expected to support the 
> SIP conferencing

[CNG] I don't agree that it is expected that telepresence systems 
support RFC4353 and 4579. CLUE should be able to be used without these. 
Especially in the case of point to point CLUE calls. The use of RFC4353 
and RFC4579 shouldn't be precluded however.
>
>       * about dictating architectural choices
>         In the Introduction section, "/It is not the intention of CLUE
>         to dictate telepresence architectural and implementation
>         choices./" I would propose to erase "architectural choice" and
>         to leave only "implementation choice". The CLUE framework
>         should provide some reference architecture for SIP-based
>         telepresence systems in order to let them interoperate, so I
>         would not say that CLUE is not intended to dictate
>         architectural choice.
>
> [MB] I agree. [/MB]

[CNG] I would prefer to leave the existing text. I believe that was the 
original intention.

..snip..

---

From: Mary Barnes <[email-masked]>
Date: Thu, 10 Oct 2013 06:10:38 -0500

My responses below [MB2].

Mary

On Thu, Oct 10, 2013 at 12:16 AM, Christian Groves <
[email-masked]> wrote:

>> On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta <[email-masked]<mailto:
>> roberta.presta@unina.**it <[email-masked]>>> wrote:
>>
>>     Hi all,
>>
> [CNG] I don't agree that it is expected that telepresence systems support
> RFC4353 and 4579. CLUE should be able to be used without these. Especially
> in the case of point to point CLUE calls. The use of RFC4353 and RFC4579
> shouldn't be precluded however.
>
[MB2] I would agree for a point to point, so we adjust the wording to
accommodate that.  However, our WG is explicitly chartered to be based on
SIP Conferencing.  Text from the charter:
  " WG will create specifications for SIP-based conferencing systems"
I would suggest the following new text to be explicit about point to point.
NEW:
   The purpose of this document is to describe the requirements for a
   specification that enables interworking between different SIP-based
   [RFC3261] telepresence systems and endpoints by exchanging and
negotiating
   appropriate information.  In the context of the requirements in this
document and
   related solution documents,  this includes both point to point SIP
sessions as well as SIP based
   conferences as described in the SIP conferencing
   framework [RFC 4353] and the SIP based conference control [RFC 4579]
specifications.

It is important for you to be aware that 4353 is informational, however,
4579 is a BCP, thus it should be supported.
[/MB2]

> [CNG] I would prefer to leave the existing text. I believe that was the
[MB] I don't know what you mean by "original intention"?     We have a WG
deliverable for a framework which does introduce some architectural
concepts.  Clearly, we aren't prescribing implementation choices.  But, we
do lay out a model/architecture/framework for the solution.  I think we
should stick with the text that the majority agrees with. Also, please keep
in mind that this is an informational document, thus it's setting the
context for the solution, but defines nothing normative per se.
[/MB]

>
> ..snip..
>
>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 11 Oct 2013 10:43:14 +1100

Hello Mary,
..snip..
>            appropriate information.  In the context of these
>         requirements and related
>            solutions, the SIP telepresence systems are expected to
>         support the SIP conferencing
>     support RFC4353 and 4579. CLUE should be able to be used without
>     these. Especially in the case of point to point CLUE calls. The
>     use of RFC4353 and RFC4579 shouldn't be precluded however.
>
> accommodate that.  However, our WG is explicitly chartered to be based 
> on SIP Conferencing.  Text from the charter:
>    appropriate information.  In the context of the requirements in 
> this document and
>    framework [RFC 4353] and the SIP based conference control [RFC 
> 4579] specifications.
>
> It is important for you to be aware that 4353 is informational, 
> however, 4579 is a BCP, thus it should be supported.
> [/MB2]

[CNG] I'm happy with your suggestion, it covers the point to point case 
and removes "expected to support".

>     [CNG] I would prefer to leave the existing text. I believe that
>     was the original intention.
>
> [MB] I don't know what you mean by "original intention"?     We have a 
> WG deliverable for a framework which does introduce some architectural 
> concepts.  Clearly, we aren't prescribing implementation choices. 
>  But, we do lay out a model/architecture/framework for the solution. 
>  I think we should stick with the text that the majority agrees with. 
> Also, please keep in mind that this is an informational document, thus 
> it's setting the context for the solution, but defines nothing 
> normative per se.
> [/MB]

[CNG] By original intention I mean the original text "It is not the 
intention of CLUE to dictate telepresence architectural and 
implementation choices." This is the current text we have "stuck" to. 
The change isn't just about removing "architectural" from the 
requirements its also the suggested change to the framework. The current 
framework document describes a framework for a "protocol" not an overall 
architectural description of a SIP telepresence system. I think there's 
enough in the framework rather than adding a discussion on overall SIP 
telepresence system architecture. That work would be non-trivial.

>     [email-masked] <mailto:[email-masked]>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 15 Oct 2013 17:47:56 -0500

Christian,

One last response below [MB3].

Mary.

On Thu, Oct 10, 2013 at 6:43 PM, Christian Groves <
[email-masked]> wrote:

> intention of CLUE to dictate telepresence architectural and implementation
> choices." This is the current text we have "stuck" to. The change isn't
> just about removing "architectural" from the requirements its also the
> suggested change to the framework. The current framework document describes
> a framework for a "protocol" not an overall architectural description of a
> SIP telepresence system. I think there's enough in the framework rather
> than adding a discussion on overall SIP telepresence system architecture.
> That work would be non-trivial.
>
[MB3] Right and removing "architectural" from the sentence is not at all
the same thing as saying that CLUE will define an "overall SIP telepresence
system architecture".  The term "architectural choice" really doesn't mean
anything specific, so by saying we are not doing that, it provides no
information as to what CLUE isn't doing nor does it result in this document
stating that CLUE is making architectural choices.   However, some of us
would interpret architectural choices to be what protocols one uses and
what functional entities use the protocols and how they use those
protocols.  That is very close to what we are doing with the framework.
And, as a matter of fact, that's very much what the term "architecture"
means in the context of IETF - e.g., The Internet Architecture Board (IAB):
 http://www.iab.org/about/iab-overview/
[/MB3]

---

From: Christian Groves <[email-masked]>
Date: Wed, 16 Oct 2013 11:21:41 +1100

Hello Mary,

Please see below.

Regards, Christian

>                         In the Introduction section, "/It is not the
>         intention
>                 of CLUE
>
>         [MB] I don't know what you mean by "original intention"?    
>         We have a WG deliverable for a framework which does introduce
>         some architectural concepts.  Clearly, we aren't prescribing
>         implementation choices.  But, we do lay out a
>         model/architecture/framework for the solution.  I think we
>         should stick with the text that the majority agrees with.
>         Also, please keep in mind that this is an informational
>         document, thus it's setting the context for the solution, but
>         defines nothing normative per se.
>         [/MB]
>
>
>     [CNG] By original intention I mean the original text "It is not
>     the intention of CLUE to dictate telepresence architectural and
>     implementation choices." This is the current text we have "stuck"
>     to. The change isn't just about removing "architectural" from the
>     requirements its also the suggested change to the framework. The
>     current framework document describes a framework for a "protocol"
>     not an overall architectural description of a SIP telepresence
>     system. I think there's enough in the framework rather than adding
>     a discussion on overall SIP telepresence system architecture. That
>     work would be non-trivial.
>
> [MB3] Right and removing "architectural" from the sentence is not at 
> all the same thing as saying that CLUE will define an "overall SIP 
> telepresence system architecture".  The term "architectural choice" 
> really doesn't mean anything specific, so by saying we are not doing 
> that, it provides no information as to what CLUE isn't doing nor does 
> it result in this document stating that CLUE is making architectural 
> choices.   However, some of us would interpret architectural choices 
> to be what protocols one uses and what functional entities use the 
> protocols and how they use those protocols.  That is very close to 
> what we are doing with the framework. And, as a matter of fact, that's 
> very much what the term "architecture" means in the context of IETF - 
> e.g., The Internet Architecture Board (IAB): 
[CNG] I'm not sure what the IAB has to do with CLUE but... I think its 
an issue of the scope of the "architecture." As I mentioned above its 
not so much the deletion of a word its what is intended by that. The 
following sentence was "the CLUE framework should provide some reference 
architecture for SIP-based telepresence systems in order to let them 
interoperate" which you agreed to. I have an issue if the framework 
becomes a general document for describing a SIP telepresence system 
architecture. For a telepresence system there is functionality beyond CLUE.

If it simply describes the architecture of how CLUE relates to 
SIP/SDP/RTP then I would agree that is in the scope of the framework 
document. I don't think it should be a general architecture of all the 
protocols/interface that a SIP Telepresence system may use.

With respect to the issue of "saying what we are not doing" then we may 
as well remove the text regarding implementation choice.

>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 16 Oct 2013 06:42:18 -0500

Yet another round of responses below [MB4].   I would like to hear if
there's anyone else that shares Christian's concerns.  If not, then I will
leave the text with the change based on Roberta's input, which seems
reasonable to me as the document editor.

Thanks,
Mary.

On Tue, Oct 15, 2013 at 7:21 PM, Christian Groves <
[email-masked]> wrote:

>> http://www.iab.org/about/iab-**overview/<http://www.iab.org/about/iab-overview/>
>> [/MB3]
>>
> [CNG] I'm not sure what the IAB has to do with CLUE but... I think its an
> issue of the scope of the "architecture."

[MB4] I was referencing the IAB's use of the term "architecture" - follow
the link and see the context in which the term is used in the IETF.  CLUE
is an IETF WG thus it's entirely appropriate for an IETF WG to discuss
architectures.  [/MB4]

As I mentioned above its not so much the deletion of a word its what is
> intended by that. The following sentence was "the CLUE framework should
> provide some reference architecture for SIP-based telepresence systems in
> order to let them interoperate" which you agreed to. I have an issue if the
> framework becomes a general document for describing a SIP telepresence
> system architecture. For a telepresence system there is functionality
> beyond CLUE.
>
[MB4] I think you are reading way too much into the text in this section of
the document.  It's intended to set the context and has no normative impact
on anything that CLUE is doing.  It's introductory text. [/MB4]

>
> If it simply describes the architecture of how CLUE relates to SIP/SDP/RTP
> then I would agree that is in the scope of the framework document. I don't
> think it should be a general architecture of all the protocols/interface
> that a SIP Telepresence system may use.
>
> With respect to the issue of "saying what we are not doing" then we may as
> well remove the text regarding implementation choice.
>
[MB4] I think the reference to "implementation" choice is important in that
it's highlighting the fact that you can make telepresence systems
interoperable without having to entirely impact a product design.  As you
note we are not designing an entire system. [/MB4]

---

From: Paul Coverdale <[email-masked]>
Date: Wed, 16 Oct 2013 19:18:55 -0400

I'm getting a bit confused after all the multiple in-line comments. What is
the proposed text that we are left with?

..Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: Wednesday, October 16, 2013 7:42 AM
To: Christian Groves
Cc: CLUE
Subject: Re: [clue] comments to
draft-ietf-clue-telepresence-requirements-05.txt

Thanks,

Mary. 

On Tue, Oct 15, 2013 at 7:21 PM, Christian Groves
<[email-masked]> wrote:

Hello Mary,

Please see below.

Regards, Christian

                        to dictate telepresence architectural and
        implementation
                        choices./" I would propose to erase "architectural
                choice" and

                        to leave only "implementation choice". The
        CLUE framework
                        should provide some reference architecture for
        SIP-based
                        telepresence systems in order to let them
                interoperate, so I
                        would not say that CLUE is not intended to dictate
                        architectural choice.

                [MB] I agree. [/MB]

            [CNG] I would prefer to leave the existing text. I believe
        that
            was the original intention.

[MB3] Right and removing "architectural" from the sentence is not at all the
same thing as saying that CLUE will define an "overall SIP telepresence
system architecture".  The term "architectural choice" really doesn't mean
anything specific, so by saying we are not doing that, it provides no
information as to what CLUE isn't doing nor does it result in this document
stating that CLUE is making architectural choices.   However, some of us
would interpret architectural choices to be what protocols one uses and what
functional entities use the protocols and how they use those protocols.
That is very close to what we are doing with the framework. And, as a matter
of fact, that's very much what the term "architecture" means in the context
of IETF - e.g., The Internet Architecture Board (IAB):
http://www.iab.org/about/iab-overview/
[/MB3]

[MB4] I was referencing the IAB's use of the term "architecture" - follow
the link and see the context in which the term is used in the IETF.  CLUE is
an IETF WG thus it's entirely appropriate for an IETF WG to discuss
architectures.  [/MB4]

system architecture. For a telepresence system there is functionality beyond
CLUE.

            ..snip..

---

From: Christian Groves <[email-masked]>
Date: Thu, 17 Oct 2013 13:35:55 +1100

Hello Paul,

The original paragraph was:
" Telepresence systems of different vendors, today, can follow
radically different architectural approaches while offering a similar
user experience. It is not the intention of CLUE to dictate
telepresence architectural and implementation choices. CLUE enables
interoperability between telepresence systems by exchanging
information about the systems' characteristics. Systems can use this
information to control their behavior to allow for interoperability
between those systems."

I believe the proposal is to remove "telepresence architectural and" 
i.e. "It is not the intention of CLUE to dictate implementation choices".

The removal of the text was the first part of the proposal the second 
part was "the CLUE framework should provide some reference architecture 
for SIP-based telepresence systems in order to let them interoperate".

It's this second part that I'm trying to get to the bottom of. 
Architecture has a wide scope (e.g. as covered by F/H.TPS-Arch). 
Architecture could relate to simply where CLUE sits with other protocols 
or it could encompass defining different nodes types, endpoint 
capabilities, etc. i.e. a telepresence system architecture. The first 
sentence of the paragraph to me indicates the wider view and there 
wasn't a proposal to remove this instance. I agree with the current text 
on the view that CLUE shouldn't describe an overall "telepresence 
system" architecture. However I do think that CLUE should describe the 
protocol architecture.

So to cover my concern I would propose to expand the sentence:
"CLUE will not dictate an overall Telepresence system architecture and 
implementation choices however it will describe a protocol architecture 
for CLUE and it relates to other protocols."

I think this is consistent with the framework abstract i.e. "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."

Regards, Christian

On 17/10/2013 10:18 AM, Paul Coverdale wrote:
>
> I’m getting a bit confused after all the multiple in-line comments. 
> What is the proposed text that we are left with?
>
> ..Paul
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Mary Barnes
> *Sent:* Wednesday, October 16, 2013 7:42 AM
> *To:* Christian Groves
> *Cc:* CLUE
> *Subject:* Re: [clue] comments to 
> there's anyone else that shares Christian's concerns. If not, then I 
> will leave the text with the change based on Roberta's input, which 
> seems reasonable to me as the document editor.
>
> Thanks,
>
> Mary.
>
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
> Hello Mary,
>
> Please see below.
>
> Regards, Christian
>
>
>
>
>     WG deliverable for a framework which does introduce
>     [MB3] Right and removing "architectural" from the sentence is not
>     at all the same thing as saying that CLUE will define an "overall
>     SIP telepresence system architecture". The term "architectural
>     choice" really doesn't mean anything specific, so by saying we are
>     not doing that, it provides no information as to what CLUE isn't
>     doing nor does it result in this document stating that CLUE is
>     making architectural choices. However, some of us would interpret
>     architectural choices to be what protocols one uses and what
>     functional entities use the protocols and how they use those
>     protocols. That is very close to what we are doing with the
>     framework. And, as a matter of fact, that's very much what the
>     term "architecture" means in the context of IETF - e.g., The
>     Internet Architecture Board (IAB):
> an issue of the scope of the "architecture."
>
> [MB4] I was referencing the IAB's use of the term "architecture" - 
> follow the link and see the context in which the term is used in the 
> IETF. CLUE is an IETF WG thus it's entirely appropriate for an IETF WG 
> to discuss architectures. [/MB4]
>
>     As I mentioned above its not so much the deletion of a word its
>     what is intended by that. The following sentence was "the CLUE
>     framework should provide some reference architecture for SIP-based
>     telepresence systems in order to let them interoperate" which you
>     agreed to. I have an issue if the framework becomes a general
>     document for describing a SIP telepresence system architecture.
>     For a telepresence system there is functionality beyond CLUE.
>
> [MB4] I think you are reading way too much into the text in this 
> section of the document. It's intended to set the context and has no 
> normative impact on anything that CLUE is doing. It's introductory 
> text. [/MB4]
>
>
>     SIP/SDP/RTP then I would agree that is in the scope of the
>     framework document. I don't think it should be a general
>     architecture of all the protocols/interface that a SIP
>     Telepresence system may use.
>
>     With respect to the issue of "saying what we are not doing" then
>     we may as well remove the text regarding implementation choice.
>
> [MB4] I think the reference to "implementation" choice is important in 
> that it's highlighting the fact that you can make telepresence systems 
> interoperable without having to entirely impact a product design. As 
> you note we are not designing an entire system. [/MB4]
>
>
>         ..snip..
>
>
>         <mailto:[email-masked]>> <mailto:[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 17 Oct 2013 07:58:20 -0500

On Wed, Oct 16, 2013 at 9:35 PM, Christian Groves <
[email-masked]> wrote:

> I believe the proposal is to remove "telepresence architectural and" i.e.
> "It is not the intention of CLUE to dictate implementation choices".
>
> The removal of the text was the first part of the proposal the second part
> was "the CLUE framework should provide some reference architecture for
> SIP-based telepresence systems in order to let them interoperate".
>
> Architecture could relate to simply where CLUE sits with other protocols or
> it could encompass defining different nodes types, endpoint capabilities,
> etc. i.e. a telepresence system architecture. The first sentence of the
> paragraph to me indicates the wider view and there wasn't a proposal to
> remove this instance. I agree with the current text on the view that CLUE
> shouldn't describe an overall "telepresence system" architecture. However I
> do think that CLUE should describe the protocol architecture.

[MB] There was never any intention of adding text for the second. Roberta's
sentence is just explaining why she thinks we should remove the
"architectural" choices from that 1st sentence. [/MB]

> implementation choices however it will describe a protocol architecture for
> CLUE and it relates to other protocols."
>
[MB]  It would have been nice if you had provided your proposed sentence
way earlier in this thread because I had no understanding that you were
proposing that (since Roberta was only proposing to remove the word and NOT
add any new text).  I understood you were just debating removing the
"architectural" choice.  As I have already said, removing the term
"architectural" makes NO implication as to what CLUE is or is not doing in
terms of protocols, etc.  But, if others are okay with the newly proposed
change, that's fine.
[/MB]

>
> I think this is consistent with the framework abstract i.e. "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."
>
[MB] Right - that's in the framework so I'm not sure we need that level of
detail in the *Introduction* to the requirements document. But, I have
already spent way too much time on this circular debate, so as long as
others agree, we can make that change.  [/MB]

>> I’m getting a bit confused after all the multiple in-line comments. What
>> is the proposed text that we are left with?
>>
>> ..Paul
>>
>> *Subject:* Re: [clue] comments to draft-ietf-clue-telepresence-**
>> requirements-05.txt
>>
>>
>> [email-masked] <mailto:Christian.Groves@**nteczone.com<[email-masked]>>>
>> wrote:
>>
>> Hello Mary,
>>
>> Please see below.
>>
>> Regards, Christian
>>
>>
>>
>>
>> [MB4] I think you are reading way too much into the text in this section
>> of the document. It's intended to set the context and has no normative
>> impact on anything that CLUE is doing. It's introductory text. [/MB4]
>>
>>

---

From: Paul Coverdale <[email-masked]>
Date: Thu, 17 Oct 2013 11:42:42 -0400

OK, thanks for the clarification, Christian. I agree with your concern and I
support your new proposed text, with a slight change to correct the English
(addition of a semi-colon and the word "how").

So the new text reads:

"CLUE will not dictate an overall Telepresence system architecture and
implementation choices; however it will describe a protocol architecture for
CLUE and how it relates to other protocols."

...Paul

>-----Original Message-----
>From: Christian Groves [mailto:[email-masked]]
>Sent: Wednesday, October 16, 2013 10:36 PM
>To: Paul Coverdale; 'Mary Barnes'
>Cc: 'CLUE'
>Subject: Re: [clue] comments to draft-ietf-clue-telepresence-
>requirements-05.txt
>
>Hello Paul,
>
>" Telepresence systems of different vendors, today, can follow radically
>different architectural approaches while offering a similar user
>experience. It is not the intention of CLUE to dictate telepresence
>architectural and implementation choices. CLUE enables interoperability
>between telepresence systems by exchanging information about the
>systems' characteristics. Systems can use this information to control
>their behavior to allow for interoperability between those systems."
>
>> I'm getting a bit confused after all the multiple in-line comments.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Oct 2013 18:04:12 -0400

Interesting discussion about what architecture is/isn't.

Ultimately we are describing an actual protocol, and profiling some use 
of other protocols. That protocol references an assortment of entities, 
for instance scenes, capture devices, and sites. (We haven't formally 
defined sites, but we keep talking about them, so we ought to define.) 
ISTM that the high level description of those things and their 
relationships is an architecture for the kinds of telepresence systems 
we are addressing. Is that a "protocol architecture"? Or is it an 
architecture for the systems that the protocol is intended to support?

	Thanks,
	Paul

---

From: Paul Coverdale <[email-masked]>
Date: Thu, 24 Oct 2013 15:09:17 -0400

I don't want to open a discussion on the definition of architecture in
general, but in the context of CLUE my view is that "architecture" should
define all the entities that are required to make the protocol work, and
interoperate with other protocols where necessary, but shouldn't define a
telepresence system itself. 

...Paul

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Paul Kyzivat
>Sent: Wednesday, October 23, 2013 6:04 PM
>To: [email-masked]
>> OK, thanks for the clarification, Christian. I agree with your concern
>> and I support your new proposed text, with a slight change to correct
>> the English (addition of a semi-colon and the word "how").
>>
>> So the new text reads:
>>
>> implementation choices; however it will describe a protocol
>> architecture for CLUE and how it relates to other protocols."
>>
>>
>> ...Paul
>>
>>
>>