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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 17 September 2013 20:28 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEF711E8196 for <clue@ietfa.amsl.com>; Tue, 17 Sep 2013 13:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level:
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obTrCHPQG+AW for <clue@ietfa.amsl.com>; Tue, 17 Sep 2013 13:28:53 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id B0AFD11E857D for <clue@ietf.org>; Tue, 17 Sep 2013 13:28:48 -0700 (PDT)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id SBtE1m0050ldTLk53LUd8x; Tue, 17 Sep 2013 20:28:37 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id SLUd1m00e3ZTu2S01LUdMy; Tue, 17 Sep 2013 20:28:37 +0000
Message-ID: <5238BB74.6090907@alum.mit.edu>
Date: Tue, 17 Sep 2013 16:28:36 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: clue@ietf.org
References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> <CAHBDyN6GEXYmOud9+TC47-FYsAVYiL6iEoFgPPFrpZfHdHsCZg@mail.gmail.com>
In-Reply-To: <CAHBDyN6GEXYmOud9+TC47-FYsAVYiL6iEoFgPPFrpZfHdHsCZg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379449717; bh=JVuhwBtwVDmLVoaPC/wsn9G4KnAGUHbyyINuKjRLZOM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DJLQn1n99j/vFs15G9D9fCMvyyEhamq7PLN+1b4AiDpxgZ734BkHeTIBgDxjl0dar cKpZvvMA9/zq/GRzIEA7fzK0mTdhwv9GAm/A+/2z84AnXchwI7JvUfan8V4XGdv1aL J10boVDfYgEYLZnnMQuu7FkcRbFW3AZbMgFDwDNPyxgTODzqy4tEYRlZA0dhaqzgCS y+TCotZoCUyAoKHNvRASgfs266KUodDS2tmIUFyRcf3Ve6znkCrABPmULIEcNMajj0 fjJejeltUfCvudC5SbOZyvjCgvPEw/zYkW9EnqjUnkZZnqNv79dhe+XBSw9AHVF8p9 8shE6mvEWAFIQ==
Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2013 20:29:01 -0000

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
> <Christian.Groves@nteczone.com <mailto:Christian.Groves@nteczone.com>>
> 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, internet-drafts@ietf.org
>             <mailto:internet-drafts@ietf.org> 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>
>
>
>
>                 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>
>
>                 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>
>
>
>
>
>                 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/>
>
>                 _________________________________________________
>                 clue mailing list
>                 clue@ietf.org <mailto:clue@ietf.org>
>                 https://www.ietf.org/mailman/__listinfo/clue
>                 <https://www.ietf.org/mailman/listinfo/clue>
>
>
>             _________________________________________________
>             clue mailing list
>             clue@ietf.org <mailto:clue@ietf.org>
>             https://www.ietf.org/mailman/__listinfo/clue
>             <https://www.ietf.org/mailman/listinfo/clue>
>
>
>         _________________________________________________
>         clue mailing list
>         clue@ietf.org <mailto:clue@ietf.org>
>         https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>
>
>
>     _________________________________________________
>     clue mailing list
>     clue@ietf.org <mailto:clue@ietf.org>
>     https://www.ietf.org/mailman/__listinfo/clue
>     <https://www.ietf.org/mailman/listinfo/clue>
>
>
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>