Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt
Michael Hammer <michael.hammer@yaanatech.com> Thu, 19 September 2013 01:17 UTC
Return-Path: <michael.hammer@yaanatech.com>
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 F171511E80D5 for <clue@ietfa.amsl.com>; Wed, 18 Sep 2013 18:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level:
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877]
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 HOwnoQxreZl4 for <clue@ietfa.amsl.com>; Wed, 18 Sep 2013 18:16:57 -0700 (PDT)
Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0C21111E8162 for <clue@ietf.org>; Wed, 18 Sep 2013 18:16:57 -0700 (PDT)
Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 18 Sep 2013 05:53:07 -0700
From: Michael Hammer <michael.hammer@yaanatech.com>
To: "mary.ietf.barnes@gmail.com" <mary.ietf.barnes@gmail.com>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
Thread-Topic: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt
Thread-Index: AQHOskpOGJQ41sUL0UG37BBMOb7RO5nJyJiAgADpbACAACe4AIAACeqAgAAWrQCAAA+fgIAAbTWg
Date: Wed, 18 Sep 2013 12:53:05 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEDAC0F@sc9-ex2k10mb1.corp.yaanatech.com>
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> <5238BB74.6090907@alum.mit.edu> <CAHBDyN6wDySZtz5kpQkVAkOrRoN6oBYiyz0EFH-7TnoxKgnx-A@mail.gmail.com> <5238D6CA.3080500@alum.mit.edu> <CAHBDyN7PbUv8hWAHASutiXQtEwsG4YUODT1B_=B193TuOtpytw@mail.gmail.com>
In-Reply-To: <CAHBDyN7PbUv8hWAHASutiXQtEwsG4YUODT1B_=B193TuOtpytw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.17.100.136]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0011_01CEB44C.7D035E50"
MIME-Version: 1.0
Cc: "clue@ietf.org" <clue@ietf.org>
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: Thu, 19 Sep 2013 01:17:04 -0000
Or make reference to a "site controller". After all, I don't think it is the door or lights or seats that are responding to the signaling. Mike From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] 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 <pkyzivat@alum.mit.edu> 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 <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>> 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 <Christian.Groves@nteczone.com <mailto:Christian.Groves@nteczone.com> <mailto: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> <mailto: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-requir ements <https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requireme nts> <https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requireme nts <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-requir ements-05 <http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requireme nts-05> <http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requireme nts-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>. 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 clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org <mailto:clue@ietf.org>> 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 clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org <mailto:clue@ietf.org>> 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 clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org <mailto:clue@ietf.org>> 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 clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org <mailto:clue@ietf.org>> 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 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] I-D Action: draft-ietf-clue-telepresence-r… internet-drafts
- [clue] Fwd: I-D Action: draft-ietf-clue-teleprese… Mary Barnes
- [clue] WGLC: draft-ietf-clue-telepresence-require… Paul Kyzivat
- [clue] REMINDER!!! WGLC: draft-ietf-clue-telepres… Paul Kyzivat
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Christian Groves
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Mary Barnes
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Paul Kyzivat
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Mary Barnes
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Paul Kyzivat
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Mary Barnes
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Christian Groves
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Michael Hammer
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Duckworth, Mark
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Duckworth, Mark
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Paul Kyzivat
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Mary Barnes