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

[Mary Barnes <[e-mail]>]

On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat <[e-mail]>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>.
>>
>> 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]

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

And, note these requirements were added based on discussion at IETF-82:
http://www.ietf.org/proceedings/82/slides/clue-1.pdf

 [/MB]

>         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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/clue
>>
>>
>