Hello all,

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-clue-telepresence-use-cases-07
Title: Use Cases for Telepresence Multi-streams
Reviewer: Claudio Allocchio
Review Date: Sep 26th 2013
IETF Last Call Date: Sep 26th 2013
IESG Telechat Date: Not known

Summary: This draft is almost ready for publication as an Informational
RFC. However it needs some editing and maybe a re-ordering of some 
sections. Also a more detailed descprition of the "audio scenario" in all 
sections is worth an efort before publication.

Major issues:

none.

Minor issues:

General comment: most of the documet focuses a lot on the video aspect of 
telepresence, and only is some section the "audio presence" is quickly 
described as possible stereo, or surround or multible monophonic channels. 
I think the audio aspect is as important as the video one in making 
participatns feel the telepresence effect, thus each section should add a 
carful audio setup scenario as detailed as the video on. The voice of a 
partiipants must come from where his/her virtual image is.

There is a text repetition in Introduction and in section 2 (page 5):

    The basic features that give telepresence its distinctive
    characteristics are implemented in disparate ways in different
    systems.  Currently Telepresence systems from diverse vendors
    interoperate to some extent, but this is not supported in a standards
    based fashion.  Interworking requires that translation and
    transcoding devices be included in the architecture.  Such devices
    increase latency, reducing the quality of interpersonal interaction.
    Use of these devices is often not automatic; it frequently requires
    substantial manual configuration and a detailed understanding of the
    nature of underlying audio and video streams. This state of affairs
    is not acceptable for the continued growth of telepresence -
    telepresence systems should have the same ease of interoperability as
    do telephones.

Either you make a shorter statement in the Introduction, of you just refer 
to the introduction text in section 2, page 5.

3.2 section. The whole section describes possible techniques to overcome 
the mismatched situation at the 2 sites... but it does not analyse at all 
possible effects that different proposed solutions have on the 
"telepresence effect" itself, and on human participants. As this is a 
"scenario introduction", we should also consider this aspect, as then 
technical specification can also handle possible mitigation actions to 
reduce the problm. For example, in some of the cases - remote participants 
chenging dynamically on the screens - a potential very bad seasick 
situation will happen easily, making the telepresence esperience a 
nightmare. Note that this comment also applies to 3.3 section.

3.3 section. The description applies to current techniques for multisites, 
bue there is no mention of possible overcome situations when different 
systems are used. Of course this is very similar to 3.2 case, but with 
complexity multiplied by the number of dirrefent sites. It should be 
useful to mention explicitly also this fact.

3.4 section. The currect text describes what you do with the H.239 
equivalent channel data, and suggests the need of additional streams (not 
a sigle one): fine but what is the problem to solve here, is any? Ok, 
maybe you just need to state that you need to make interoperable the sigle 
"presentaton channel" provided by any site.

3.5 section. A basic doubt: is this section into the scope of this 
Informational document? If we aim to help deployment of complete 
interoparting systems, maybe it is, because most existing telepresence 
systems have proprietary (or likely) ways to allow participatns with non 
telepresence devices. If we are only aiming to real telepresence systems 
interoperability, then this section could go into an appendix section.

3.6 section. I tend to think that also this case is worth for an appendix 
(see 3.5 comments).

3.8 section. My basic doubt here is "does this belong to telepresence 
scenario at all? Immersive scnenario in this situation is quite different 
that the one described in the beginning (a typical business meeting). This 
comment also applies to section 3.6

Nits:

none.

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca