Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt

[Paul Kyzivat <[e-mail]>]

I'm trying to clean up old dangling mail, and came across this one.

On 9/24/13 4:46 PM, Duckworth, Mark wrote:
> 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.

In most cases I think what you say will end up being right.
But there are some troublesome cases that I have considered. (And 
discussed in the past.) Most notably:

There could be a "traditional" TP room - seats for several people in 
front of some big screens, and some cameras pointing at them, ...
There is a single system (endpoint) controlling all that equipment.
This seems like a "site" to me.

People in that room may have their own laptops or tablets. Those systems 
can have a CLUE client. They could connect directly to the same 
conference focus that the room endpoint connects to. They could use 
their private system to share presentations, and maybe to display video 
captures that aren't displayed in the room. (Or that are, in order to 
get a closer view.)

These separate systems will be viewed by the MCU as separate endpoints. 
But should we consider them to be in a separate *site*?

It might be difficult to discover that they are part of the same site. 
And maybe we don't need to. But it might be convenient to be able to 
detect that the person talking in the room is talking about the 
presentation being shared by the separate endpoint that he controls.

Maybe this just highlights that we shouldn't use the term "site", and 
should instead use "endpoint" or "scene" depending on which is important.

	Thanks,
	Paul

> Mark
>
> *From:*[e-mail] [mailto:[e-mail]] *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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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:
>     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.
>
>     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.
>
>         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.
>
>     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
>         <[e-mail] <mailto:[e-mail]>
>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>         wrote:
>
>              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:
>
>                  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
>                  <[e-mail]
>         <mailto:[e-mail]>
>                  <mailto:[e-mail]
>         <mailto:[e-mail]>>
>
>                  <mailto:Christian.Groves@
>         <mailto:Christian.Groves@>__nteczone.com <http://nteczone.com>
>
>
>                  <mailto:[e-mail]
>         <mailto:[e-mail]>>>>
>
>                  wrote:
>
>                       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.
>
>                  [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]
>
>
>                       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
>
>
>                       On 16/09/2013 5:32 AM, Paul Kyzivat wrote:
>
>                           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
>
>                           On 9/2/13 3:50 PM, Paul Kyzivat wrote:
>
>                               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,
>         [e-mail] <mailto:[e-mail]>
>                  <mailto:[e-mail]
>         <mailto:[e-mail]>>
>
>                               <mailto:internet-drafts@ietf.
>         <mailto:internet-drafts@ietf.>__org
>
>
>                  <mailto:[e-mail]
>         <mailto:[e-mail]>>> 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
>
>         <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>>
>
>
>
>                                   There's also a htmlized version
>         available at:
>
>         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>>
>
>                                   A diff from the previous version is
>         available at:
>
>         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>>
>
>
>
>
>                                   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>.
>
>
>
>
>                                   Internet-Drafts are also available by
>         anonymous
>                  FTP at:
>
>         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
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>                  <mailto:[e-mail] <mailto:[e-mail]>>>
>         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
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>                  <mailto:[e-mail] <mailto:[e-mail]>>>
>         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
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>                  <mailto:[e-mail] <mailto:[e-mail]>>>
>         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
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>                  <mailto:[e-mail] <mailto:[e-mail]>>>
>         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
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         https://www.ietf.org/mailman/__listinfo/clue
>                  <https://www.ietf.org/mailman/listinfo/clue>
>
>
>              _________________________________________________
>              clue mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         https://www.ietf.org/mailman/__listinfo/clue
>              <https://www.ietf.org/mailman/listinfo/clue>
>