Subject: [clue] WGLC: draft-ietf-clue-telepresence-requirements-05.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Sep 2013 15:50:50 -0400

With this message I'm announcing the start of WGLC for
draft-ietf-clue-telepresence-requirements-05

This WGLC will last for roughly two weeks, ending at midnight GMT on 
Sunday September 15.

It is important to have decisive results from a WGLC.
(Silence doesn't do it.)
So please, take a last careful look at these requirements and comment. 
If you like these as they are, please say so.

	Thanks,
	Paul (as co-chair)

On 8/30/13 6:39 PM, [email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF.
>
> 	Title           : Requirements for Telepresence Multi-Streams
> 	Author(s)       : Allyn Romanow
>                            Stephen Botzko
>                            Mary Barnes
> 	Filename        : draft-ietf-clue-telepresence-requirements-05.txt
> 	Pages           : 13
> 	Date            : 2013-08-30
>
> Abstract:
>     This memo discusses the requirements for a specification that enables
>     telepresence interoperability, by describing the relationship between
>     multiple RTP streams.  In addition, the problem statement and
>     definitions are also covered herein.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-05
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 15 Sep 2013 15:32:16 -0400

We started WGLC on the requirements two weeks ago.
It has run for two weeks, and there have been *NO* comments!!! :-(

I can't advance this document without better indication of support from 
the WG. So I'm extending this WGLC. I'll be away next weekend, so I will 
let this extension run another two weeks, ending Sunday Sept 29.

We NEED NEED NEED your comments on this. Please review it again, and 
respond either positively or negatively, whether you think it is ready 
to progress.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 17 Sep 2013 14:10:59 +1000

Hello,

Here are my comments to the WGLC:

1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a 
means to identify
                          the extent of individual video captures in
                          three dimensions.

Did we decide whether this was with respect to a "plane of interest" in 
3 dimensions? and/or a volume (i.e. incorporating a depth aspect) in 3 
dimensions? It probably would be good to clarify this in the requirements.

2) General: At different places there are references to particular use 
cases. However this doesn't appear to used consistently. e.g. Regmt-9 
regarding interoperability between endpoints using different numbers of 
streams makes references to the heterogeneous use case. The 
heterogeneous use cases mentions different bit rates etc, however 
Reqmts-8, 7 etc don't mention the use case? It seems to me that if we 
include references to use cases that we should be consistent.

3) REQMT-12: Rather than say "..more than two <sites>" should we use 
"..more than two endpoints". We don't have a definition for "site".

4) General: Do we need to have some text in the document that indicates 
that there may be other unspecified requirements that may be 
implemented? The framework has a number of attributes that aren't 
mentioned as part of the requirements e.g. scene description. Or 
alternatively do we capture this by adding a generic requirement 
regarding description of the content of captures/scenes? The 
requirements are very focussed on spatial/render aspects rather than 
information pertaining to the selection of captures.

5) General: There seems to be a requirement in CLUE of the ability to 
indicate how captures are related to resources. e.g. the STS mechanism 
indicates which captures may be used together (which indicates which 
ones can't be used together) and the CSE that groups capture resources. 
This seems to be an important aspect of CLUE but there doesn't appear to 
be a requirement driving it.

Regards, Christian

On 16/09/2013 5:32 AM, Paul Kyzivat wrote:
> I can't advance this document without better indication of support 
> from the WG. So I'm extending this WGLC. I'll be away next weekend, so 
> I will let this extension run another two weeks, ending Sunday Sept 29.
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 17 Sep 2013 13:06:26 -0500

Hi Christian,

Thanks for taking the time to review this. Comments/responses below [MB].

Mary.

On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves <
[email-masked]> wrote:

> 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a means
> to identify
> Did we decide whether this was with respect to a "plane of interest" in 3
> dimensions? and/or a volume (i.e. incorporating a depth aspect) in 3
[MB] I don't know that this particular detail matters in the requirements
document.  [/MB]

> streams makes references to the heterogeneous use case. The heterogeneous
> use cases mentions different bit rates etc, however Reqmts-8, 7 etc don't
> mention the use case? It seems to me that if we include references to use
> cases that we should be consistent.
>
[MB] Not all requirements can be mapped directly to use cases - e.g., 16,
17 & 18. In the cases, where they can, we probably should. The references
are intended to informative. [/MB]

> "..more than two endpoints". We don't have a definition for "site".
[MB] We don't have an explicit definition but it can certainly be derived
from the context. We use "site" in several other places and just replacing
that with endpoint in those cases won't work - e.g,. in Section 4:  "If
Alice and Bob are at different sites, Alice needs to tell Bob about the
camera and sound equipment arrangement at her site so that Bob's receiver
can create an accurate rendering of her site."
That all said, I think we can replace the use of "site" in that requirement
as that's consistent with all the other requirements.
[/MB]

> that there may be other unspecified requirements that may be implemented?
> The framework has a number of attributes that aren't mentioned as part of
> the requirements e.g. scene description. Or alternatively do we capture
> this by adding a generic requirement regarding description of the content
> of captures/scenes? The requirements are very focussed on spatial/render
> aspects rather than information pertaining to the selection of captures.
>
[MB] I do not believe so.  These are the bare bones requirements - if we
don't have functionality to support these then we haven't done our job.
 However, the solution can certainly define additional functionality, that
doesn't necessarily map to a specific requirement.  The requirements should
not be specifying all the details of the attributes necessary to support
the use cases - that's the objective of the framework. Now, if you think
there is a general requirement that's missing, certainly you can propose
such. Realistically, requirements documents are starting points to seed the
solution work. Once the solution is started unless the WG thinks a
requirement can't be met, it's not necessarily productive to try to make
the requirements document absolutely complete.  Indeed, a number of WGs
actually never publish requirements documents, but rather just cache them
in an appendix for historical purposes. [/MB]

> indicates which captures may be used together (which indicates which ones
> can't be used together) and the CSE that groups capture resources. This
> seems to be an important aspect of CLUE but there doesn't appear to be a
> requirement driving it.
>
[MB] As I mentioned previously, we don't need to have a requirement to
justify every aspect of the solution.   We don't want to get into having to
define capture scene entries, etc. in the requirements.   We don't need to
backwards engineer the requirements to match the solution.  [/MB]

>> respond either positively or negatively, whether you think it is ready to
>> progress.
>>
>>     Thanks,
>>     Paul
>>
>>> draft-ietf-clue-telepresence-**requirements-05
>>>
>>>>     Filename        : draft-ietf-clue-telepresence-**
>>>> requirements-05.txt
>>>>     Pages           : 13
>>>>     Date            : 2013-08-30
>>>>
>>>> Abstract:
>>>> https://datatracker.ietf.org/**doc/draft-ietf-clue-**
>>>> telepresence-requirements<https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements>
>>>>
>>>>
>>>> http://tools.ietf.org/html/**draft-ietf-clue-telepresence-**
>>>> requirements-05<http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05>
>>>>
>>>> http://www.ietf.org/rfcdiff?**url2=draft-ietf-clue-**
>>>> telepresence-requirements-05<http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-05>
>>>>
>>>>
>>>>
>>>> ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts/>
>>>>
>>>> ______________________________**_________________
>>>> clue mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>
>>>>
>>> ______________________________**_________________
>>> clue mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>
>>>
>> ______________________________**_________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Sep 2013 16:28:36 -0400

Mary,

IIUC, you are proposing to make a change from "site" to "endpoint" in 
Reqmnt-12, and otherwise leave things alone?

	Thanks,
	Paul

On 9/17/13 2:06 PM, Mary Barnes wrote:
> On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hello,
>
>     Did we decide whether this was with respect to a "plane of interest"
>     in 3 dimensions? and/or a volume (i.e. incorporating a depth aspect)
>     in 3 dimensions? It probably would be good to clarify this in the
>     requirements.
>
> [MB] I don't know that this particular detail matters in the
> requirements document.  [/MB]
>
>
>     2) General: At different places there are references to particular
>     use cases. However this doesn't appear to used consistently. e.g.
>     Regmt-9 regarding interoperability between endpoints using different
>     numbers of streams makes references to the heterogeneous use case.
>     The heterogeneous use cases mentions different bit rates etc,
>     however Reqmts-8, 7 etc don't mention the use case? It seems to me
>     that if we include references to use cases that we should be consistent.
>
> [MB] Not all requirements can be mapped directly to use cases - e.g.,
> 16, 17 & 18. In the cases, where they can, we probably should. The
> references are intended to informative. [/MB]
>
>
> [MB] We don't have an explicit definition but it can certainly be
> derived from the context. We use "site" in several other places and just
> replacing that with endpoint in those cases won't work - e.g,. in
> Section 4:  "If Alice and Bob are at different sites, Alice needs to
> tell Bob about the camera and sound equipment arrangement at her site so
> that Bob's receiver can create an accurate rendering of her site."
> That all said, I think we can replace the use of "site" in that
> requirement as that's consistent with all the other requirements.
> [/MB]
>
>
>     4) General: Do we need to have some text in the document that
>     indicates that there may be other unspecified requirements that may
>     be implemented? The framework has a number of attributes that aren't
>   However, the solution can certainly define additional functionality,
> that doesn't necessarily map to a specific requirement.  The
> requirements should not be specifying all the details of the attributes
> necessary to support the use cases - that's the objective of the
> framework. Now, if you think there is a general requirement that's
> missing, certainly you can propose such. Realistically, requirements
> documents are starting points to seed the solution work. Once the
> solution is started unless the WG thinks a requirement can't be met,
> it's not necessarily productive to try to make the requirements document
> absolutely complete.  Indeed, a number of WGs actually never publish
> requirements documents, but rather just cache them in an appendix for
> historical purposes. [/MB]
>
>
>     5) General: There seems to be a requirement in CLUE of the ability
>     to indicate how captures are related to resources. e.g. the STS
>     mechanism indicates which captures may be used together (which
>     indicates which ones can't be used together) and the CSE that groups
>     capture resources. This seems to be an important aspect of CLUE but
>     there doesn't appear to be a requirement driving it.
>
> justify every aspect of the solution.   We don't want to get into having
> to define capture scene entries, etc. in the requirements.   We don't
> need to backwards engineer the requirements to match the solution.  [/MB]
>
>
>     Regards, Christian
>
>
>         I can't advance this document without better indication of
>         support from the WG. So I'm extending this WGLC. I'll be away
>         next weekend, so I will let this extension run another two
>         weeks, ending Sunday Sept 29.
>
>         We NEED NEED NEED your comments on this. Please review it again,
>         and respond either positively or negatively, whether you think
>         it is ready to progress.
>
>              Thanks,
>              Paul
>
>             draft-ietf-clue-telepresence-__requirements-05
>
>             On 8/30/13 6:39 PM, [email-masked]
>             <mailto:[email-masked]> wrote:
>
>
>                 A New Internet-Draft is available from the on-line
>                 Internet-Drafts
>                 directories.
>                    This draft is a work item of the ControLling mUltiple
>                 streams for
>                 tElepresence Working Group of the IETF.
>
>                      Filename        :
>                 draft-ietf-clue-telepresence-__requirements-05.txt
>                      Pages           : 13
>                      Date            : 2013-08-30
>
>                 Abstract:
>                 https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requirements
>                 <https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements>
>
>
>
>                 http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05
>                 <http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05>
>
>                 http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requirements-05
>                 <http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-05>
>
>
>
>
>                 Please note that it may take a couple of minutes from
>                 the time of
>                 submission
>                 until the htmlized version and diff are available at
>                 tools.ietf.org <http://tools.ietf.org>.
>
>                 ftp://ftp.ietf.org/internet-__drafts/
>                 <ftp://ftp.ietf.org/internet-drafts/>
>
>                 _________________________________________________
>                 clue mailing list
>                 [email-masked] <mailto:[email-masked]>
>                 https://www.ietf.org/mailman/__listinfo/clue
>                 <https://www.ietf.org/mailman/listinfo/clue>
>
>
>             _________________________________________________
>             clue mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/__listinfo/clue
>             <https://www.ietf.org/mailman/listinfo/clue>
>
>
>         _________________________________________________
>         clue mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>
>
>
>     _________________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/clue
>     <https://www.ietf.org/mailman/listinfo/clue>
>
>
>
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 17 Sep 2013 16:04:05 -0500

Yes.  There are other requirements using the term site.  If you look at the
definition of "endpoint", there is the following statement:
            Endpoints can be anything from
multiscreen/multicamera rooms to handheld devices.

So, I think we are using site to refer explicitly/only to
multiscreen/multicamera
rooms. Maybe the easiest thing to do is to just add a parenthetical comment
in that sentence like the following:

      Endpoints can be anything from
      multiscreen/multicamera rooms (referred to as "sites") to
handheld devices.

Then, I do think it is appropriate to change the word "site" in REQMT-12 to
"endpoint" as the intent of the requirement should also to endpoints other
than multiscreen/multicamera rooms.  I think the use of "site" in the other
requirements is okay.

Mary.

On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat <[email-masked]> wrote:

>> <[email-masked] <mailto:Christian.Groves@**nteczone.com<[email-masked]>
>> >>
>>
>> wrote:
>>
>>     Hello,
>>
>>             draft-ietf-clue-telepresence-_**_requirements-05
>>
>>
>>             <mailto:internet-drafts@ietf.**org <[email-masked]>>
>> wrote:
>>
>>
>>                 draft-ietf-clue-telepresence-_**_requirements-05.txt
>>
>>                      Pages           : 13
>>                      Date            : 2013-08-30
>>
>>                 Abstract:
>>                 https://datatracker.ietf.org/_**_doc/draft-ietf-clue-__**
>> telepresence-requirements<https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requirements>
>>
>>                 <https://datatracker.ietf.org/**doc/draft-ietf-clue-**
>>                 http://tools.ietf.org/html/__**
>> draft-ietf-clue-telepresence-_**_requirements-05<http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05>
>>
>>                 <http://tools.ietf.org/html/**
>> draft-ietf-clue-telepresence-**requirements-05<http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05>
>> >
>>
>>                 http://www.ietf.org/rfcdiff?__**url2=draft-ietf-clue-__**
>> telepresence-requirements-05<http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requirements-05>
>>
>>                 <http://www.ietf.org/rfcdiff?**url2=draft-ietf-clue-**
>>                 ftp://ftp.ietf.org/internet-__**drafts/<ftp://ftp.ietf.org/internet-__drafts/>
>>                 <ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts/>
>> >
>>
>>                 ______________________________**___________________
>>                 clue mailing list
>>                 https://www.ietf.org/mailman/_**_listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>                 <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>> >
>>
>>
>>             ______________________________**___________________
>>             clue mailing list
>>             https://www.ietf.org/mailman/_**_listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>             <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>> >
>>
>>
>>         ______________________________**___________________
>>         clue mailing list
>>         https://www.ietf.org/mailman/_**_listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>         <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>> >
>>
>>
>>     ______________________________**___________________
>>     clue mailing list
>>     https://www.ietf.org/mailman/_**_listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>     <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>> >
>>
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Sep 2013 18:25:14 -0400

Mary,

On 9/17/13 5:04 PM, Mary Barnes wrote:
> Yes.  There are other requirements using the term site.  If you look at
> the definition of "endpoint", there is the following statement:
> multiscreen/multicamera rooms.

Are we? I think even then we are really talking about endpoints, but 
with our design center biased towards multiscreen/multicamera rooms.

E.g., when we are doing "site switching", a CLUE compatible cell phone 
is still going to be treated as a site, together with the telepresence 
"rooms" in the session.

I'm not aware of *anything* that is specific to multiscreen/multicamera 
endpoints.

> Maybe the easiest thing to do is to just
> add a parenthetical comment in that sentence like the following:
>
>        multiscreen/multicamera rooms (referred to as "sites") to handheld devices.

Wouldn't that confuse the definition of site switching?

	Thanks,
	Paul

> Then, I do think it is appropriate to change the word "site" in REQMT-12
> to "endpoint" as the intent of the requirement should also to endpoints
> other than multiscreen/multicamera rooms.  I think the use of "site" in
> the other requirements is okay.

> Mary.
>
>
> On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Mary,
>
>     IIUC, you are proposing to make a change from "site" to "endpoint"
>     in Reqmnt-12, and otherwise leave things alone?
>
>              Thanks,
>              Paul
>
>
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>         wrote:
>
>              Hello,
>
>                      draft-ietf-clue-telepresence-____requirements-05
>
>
>                      So please, take a last careful look at these
>         requirements
>                      and comment.
>         <mailto:[email-masked]>
>                      <mailto:[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>
>                               Title           : Requirements for
>         Telepresence
>                          Multi-Streams
>         draft-ietf-clue-telepresence-____requirements-05.txt
>
>                               Pages           : 13
>                               Date            : 2013-08-30
>
>                          Abstract:
>                               telepresence interoperability, by
>         describing the
>                          relationship between
>                               multiple RTP streams.  In addition, the
>         problem
>                          statement and
>         https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-requirements
>         <https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requirements>
>
>
>         <https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requirements
>         <https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements>>
>
>
>
>         http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requirements-05
>         <http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05>
>
>
>         <http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05
>         <http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05>>
>
>         http://www.ietf.org/rfcdiff?____url2=draft-ietf-clue-____telepresence-requirements-05
>         <http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requirements-05>
>
>
>         <http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requirements-05
>         <http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-05>>
>
>
>
>
>         tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>.
>
>
>         ftp://ftp.ietf.org/internet-____drafts/
>         <ftp://ftp.ietf.org/internet-__drafts/>
>                          <ftp://ftp.ietf.org/internet-__drafts/
>         <ftp://ftp.ietf.org/internet-drafts/>>
>
>                          ___________________________________________________
>                          clue mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/clue
>         <https://www.ietf.org/mailman/__listinfo/clue>
>                          <https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>>
>
>
>                      ___________________________________________________
>                      clue mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/clue
>         <https://www.ietf.org/mailman/__listinfo/clue>
>                      <https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>>
>
>
>                  ___________________________________________________
>                  clue mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/clue
>         <https://www.ietf.org/mailman/__listinfo/clue>
>                  <https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>>
>
>
>              ___________________________________________________
>              clue mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/clue
>         <https://www.ietf.org/mailman/__listinfo/clue>
>              <https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>>
>
>
>
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 17 Sep 2013 18:21:09 -0500

On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat <[email-masked]> wrote:

> Are we? I think even then we are really talking about endpoints, but with
> our design center biased towards multiscreen/multicamera rooms.

> E.g., when we are doing "site switching", a CLUE compatible cell phone is
> still going to be treated as a site, together with the telepresence "rooms"
> in the session.
>
[MB] Actually, we don't define "site" in the CLUE framework either (and the
word appears 89 times in the use cases).   So, maybe we *should* define
site and leave most of the requirements alone.  I think the word conveys
the concept well and I think we lose something if we change to endpoint in
many cases, which we should do consistently if we propose to do so in the
requirements document.    [/MB]

>> <mailto:[email-masked]>**> wrote:
>>
>>     Mary,
>>
>>         <mailto:Christian.Groves@**nteczone.com<[email-masked]>
>> >
>>         <mailto:Christian.Groves@__nte**czone.com <http://nteczone.com>
>>
>>         <mailto:Christian.Groves@**nteczone.com<[email-masked]>
>> >>>
>>
>>         wrote:
>>
>>              Hello,
>>
>>                      draft-ietf-clue-telepresence-_**___requirements-05
>>
>>
>>
>>                      <mailto:[email-masked]**_org
>>
>>         <mailto:internet-drafts@ietf.**org <[email-masked]>>>
>> wrote:
>>
>>
>>         draft-ietf-clue-telepresence-_**___requirements-05.txt
>>
>>
>>                               Pages           : 13
>>                               Date            : 2013-08-30
>>
>>                          Abstract:
>>         https://datatracker.ietf.org/_**___doc/draft-ietf-clue-____**
>> telepresence-requirements<https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-requirements>
>>         <https://datatracker.ietf.org/**__doc/draft-ietf-clue-__**
>>         <https://datatracker.ietf.org/**__doc/draft-ietf-clue-__**
>>         http://tools.ietf.org/html/___**_draft-ietf-clue-telepresence-**
>> ____requirements-05<http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requirements-05>
>>         <http://tools.ietf.org/html/__**draft-ietf-clue-telepresence-_**
>> _requirements-05<http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05>
>> >
>>
>>
>>
>>         <http://tools.ietf.org/html/__**draft-ietf-clue-telepresence-_**
>> _requirements-05<http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05>
>>         <http://tools.ietf.org/html/**draft-ietf-clue-telepresence-**
>>         http://www.ietf.org/rfcdiff?__**__url2=draft-ietf-clue-____**
>> telepresence-requirements-05<http://www.ietf.org/rfcdiff?____url2=draft-ietf-clue-____telepresence-requirements-05>
>>         <http://www.ietf.org/rfcdiff?_**_url2=draft-ietf-clue-__**
>>         <http://www.ietf.org/rfcdiff?_**_url2=draft-ietf-clue-__**
>>         ftp://ftp.ietf.org/internet-__**__drafts/<ftp://ftp.ietf.org/internet-____drafts/>
>>         <ftp://ftp.ietf.org/internet-_**_drafts/<ftp://ftp.ietf.org/internet-__drafts/>
>> >
>>                          <ftp://ftp.ietf.org/internet-_**_drafts/<ftp://ftp.ietf.org/internet-__drafts/>
>>                          ______________________________**
>> _____________________
>>                          clue mailing list
>>         https://www.ietf.org/mailman/_**___listinfo/clue<https://www.ietf.org/mailman/____listinfo/clue>
>>         <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>> >
>>                          <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>                      ______________________________**
>> _____________________
>>                      clue mailing list
>>         https://www.ietf.org/mailman/_**___listinfo/clue<https://www.ietf.org/mailman/____listinfo/clue>
>>         <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>> >
>>                      <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>                  ______________________________**_____________________
>>                  clue mailing list
>>         https://www.ietf.org/mailman/_**___listinfo/clue<https://www.ietf.org/mailman/____listinfo/clue>
>>         <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>> >
>>                  <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>              ______________________________**_____________________
>>              clue mailing list
>>         https://www.ietf.org/mailman/_**___listinfo/clue<https://www.ietf.org/mailman/____listinfo/clue>
>>         <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>> >
>>
>>              <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 Sep 2013 10:15:47 +1000

Hello Mary,

Please see my replies below.

Regards, Christian

On 18/09/2013 4:06 AM, Mary Barnes wrote:
>     1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support
>     a means to identify
>     Did we decide whether this was with respect to a "plane of
>     interest" in 3 dimensions? and/or a volume (i.e. incorporating a
>     depth aspect) in 3 dimensions? It probably would be good to
>     clarify this in the requirements.
>
[CNG] I think that a requirement should be clear. Someone reads the 
framework and checks it against the requirement, did we meet the 
requirement or not? The way the requirement is written we can't say.

