Use Cases for Telepresence Multistreams
draft-ietf-clue-telepresence-use-cases-09

[Ballot comment]
You didn't quite mention the use case where participants are all wearing immersive VR devices like the Oculus Rift, and the simulated virtual space is synthesized onto a single display for each participant.  I _think_ that you covered this adequately anyway in 3.7, but I mention it here just to make sure that this scenario was in fact considered.  In this scenario the image of participants wearing VR headsets would have to be synthesized on-site, but it's otherwise pretty much the same as the virtual space scenario with cameras and large displays.

[Ballot comment]
1.

  Furthermore, these use cases do not describe all the aspects needed
  to create the best user experience.

I guess you mean "aspects" that are not relevant to the multiple audio and video streams requirement.
So not interesting for us.  You might want to expand on this.

2.
OLD:

  One common policy is called site switching.  Let's say the speaker is
  at site A and everyone else is at a "remote" site.  When the room at
  site A shown, all the camera images from site A are forwarded to the
  remote sites.

NEW:         
  One common policy is called site switching.  Let's say the speaker is
  at site A and everyone else is at different "remote" sites.  When the room at
  site A shown, all the camera images from site A are forwarded to the
  remote sites.


3.
Section 3.5. Heterogeneous Systems
Question: Is there a use case for a PC running Skype to participate to the telepresence? I mean: I'm in the telepresence room, but I have someone on Skype on my own PC: can I plug a cable from my PC, and make that person participating.
I know that we're far from the telepresence experience, but I've seen that type of Skype set up in IETF meetings where the chair microphone is close to the PC speaker, at least allowing reasonable audio performance.
Or maybe that doesn't qualify as a telepresence use case?

4.
MCU acronym


Warning: As an OPS AD, I will carefully review the operational requirements in draft-ietf-clue-telepresence-requirements-07

[Ballot comment]
Overall, this draft is nice work.

I share Adrian's comments, so I won't repeat (most of) them here.

In addition, I have a few non-blocking comments you might want to consider, along with any other comments you receive.

In this text:

2.  Telepresence Scenarios Overview

  We describe such a telepresence system as sending one or more video
  streams, audio streams, and presentation streams to the remote
  system(s).  (Note that the number of audio, video or presentation
  streams is generally not identical.)

I thought the parenthetical remark was saying the number of audio channels I was sending wasn't necessarily the number of video or presentation channels I was sending, but I started losing clarity wondering whether this was intended to also describe streams in both directions (so, I have three cameras and you have five as in section 3.2. "Point to point meeting: asymmetric", not identical), or streams to different participating sites (so, I send mono audio to you and stereo audio to another participating site, as in section 3.3. "Multipoint meeting", not identical).

Could you clarify what was actually meant? Or maybe you could just delete the parenthetical - the use cases provide clearer text. For example, section 3.1.  "Point to point meeting: symmetric" says this:

  The number of microphones and the number
  of audio channels are often not the same as the number of cameras.
  Also the number of microphones is often not the same as the number of
  loudspeakers.

In this text:

3.5.  Heterogeneous Systems

  Some may be able to handle multiple streams and others can handle
  only a single stream.  (We are not here talking about legacy systems,
  but rather systems built to participate in such a conference,
  although they are single stream only.)  In a single video stream ,
  the stream may contain one or more compositions depending on the
  available screen space on the device.  In most cases an intermediate
  transcoding device will be relied upon to produce a single stream,
  perhaps with some kind of continuous presence.

the doc has been careful to take the participants view of each use case so far, and that means for example that the text is silent on whether a mixer is present - the stream selection could be performed at the sender, receiver, or at a mixer.

As the doc introduces the first intermediate device (a transcoder) here and section 3.6 explicitly says "MCU", I started wondering if there are any considerations in earlier sections that only arise when intermediate devices are present.

I'm also wondering if intermediate devices should be introduced somewhere in section 2 instead of just popping up.

In Section 6 ... please be guided by shepherds and ADs, but I especially support this part of Adrian's comments. I wonder if you could include any text on telepresence-specific security considerations in this document, so we're not starting the conversation while balloting solution drafts. Even a bulleted list of attack surfaces would seem helpful to me.

[Ballot comment]
Wondered why H.264 doesn't qualify for a reference in Section 1.

---

