Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt

Mary Barnes <mary.ietf.barnes@gmail.com> Sat, 23 November 2013 20:36 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8747C1AE356 for <clue@ietfa.amsl.com>; Sat, 23 Nov 2013 12:36:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW7VccaaZXxL for <clue@ietfa.amsl.com>; Sat, 23 Nov 2013 12:36:15 -0800 (PST)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E24861AE353 for <clue@ietf.org>; Sat, 23 Nov 2013 12:36:14 -0800 (PST)
Received: by mail-we0-f175.google.com with SMTP id p61so2402835wes.20 for <clue@ietf.org>; Sat, 23 Nov 2013 12:36:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/M2p+tFDLgax9XqT8FaRkC7/Wj4yP78fTQhtVySORjQ=; b=Y6fiObibWlLiDIEHDqFFSMrlkAMDpxK9PgjczlUEdQzWDfts2SjAgWo+TMRXn0GDC2 QR46VJIfMYS7aHooRECAhmu4buJEFz8QrpRhEm07WX8Rp8G3NKtG7mlp8nl1/6OEPM92 eYPHxXuiejCoMJhObUX8pNMISunILYd85Fn5Ahu3AzMXfZL7Wmiyb8QtrxTgNcUl+2Hg 8z2DbiBNrxIYzivMTgF/X8e07mqRE8VSKMtVt5dINl/WxHNfCkKy/GGjSFhSeFPiBG8g KL0aWaaJ4LcO6uITMvVBciyjjgDMb3UJJGL+bJQ+DAQpOhNYnomoXAwASdY+1d1afDM0 nZmg==
MIME-Version: 1.0
X-Received: by 10.180.73.70 with SMTP id j6mr7568898wiv.47.1385238966988; Sat, 23 Nov 2013 12:36:06 -0800 (PST)
Received: by 10.216.36.4 with HTTP; Sat, 23 Nov 2013 12:36:06 -0800 (PST)
In-Reply-To: <528FA412.7000009@alum.mit.edu>
References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> <CAHBDyN7TEMfqZPrpgOeGDrWa-=9NDEeeZp9PQhoLXc0sawT4wA@mail.gmail.com> <528FA412.7000009@alum.mit.edu>
Date: Sat, 23 Nov 2013 14:36:06 -0600
Message-ID: <CAHBDyN4y5X4mo+kHZ3dM0oroLb_Own8w3NtPzyBNc1RF1dqVLg@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "Botzko, Stephen" <Stephen.Botzko@polycom.com>
Content-Type: multipart/alternative; boundary="f46d043890858e765104ebde14ec"
Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" <draft-ietf-clue-telepresence-requirements.all@tools.ietf.org>, "clue@ietf.org" <clue@ietf.org>
Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 23 Nov 2013 20:36:18 -0000

I chatted with Steve and he has a suggestion for changing that wording that
should be acceptable (he also has significant expertise in this area).
 Steve, can you please post your suggestion to the mailing list?

Thanks,
Mary.


On Fri, Nov 22, 2013 at 12:36 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>wrote:

> Inline
>
>
> On 11/21/13 1:39 PM, Mary Barnes wrote:
>
>> On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>
>>     Authors,
>>
>>     What do you think of these comments?
>>     If you aren't in agreement with all of them, then we should have a
>>     dialog with Dan about them.
>>
>>     If in agreement, then lets discuss what changes are appropriate.
>>
>>     More inline.
>>
>>
>>     On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote:
>>
>>         I am the assigned Gen-ART reviewer for this draft. For
>>         background on Gen-ART, please see the FAQ at
>>
>>         <http://wiki.tools.ietf.org/__area/gen/trac/wiki/GenArtfaq
>>
>>         <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>>.
>>
>>         Please resolve these comments along with any other Last Call
>>         comments you may receive.
>>
>>         Document: draft-ietf-clue-telepresence-__requirements-06.txt
>>
>>         Reviewer: Dan Romascanu
>>         Review Date: 11/21/13
>>         IETF LC End Date: 11/27/13
>>         IESG Telechat date: (if known)
>>
>>         Summary: It's a good and well written document, almost ready,
>>         but a number of issues should be clarified before approval.
>>
>>         Major issues:
>>
>>         1. The definitions of Left and Right in Section 3 use an entry
>>         article in Wikipedia ('Stage Directions'). I am both
>>         uncomfortable with the usage of Wikipedia articles (subject to
>>         change, subject to attacks) as references, and I also believe
>>         that the current definitions (@11/21/13, US morning hours) are
>>         ambiguous. Actually the Wikipedia article does not include
>>         definitions for Left and Right, and speaks about 'house left'
>>         (equal to 'stage right') and 'house right' (equal to 'stage
>>         left'). If another specification in CLUE will use the terms
>>         defined here it is not clear which one is meant.
>>
>>
>>     This seems like a reasonable point to me. Is there a more stable
>>     reference we can use? If not, can we just define these terms in the
>>     document?
>>
>> [MB] I'm almost of a mind to just remove those definitions.  The
>> consensus was that the terms should be qualified when they are used and
>> the framework does an excellent job of defining more precise terms that
>> properly qualify "left" and "right" and differentiate from stage right,
>> etc. as appropriate.  We use "left" and "right" in one place in this
>> requirements document and I think the use is general enough that we
>> don't need a definition (in this document).   The wikipedia reference
>> has been in the document since day 1 as a WG document (it was added in
>> -03 of the individual document).   The discussions around "left"/"right"
>> on the list were in the context of the definitions document and again,
>> consensus was that the terms should be qualified (as they are in the
>> framework), thus I don't think the current definitions serve any
>> value. [/MB]
>>
>
> WFM.
>
>
>          2. In REQMT-1d it is not clear what 'the extent of individual
>>         video captures' means
>>
>>         3. In REQMT-2d it is not clear what 'the extent of individual
>>         audio captures' means
>>
>>
>>     We have had our own concerns about this. I think we want to say
>>     *something* but its unclear to me exactly what. Perhaps we could
>>     focus on what we want to use this for, and explicitly leave details
>>     of what it is for the FW.
>>
>> [MB] Can you point to the threads of discussion where you feel this
>> concern with this phrasing has been raised?   There were certainly
>> concerns raised about those requirements (i.e., 3D), but I'm not reading
>> this as Dan's concern.   My understanding is that the word "extent" is
>> used in the context of video imagery from the perspective of the camera
>> - i.e., the "angular extent" or something like that.  I think we should
>> replace the word "extent" with something more specific.  Anyone have a
>> suggestion?
>>
>
> I was referring specifically to the comment about *audio*.
> There was a lot of discussion about the the use of spatial coordinates for
> this. John Leslie, who seems the most knowledgeable on the subject, has
> said that they don't mean much. We have talked about other ways of
> representing this, but I don't know if people have been satisfied with the
> results or not.
>
> Of course most of that is in the FW. Here I think we can be much more
> vague about what we mean, because it is up to the FW to specify how to
> accomplish it.
>
> That is why I was suggesting that maybe we could just specify what the
> goal is, with the FW providing the mechanism.
>
> I think there are a few goals. The ones that come to mind are:
>
> - choosing how to map the capture onto available devices when rendering
> - deciding how to transform the capture when rendering
> - correlating audio and video captures
>
>         Thanks,
>         Paul
>