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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 21 November 2013 16:38 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 85C5E1AE1D4 for <clue@ietfa.amsl.com>; Thu, 21 Nov 2013 08:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
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 gcUtKoxjdu0p for <clue@ietfa.amsl.com>; Thu, 21 Nov 2013 08:38:37 -0800 (PST)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id B02301AE044 for <clue@ietf.org>; Thu, 21 Nov 2013 08:38:37 -0800 (PST)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id sF811m0070EZKEL5CGeWt9; Thu, 21 Nov 2013 16:38:30 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id sGeW1m00Q3ZTu2S3MGeWox; Thu, 21 Nov 2013 16:38:30 +0000
Message-ID: <528E3706.1000102@alum.mit.edu>
Date: Thu, 21 Nov 2013 08:38:30 -0800
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" <draft-ietf-clue-telepresence-requirements.all@tools.ietf.org>
References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.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=1385051910; bh=67AsR4wcXt0aoNvNR5neDaOlhhCcBXD8JyG1vc4Iu0w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BX/E273iU+Hsy6OAdcLSHkTaBoapv8TnWhYD51v47NNH/UJJBMGCdhgwoIp++uKs7 g1euMjPcxHvjYLSAbCkM0CDMvsqOdAmB6qC67psQ4s1DOkT5XsFlO0FmDaV8UvepPj z5Ma3GriZN7OYPCE+a4PNG40lk0Guwtv2Xabw+0/rGmtYQgts5TMvB/kJ0jxU8FFtp +a7GXvcDWVc/8NrCpr6bXHD1d/2uCEnzJUYv1tPz0ZuGt5eyvhqYUi1SUBjL8j5mAT O3PVkmNCGEcoC8BNHZZM611aKvlQPIvyYslnsdBkIV+FsQ+B+SAQhztUikd3a7VFpD 9NI05c6Ut4l4g==
Cc: "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: Thu, 21 Nov 2013 16:38:39 -0000

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>.
>
> 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?

> 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.

	Thanks,
	Paul

> 4. REQMT-10: The solution MUST make it possible for endpoints without
>                support for telepresence extensions to participate in a
>                telepresence session with those that do.
>
> More clarity is needed to explain what level of participation in a session (and what limitations) are expected from endpoints that do not support the telepresence extensions. I assume there are limitations, otherwise extensions would not be needed.
>
> 5. REQMT-15 (last bullet): I could not really figure out what is meant here
>
> *  There can be variation in placement, number and size of
>                   presentations
>
> 6. REQMT-16:  The solution MUST include extensibility mechanisms.
>
> What 'extensibility' is meant here? Extending the telepresence sessions, or extending the specifications for new functionality in the future?
>
>
> Minor issues:
>
> 1. If this is the first and basic document to be read by somebody who starts to browse through the CLUE specifications, it would be good to define or expand some place in the introduction what CLUE is.
>
> 2. In the Introduction Section I see:
>
>>   These
>     requirements are for the specification, they are not requirements on
>     the telepresence systems implementing the solution/protocol that will
>     be specified.
>
> But then all requirements in section 5 start by 'The solution ...' which is ambiguous. It would be good to mention (again) in section 5 that by what is meant by the 'solution' is the definition of the protocol, not the implementation.
>
> 3. I will defer to the Security Review to comment whether REQMT-18 is enough from a security point of view - especially as the information about media captures may include explicitly or implicitly details about equipment on each site, etc. To me it seems a little bit too vague.
>
> Regards,
>
> Dan
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>