>     Regmt-9 regarding interoperability between endpoints using
>     different numbers of streams makes references to the heterogeneous
>     use case. The heterogeneous use cases mentions different bit rates
>     etc, however Reqmts-8, 7 etc don't mention the use case? It seems
>     to me that if we include references to use cases that we should be
>     consistent.
>
[CNG] I agree, if we can we probably should. I think consistency is the 
key. I think it would be good to add a sentence to the draft with 
respect to your comment that the references are intended to be informative.

>
>     3) REQMT-12: Rather than say "..more than two <sites>" should we
>     use "..more than two endpoints". We don't have a definition for
>     "site".
>
> derived from the context. We use "site" in several other places and 
> just replacing that with endpoint in those cases won't work - e.g,. in 
> tell Bob about the camera and sound equipment arrangement at her site 
> so that Bob's receiver can create an accurate rendering of her site."
[CNG] My comment re: site was only on the requirement.
>     indicates that there may be other unspecified requirements that
>     may be implemented? The framework has a number of attributes that
>     aren't mentioned as part of the requirements e.g. scene
>     description. Or alternatively do we capture this by adding a
>     generic requirement regarding description of the content of
>     captures/scenes? The requirements are very focussed on
>     spatial/render aspects rather than information pertaining to the
>     selection of captures.
>
> [MB] I do not believe so.  These are the bare bones requirements - if 
> we don't have functionality to support these then we haven't done our 
> job.  However, the solution can certainly define additional 
> functionality, that doesn't necessarily map to a specific requirement. 
>  The requirements should not be specifying all the details of the 
> attributes necessary to support the use cases - that's the objective 
> of the framework. Now, if you think there is a general requirement 
> that's missing, certainly you can propose such. Realistically, 
> requirements documents are starting points to seed the solution work. 
> Once the solution is started unless the WG thinks a requirement can't 
> be met, it's not necessarily productive to try to make the 
> requirements document absolutely complete.  Indeed, a number of WGs 
> actually never publish requirements documents, but rather just cache 
> them in an appendix for historical purposes. [/MB]
[CNG] I've got no problem with your explanation. If that's how the group 
sees the requirements then that's OK however I think we should document 
in the draft what the objective is and how its meant to be interpreted. 
We have to remember that someone may read the draft(RFC) in the future 
who doesn't have the benefit of a couple years involvement on the CLUE 
WG email lists. It should be clear to them why there is a difference 
between the requirements and the other documents.

