Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt
Mark Duckworth <mrducky@gmail.com> Wed, 25 September 2013 12:31 UTC
Return-Path: <mrducky@gmail.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 DEA6221F94FA for <clue@ietfa.amsl.com>; Wed, 25 Sep 2013 05:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 Tw0BSER6-5GC for <clue@ietfa.amsl.com>; Wed, 25 Sep 2013 05:31:31 -0700 (PDT)
Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 99FD421F9425 for <clue@ietf.org>; Wed, 25 Sep 2013 05:31:30 -0700 (PDT)
Received: by mail-ve0-f182.google.com with SMTP id oy12so4526022veb.41 for <clue@ietf.org>; Wed, 25 Sep 2013 05:31:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CnDuPmftu7shzMSEejxQHcbGzGExkde6+Y239Ih4OSI=; b=QxuylbajW54w4NW9V2vJryQ4TwlNaimBSD5t4ZYwi0XvhqlCRbusXQNDQKSEicmgaI Rp7ywysaOOl+7TC3sqGnBxBVNFyGqpu8XLjQOPjuHkLiI5fYxBKmz9Mbzso7DZmkQewT PB9psnuc11oj9eml8nIrYgu5jGeorxfvlg5Ai7XNOOIcDFVzycffHHGZ8Hk0cG4jCqzn iQYxBmBtqNkXgn8H/X9VPuyNvSKdF3Xdbj6KlDRthUeOcPHLmB3fkxNQtWmYDl+DuG5f fN8qOEC38GPo75ZKse3u3937HWus6TA3mmOvXBacCzQRmRoRZcv9nle7LPpUEo09umgH 8I9Q==
MIME-Version: 1.0
X-Received: by 10.220.46.72 with SMTP id i8mr33329998vcf.10.1380112289957; Wed, 25 Sep 2013 05:31:29 -0700 (PDT)
Received: by 10.58.237.230 with HTTP; Wed, 25 Sep 2013 05:31:29 -0700 (PDT)
Date: Wed, 25 Sep 2013 08:31:29 -0400
Message-ID: <CAHmhzTY8Q-1G__6F5BgaEZm4iPXnLbGQwiSyWk9wnQq_VcH2Jw@mail.gmail.com>
From: Mark Duckworth <mrducky@gmail.com>
To: clue@ietf.org
Content-Type: multipart/alternative; boundary="001a11c2c674cb102d04e7346e4c"
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: Wed, 25 Sep 2013 12:31:33 -0000
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:* 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-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>.*** > * > > > > > 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>**** > > ** ** > > ** ** >
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Mark Duckworth
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Mark Duckworth
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Schwarz, Albrecht (Albrecht)
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Christian Groves