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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 21 Nov 2013 15:08:13 +0000

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. 

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Nov 2013 08:38:30 -0800

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.

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

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?

> 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

> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 21 Nov 2013 15:39:23 -0600

On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat <[email-masked]>wrote:

> If you aren't in agreement with all of them, then we should have a dialog
> with Dan about them.
>
>> 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]

> *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]

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Nov 2013 10:36:02 -0800

Inline

On 11/21/13 1:39 PM, Mary Barnes wrote:
> On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Authors,
>
>         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>>.
>
>         Document: draft-ietf-clue-telepresence-__requirements-06.txt
>         Reviewer: Dan Romascanu
>         Review Date: 11/21/13
>         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.
>
>
> [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.

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

---

From: Mary Barnes <[email-masked]>
Date: Sat, 23 Nov 2013 14:36:06 -0600

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 <[email-masked]>wrote:

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

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 27 Nov 2013 17:27:55 -0500

Dan - thanks so much for reviewing this.

Comments are in-line

Stephen Botzko

On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes <[email-masked]>wrote:

>>> 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.
>>>
>>
[SB] I agree with Mary that these definitions can simply be removed.
[/SB]

> 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
[SB]
The intent of REQMT-1d was to say that CLUE needs to identify the area that
each camera captured in the room - so it would be clear how views from
different camera related to each other, and also if there were any gaps,
etc.  Identifying the scale of the view is related, but is captured
concisely in requirement 6.  Proper rendering in a multi-camera
telepresence system requires this knowledge - today it is generally
hard-wired into the room design.  But that doesn't result in an
interoperable experience, and it needs to be signaled if you want to get
appropriate rendering between rooms with disparate designs.

For audio [REQMT-2d], there is an analogous need to identify the area of
coverage of a microphone.  The need to correlate the audio and the video is
related, but is captured separately in REQMT-3.

The discussions on the list related to audio and video area of coverage
were about whether the model in the framework was adequate.  Personally I
believe it is.  But what really matters here is whether we are clearly
stating the *requirement*, not the adequacy of the proposed
specifications.

One alternative term is "area of coverage", which is commonly used in
surveillance applications to describe a similar concept.  If people think
that might be confused with radio coverage (e.g. an LTE coverage map) we
could draft a definition and add it to section 3.
[/SB]

>> [SB] The intent was to simply state that the solution must not prevent
direct interoperability with SIP devices (either phone or
videoconferencing) - without the need for a middlebox to convert signaling
(as would be required with rtcweb for instance).   The limitation is simply
that telepresence extensions can't be used.  I do not see a need to
describe the limitations of existing SIP systems in this requirements
document.

Suggested text that makes the requirement more clear would be helpful.
This is a bit tricky to word, since SIP itself has no requirement that says
SIP endpoints must interoperate with each other w/o middleboxes to assist.
And in fact they often don't.  We could alternatively drop the requirement.
[/SB]

>>> [SB]At this point I am not certain either.  We might have meant that
different use cases had different placements, number, and size of
presentations. Or that existing telepresence systems handle presentations
in different ways.

It is not worded as a clear requirement, and it says "can", not "should" or
"must".  My recommendation is to delete that bullet.
[/SB]

>> [SB] What is meant is extending the specifications for new functionality
in the future.  I suggest that we re-word to "New protocols developed for
the solution MUST include extensibility mechanisms"
[/SB]

>>> [SB] I am not sure if the CLUE WG has a recommended order for reading
the various documents.  Personally I would recommend that people start with
the use cases.  In any event, I think the document purpose is properly
captured in the abstract - it is not intended to be an introduction to
telepresence generally or as an orientation to CLUE specifications.
[/SB]

>> [SB] I agree.  We should also use "specifications", since current plans
call for more than one standards-track RFC
[/SB]

>> [SB] I don't see it as vague - it pretty clearly says that only the
mechanism needs to be secure.  I think you are saying that the security
section might be incomplete.

Current protocol designs do not include explicit details about equipment,
and I see nothing in the requirements that suggest otherwise.  Some
requirements do require transport of information that can be used infer
room dimensions (at least of the visible portion of the room) and the
audio/video coverage within it.  Can you identify threats that might use
that information?

Of course each specification includes its own Security Considerations.
Obviously we will address any security review comments in this one.
[/SB].