In 3.1

  The important thing here is that each of the 2 sites has the same
  number of screens.  Each screen is paired with a corresponding
  camera.  Each camera / screen pair is typically connected to a
  separate codec, producing a video encoded stream for transmission to
  the remote site, and receiving a similarly encoded stream from the
  remote site.

I understand the pairing of screen to camera. I did not understand why
each site (i.e., both sites) has the same number of screens. It was only
when I reached 3.2 that I realised that 3.1 was drawing out a sub-case
of point-to-point meetings and that 3.2 was describing the other sub-
case.

Reading (and re-reading)-: the two sections, I think that you have not
drawn out adequately the concept of seats. That is, Section 3.2 gets in
a bit of a mess trying to handle the mismatch between seats and cameras/
screens. But this issue is a separate thing from the mismatch of
number of cameras/screens at the two sites.

---

While the situation described in Section 3.5 is clearly very important
(indeed, maybe at least as important as the perfect "everyone is in a
telepresence suite" use cases), it seems to diverge from the definition
of telepresence presented earlier in the document. That is, according to
the description of telepresence, someone connecting in using a lap-top
with tiny video windows is not participating in telepresence.

Rather than rule Section 3.5 out of scope (because I think it is
important) it would be better if you refined your definition of
telepresence earlier in the document to allow this "special case" to be
in scope.

---

Section 6 reads like a cop-out! Surely you can spend some time
describing the security issues for the general telepresence use cases,
which would seem to be:
- disruption
- knowledge of participation
- witnessing
- uninvited participation
It is probable that all use cases demand that all of these issues are
completely prevented, but it may be that some of the issues are
considered more severe in some use cases.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-clue-telepresence-use-cases-07, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.


If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Use Cases for Telepresence Multi-streams) to Informational RFC


The IESG has received a request from the ControLling mUltiple streams for
tElepresence WG (clue) to consider the following document:
- 'Use Cases for Telepresence Multi-streams'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Telepresence conferencing systems seek to create an environment that
  gives non co-located users or user groups a feeling of co-located
  presence through multimedia communication including at least audio
  and video signals of high fidelity.  A number of techniques for
  handling audio and video streams are used to create this experience.
  When these techniques are not similar, interoperability between
  different systems is difficult at best, and often not possible.
  Conveying information about the relationships between multiple
  streams of media would allow senders and receivers to make choices to
  allow telepresence systems to interwork.  This memo describes the
  most typical and important use cases for sending multiple streams in
  a telepresence conference.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO questionnaire for: draft-ietf-clue-telepresence-use-cases-07.txt

To be Published as: Informational

Prepared by: Mary Barnes (mary.ietf.barnes@gmail.com) on Sept. 10, 2013


  (1) What type of RFC is being requested (BCP, Proposed Standard,
      Internet Standard, Informational, Experimental, or Historic)? 
      Why is this the proper type of RFC?  Is this type of RFC indicated 
      in the title page header?

