Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-clue-telepresence-use-cases-07

From: Claudio Allocchio <[email-masked]>
Date: Fri, 25 Oct 2013 11:11:01 +0200 (CEST)

Hi Roni!

On Thu, 24 Oct 2013, Roni Even wrote:

> Hi Claudio,
> Thanks for the review.
>
> The technical feedback on sections 3.2, 3.3, 3.4,3.5, 3.6, and 3.8 all 
> seem to be based on a misunderstanding of the document's purpose.  As 
> stated in the introduction, it is merely a set of use cases that the 
> CLUE WG agreed to consider in the development of requirements.

I think there is no misunderstanding at all. I indeed made those 
suggestions exactly to make the use cases even more close to reality that 
users experience now. As I said, just suggestions, drawn directly from 
user's feedback; at GARR we do run all those services, with about 3 
million users around them, thus the help/support desk knows quite a wide 
set of users' comments :-) BUT, JUST SUGGESTIONS!

> What the document is NOT is

> (a) an attempt to precisely define the boundaries between telepresence 
> systems and traditional systems.  The CLUE WG agreed early on that this 
> was both problematic and unnecessary.

> (b) an attempt to define the best solution for each presented scenario. 
> Generally there is no "best" solution, and vendors will continue to make 
> different choices.  Listing possible approaches (generally in use today) 
> is intended to help the CLUE WG ensure that that its protocol building 
> blocks are flexible enough to enable multiple solutions.

This is clear already from the introduction.

> Rather than add the proposed new material to sections 3.2, 3.3, 3.4, 
> 3.5, 3.6, and 3.8, we propose a clarifying sentence be added to the end 
> of the first paragraph of section 2:
>
> "We also specifically do not attempt to precisely define the boundaries 
> between telepresence systems and other systems, nor do we attempt to 
> identify the “best” solution for each presented scenario.  "

that helps, but does not get my suggestions. If you want to add 
additional facts about current users' experiences, than you just take my 
suggestions and expand them a bit into some text. But you can also just 
state "Furtheremore we do not attempt to details all possible scenarios, 
including current problems which users can experinces when sitting in one 
of them." and such addition will also work fine.

> In addition, there is an editorial suggestion to move sections 3.5 and 
> 3.6 to appendices.  We do not see any benefits in reorganizing the text 
> in this way, and we do see a drawback.  CLUE agreed that all of these 
> use cases were germane to its requirements definition.  It seems to us 
> that shifting these sections to appendices would create confusion on 
> that point.

as you prefer.

> We will remove the duplicate text from section 2 and reference the introduction.
> Thanks

you are welcome!

all the best!

> Roni Even
>
>
> ________________________________________
> From: Claudio Allocchio [[email-masked]]
> Sent: Thursday, September 26, 2013 11:27 AM
> To: [email-masked]; [email-masked]
> Cc: IESG
> Subject: APPSDIR review of draft-ietf-clue-telepresence-use-cases-07
>
> 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          [email-masked]
>                         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

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         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

---

From: Roni Even <[email-masked]>
Date: Thu, 24 Oct 2013 19:14:31 +0000

Hi Claudio,
Thanks for the review.

The technical feedback on sections 3.2, 3.3, 3.4,3.5, 3.6, and 3.8 all seem to be based on a misunderstanding of the document's purpose.  As stated in the introduction, it is merely a set of use cases that the CLUE WG agreed to consider in the development of requirements.
 
What the document is NOT is
(a) an attempt to precisely define the boundaries between telepresence systems and traditional systems.  The CLUE WG agreed early on that this was both problematic and unnecessary.  
(b) an attempt to define the best solution for each presented scenario.    Generally there is no "best" solution, and vendors will continue to make different choices.  Listing possible approaches (generally in use today) is intended to help the CLUE WG ensure that that its protocol building blocks are flexible enough to enable multiple solutions.
 
Rather than add the proposed new material to sections 3.2, 3.3, 3.4, 3.5, 3.6, and 3.8, we propose a clarifying sentence be added to the end of the first paragraph of section 2:
  
 "We also specifically do not attempt to precisely define the boundaries between telepresence systems and other systems, nor do we attempt to identify the “best” solution for each presented scenario.  "

In addition, there is an editorial suggestion to move sections 3.5 and 3.6 to appendices.  We do not see any benefits in reorganizing the text in this way, and we do see a drawback.  CLUE agreed that all of these use cases were germane to its requirements definition.  It seems to us that shifting these sections to appendices would create confusion on that point.

Hello all,

Major issues:

none.

Minor issues:

Nits:

none.