>     indicates which ones can't be used together) and the CSE that
>     groups capture resources. This seems to be an important aspect of
>     CLUE but there doesn't appear to be a requirement driving it.
>
> justify every aspect of the solution.   We don't want to get into 
> having to define capture scene entries, etc. in the requirements.   We 
> don't need to backwards engineer the requirements to match the 
> solution.  [/MB]
[CNG] See my above comment.

>         We NEED NEED NEED your comments on this. Please review it
>         again, and respond either positively or negatively, whether
>         you think it is ready to progress.
>
>             Thanks,
>             Paul
>
>                   This draft is a work item of the ControLling
>                 mUltiple streams for
>                 draft-ietf-clue-telepresence-requirements-05.txt
>                     Pages           : 13
>                     Date            : 2013-08-30
>
>                 Abstract:

---

From: Michael Hammer <[email-masked]>
Date: Wed, 18 Sep 2013 12:53:05 +0000

Or make reference to a "site controller".

After all, I don't think it is the door or lights or seats that are
responding to the signaling.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: Tuesday, September 17, 2013 7:21 PM
To: Paul Kyzivat
Cc: CLUE
Subject: Re: [clue] REMINDER!!! WGLC:
draft-ietf-clue-telepresence-requirements-05.txt

Mary,

[MB] Actually, we don't define "site" in the CLUE framework either (and the
word appears 89 times in the use cases).   So, maybe we *should* define site
and leave most of the requirements alone.  I think the word conveys the
concept well and I think we lose something if we change to endpoint in many
cases, which we should do consistently if we propose to do so in the
requirements document.    [/MB] 

       Endpoints can be anything from
       multiscreen/multicamera rooms (referred to as "sites") to handheld
devices.

        Thanks,
        Paul

Mary.

    Mary,

             Thanks,
             Paul

        Hi Christian,

        Thanks for taking the time to review this. Comments/responses
        below [MB].

        Mary.

        wrote:

             Hello,

             1) Reqmt-1D - With regards to reqmt-1d: The solution MUST
        support a
             means to identify
                                       the extent of individual video
        captures in
                                       three dimensions.

             Did we decide whether this was with respect to a "plane of
        interest"
             in 3 dimensions? and/or a volume (i.e. incorporating a
        depth aspect)
             in 3 dimensions? It probably would be good to clarify this
        in the
             requirements.

             2) General: At different places there are references to
        particular
             use cases. However this doesn't appear to used
        consistently. e.g.
             Regmt-9 regarding interoperability between endpoints using
        different
             numbers of streams makes references to the heterogeneous
        use case.
             The heterogeneous use cases mentions different bit rates etc,
             however Reqmts-8, 7 etc don't mention the use case? It
        seems to me
             that if we include references to use cases that we should
        be consistent.

        [MB] Not all requirements can be mapped directly to use cases -
        e.g.,
        16, 17 & 18. In the cases, where they can, we probably should. The
        references are intended to informative. [/MB]

             3) REQMT-12: Rather than say "..more than two <sites>"
        should we use
             "..more than two endpoints". We don't have a definition for
        "site".

        [MB] We don't have an explicit definition but it can certainly be
        derived from the context. We use "site" in several other places
        and just
        replacing that with endpoint in those cases won't work - e.g,. in
        Section 4:  "If Alice and Bob are at different sites, Alice needs to
        tell Bob about the camera and sound equipment arrangement at her
        site so
        that Bob's receiver can create an accurate rendering of her site."
        That all said, I think we can replace the use of "site" in that
        requirement as that's consistent with all the other requirements.
        [/MB]

             4) General: Do we need to have some text in the document that
             indicates that there may be other unspecified requirements
        that may
             be implemented? The framework has a number of attributes
        that aren't
             mentioned as part of the requirements e.g. scene
        description. Or
             alternatively do we capture this by adding a generic
        requirement
             regarding description of the content of captures/scenes? The
             requirements are very focussed on spatial/render aspects
        rather than
             information pertaining to the selection of captures.

        [MB] I do not believe so.  These are the bare bones requirements
        - if we
        don't have functionality to support these then we haven't done
        our job.
           However, the solution can certainly define additional
        functionality,
        that doesn't necessarily map to a specific requirement.  The
        requirements should not be specifying all the details of the
        attributes
        necessary to support the use cases - that's the objective of the
        framework. Now, if you think there is a general requirement that's
        missing, certainly you can propose such. Realistically, requirements
        documents are starting points to seed the solution work. Once the
        solution is started unless the WG thinks a requirement can't be met,
        it's not necessarily productive to try to make the requirements
        document
        absolutely complete.  Indeed, a number of WGs actually never publish
        requirements documents, but rather just cache them in an
        appendix for
        historical purposes. [/MB]

             5) General: There seems to be a requirement in CLUE of the
        ability
             to indicate how captures are related to resources. e.g. the STS
             mechanism indicates which captures may be used together (which
             indicates which ones can't be used together) and the CSE
        that groups
             capture resources. This seems to be an important aspect of
        CLUE but
             there doesn't appear to be a requirement driving it.

        [MB] As I mentioned previously, we don't need to have a
        requirement to
        justify every aspect of the solution.   We don't want to get
        into having
        to define capture scene entries, etc. in the requirements.   We
        don't
        need to backwards engineer the requirements to match the
        solution.  [/MB]

             Regards, Christian

                 We started WGLC on the requirements two weeks ago.
                 It has run for two weeks, and there have been *NO*
        comments!!! :-(

                 I can't advance this document without better indication of
                 support from the WG. So I'm extending this WGLC. I'll
        be away
                 next weekend, so I will let this extension run another two
                 weeks, ending Sunday Sept 29.

                 We NEED NEED NEED your comments on this. Please review
        it again,
                 and respond either positively or negatively, whether
        you think
                 it is ready to progress.

                      Thanks,
                      Paul

                     This WGLC will last for roughly two weeks, ending at
                     midnight GMT on
                     Sunday September 15.

                           Thanks,
                           Paul (as co-chair)

        mUltiple

                              Title           : Requirements for
        Telepresence
                         Multi-Streams

                              Pages           : 13
                              Date            : 2013-08-30

                         Abstract:
                              This memo discusses the requirements for a
                         specification that enables
                              telepresence interoperability, by
        describing the
                         relationship between
                              multiple RTP streams.  In addition, the
        problem
                         statement and
                              definitions are also covered herein.

https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-requir
ements
 
<https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requireme
nts>

<https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requireme
nts

http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requirements
-05

 

http://www.ietf.org/rfcdiff?____url2=draft-ietf-clue-____telepresence-requir
ements-05
 
<http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requireme
nts-05>

<http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requireme
nts-05
 
<http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-
05>>

                         Please note that it may take a couple of
        minutes from
                         the time of
                         submission
                         until the htmlized version and diff are
        available at

                         Internet-Drafts are also available by anonymous
        FTP at:

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 24 Sep 2013 15:09:29 -0700

Hi Paul,

I think the requirements document is ready to progress.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Sunday, September 15, 2013 3:32 PM
> To: [email-masked]
> Subject: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-
> requirements-05.txt
> 
> I can't advance this document without better indication of support from the
> WG. So I'm extending this WGLC. I'll be away next weekend, so I will let this
> extension run another two weeks, ending Sunday Sept 29.
> 
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> >> tools.ietf.org.
> >>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 24 Sep 2013 13:46:39 -0700

I always thought "site" and "endpoint" are synonymous.  I don't know what the difference would be.  I was not using "site" to refer only to multiscreen/multicamera rooms.

Mark

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Tuesday, September 17, 2013 7:21 PM
To: Paul Kyzivat
Cc: CLUE
Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt

On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
Mary,

Are we? I think even then we are really talking about endpoints, but with our design center biased towards multiscreen/multicamera rooms.

E.g., when we are doing "site switching", a CLUE compatible cell phone is still going to be treated as a site, together with the telepresence "rooms" in the session.
[MB] Actually, we don't define "site" in the CLUE framework either (and the word appears 89 times in the use cases).   So, maybe we *should* define site and leave most of the requirements alone.  I think the word conveys the concept well and I think we lose something if we change to endpoint in many cases, which we should do consistently if we propose to do so in the requirements document.    [/MB]

I'm not aware of *anything* that is specific to multiscreen/multicamera endpoints.

        Thanks,
        Paul

Mary.

On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Mary,

             Thanks,
             Paul

        Hi Christian,

        Mary.

        On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves
        <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>
        <mailto:Christian.Groves@<mailto:Christian.Groves@>__nteczone.com<http://nteczone.com>

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

        wrote:

             Hello,

             Regards, Christian

                      Thanks,
                      Paul

                           Thanks,
                           Paul (as co-chair)

                     On 8/30/13 6:39 PM, [email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>
                     <mailto:internet-drafts@ietf.<mailto:internet-drafts@ietf.>__org

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

                              Title           : Requirements for
        Telepresence
                         Multi-Streams

                              Pages           : 13
                              Date            : 2013-08-30

                         Abstract:

                         Please note that it may take a couple of
        minutes from
                         the time of
                         submission
                         until the htmlized version and diff are
        available at
        tools.ietf.org<http://tools.ietf.org> <http://tools.ietf.org> <http://tools.ietf.org>.

                         ___________________________________________________
                         clue mailing list
        [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
        https://www.ietf.org/mailman/____listinfo/clue
        <https://www.ietf.org/mailman/__listinfo/clue>
                         <https://www.ietf.org/mailman/__listinfo/clue
        <https://www.ietf.org/mailman/listinfo/clue>>

                     ___________________________________________________
                     clue mailing list
        [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
        https://www.ietf.org/mailman/____listinfo/clue
        <https://www.ietf.org/mailman/__listinfo/clue>
                     <https://www.ietf.org/mailman/__listinfo/clue
        <https://www.ietf.org/mailman/listinfo/clue>>

                 ___________________________________________________
                 clue mailing list
        [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
        https://www.ietf.org/mailman/____listinfo/clue
        <https://www.ietf.org/mailman/__listinfo/clue>
                 <https://www.ietf.org/mailman/__listinfo/clue
        <https://www.ietf.org/mailman/listinfo/clue>>

             ___________________________________________________
             clue mailing list
        [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
        https://www.ietf.org/mailman/____listinfo/clue
        <https://www.ietf.org/mailman/__listinfo/clue>

        _________________________________________________
        clue mailing list
        [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        https://www.ietf.org/mailman/__listinfo/clue
        <https://www.ietf.org/mailman/listinfo/clue>

    _________________________________________________
    clue mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/__listinfo/clue
    <https://www.ietf.org/mailman/listinfo/clue>