This document is requested to be published as Informational. This is the proper type of RFC
as it defines no new protocol elements nor does it require any IANA registrations. 
This RFC type is indicated on the title page.

    (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up.
        Recent examples can be found in the "Action" announcements for
        approved documents. The approval announcement contains the
        following sections:

        Technical Summary:

This document describes the most typical and important use cases
for sending multiple streams in a telepresence conference. Telepresence conferencing
systems seek to create an environment that gives non
co-located users or user groups a feeling of co-located presence through multimedia
communication including at least audio and video signals of high fidelity. 
A number of techniques for handling audio and video streams are
used to create this experience.  When these techniques are not similar,
interoperability between different systems is difficult at best,
and often not possible.  Conveying information about the relationships 
between multiple streams of media would allow senders and receivers
to make choices to allow telepresence systems to interwork. 
 
        Working Group Summary:
        Was the document considered in any WG, and if so, why was
        it not adopted as a work item there? Was there controversy
        about particular points that caused the WG to not adopt the
        document?
 
This document is a product of the CLUE WG.  There was no controversy
with regards to adopting this document as a WG document.  The document has been
thoroughly reviewed by the CLUE WG participants and is deemed ready
for publication.

        Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

The intent of this document is to highlight key uses cases that are
supported in current telepresence systems.  The objective within the CLUE
WG is to develop protocols that will support those use cases to enable
more widespread interoperability of telepresence systems.  It should also
be noted that a number of these use cases were originally documented
in the IMTC Telepresence Activity Group, that is awaiting the completion
of the CLUE protocol development to progress the interoperability of
telepresence systems.  The IMTC chose to bring their original requirements
and use cases as input to the work in the IETF, recognizing IETF
as the SDO that should be doing the standards development.  There are a
number of key vendors in the telepresence industry that plan to
implement the CLUE WG series of specifications.

Lennard Xiao reviewed the document and suggested (and provided some text)
for the telemedicine use case, which is an important use case
for current telepresence systems.  Christian Groves has carefully reviewed
several versions of this WG document.

        Personnel
        Who is the Document Shepherd? Who is the Responsible Area
        Director?

Mary Barnes (CLUE WG co-chair) is the Document Shepherd. 
Gonzalo Camarillo is the Responsible AD.

    (3) Briefly describe the review of this document that was
        performed by the Document Shepherd.  If this version of
        the document is not ready for publication, please explain
        why the document is being forwarded to the IESG.

The Document Shepherd has thoroughly reviewed this version of the document. 
     
    (4) Does the document Shepherd have any concerns about the depth
        or breadth of the reviews that have been performed?

There are no concerns about the depth or breadth of the reviews.

    (5) Do portions of the document need review from a particular
        or from broader perspective, e.g., security, operational
        complexity, AAA, DNS, DHCP, XML, or internationalization?
        If so, describe the review that took place.
No.

    (6) Describe any specific concerns or issues that the Document
        Shepherd has with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document,
        or has concerns whether there really is a need for it. In any
        event, if the interested community has discussed those issues
        and has indicated that it still wishes to advance the document,
        detail those concerns here.

There are no specific concerns or issues.

    (7) Has each author confirmed that any and all appropriate IPR
        disclosures required for full conformance with the provisions
        of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.
 
    (8) Has an IPR disclosure been filed that references this document?
        If so, summarize any discussion and conclusion regarding the IPR
        disclosures.

No.

    (9) How solid is the consensus of the interested community behind this
        document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

There is WG consensus that AD sponsored is the best approach for progressing this document. No one has expressed concerns about its progression. 

    (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It 
        should be in a separate email because this questionnaire is
        publicly available.)

No.

    (11) Identify any ID nits the Document Shepherd has found in this
        document. (See http://www.ietf.org/tools/idnits/ and the
        Internet-Drafts Checklist). Boilerplate checks are not enough;
        this check needs to be thorough.

The document was checked using idnits 2.12.17. There are no errors, nits or warnings.   

    (12) Describe how the document meets any required formal review
        criteria, such as the MIB Doctor, media type, and URI type
        reviews.

No formal reviews other than review in the CLUE WG are required for this document.

    (13) Have all references within this document been identified as
        either normative or informative?

Yes.

    (14) Are there normative references to documents that are not ready
        for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the plan for their
        completion?

No.

    (15) Are there downward normative references references (see RFC 3967)?
        If so, list these downward references to support the Area Director
        in the Last Call procedure.

No.

    (16) Will publication of this document change the status of any
        existing RFCs? Are those RFCs listed on the title page header,
        listed in the abstract, and discussed in the introduction?
        If the RFCs are not listed in the Abstract and Introduction,
        explain why, and point to the part of the document where the
        relationship of this document to the other RFCs is discussed.
        If this information is not in the document, explain why the
        interested community considers it unnecessary.

No.

    (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body
        of the document. Confirm that all protocol extensions that the
        document makes are associated with the appropriate reservations
        in IANA registries. Confirm that any referenced IANA registries
        have been clearly identified. Confirm that newly created IANA
        registries include a detailed specification of the initial
        contents for the registry, that allocations procedures for future
        registrations are defined, and a reasonable name for the new
        registry has been suggested (see RFC 5226).

This document requires no IANA considerations.

    (18) List any new IANA registries that require Expert Review for
        future allocations. Provide any public guidance that the IESG
        would find useful in selecting the IANA Experts for these new
        registries.

This document defines no new IANA registries.

    (19) Describe reviews and automated checks performed by to validate 
        sections of the document written in a formal language, such as
        XML code, BNF rules, MIB definitions, etc.

No reviews or automated checks were required as this document does
not use any formal language requiring such.