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

[Mary Barnes <[e-mail]>]

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 <[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:Christian.Groves@**nteczone.com<[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:internet-drafts@ietf.**org <[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>.
>>
>>
>>                 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]>
>>                 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]>
>>             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]>
>>         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]>
>>     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]
>> 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<https://www.ietf.org/mailman/listinfo/clue>
>