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

[Christian Groves <[e-mail]>]

Hello Mary,

Please see my replies below.

Regards, Christian

On 18/09/2013 4:06 AM, 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]>> 
> 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]
[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.

>
>     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]
[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".
>
> [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]
[CNG] My comment re: site was only on the requirement.
>
>
>     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]
[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.

>
>     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]
[CNG] See my above comment.

>
>     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]> 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 <http://tools.ietf.org>.
>
>                 Internet-Drafts are also available by anonymous FTP at:
>                 ftp://ftp.ietf.org/internet-drafts/
>
>                 _______________________________________________
>                 clue mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/clue
>
>
>             _______________________________________________
>             clue mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/clue
>
>
>         _______________________________________________
>         clue mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/clue
>
>
>     _______________________________________________
>     clue mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/clue
>
>