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

[Christian Groves <[e-mail]>]

Hello Mark,

A site could be thought of as a building. I.e. the Polycom site in 
Andover has several telepresence endpoints.

Regards,
Christian

On 25/09/2013 10:31 PM, Mark Duckworth wrote:
> My emails to this list from my polycom address are not getting 
> through, so I'm trying from a different account. Duplicate messages 
> might show up later.
>
> 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:*[e-mail] <mailto:[e-mail]>
>     [mailto:[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>
>
>
>
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue