Subject: [clue] Preparing PROTO Write-up for Use case document

From: Mary Barnes <[email-masked]>
Date: Tue, 3 Sep 2013 10:06:58 -0500

Hi all,

In the process of re-reviewing the use cases document in preparation of the
PROTO write-up, I came across the following nits and a couple minor issues
that I would like to discuss with the WG.

Thanks,
Mary.

Minor issues:
-------------------

- Section 2, first two paragraphs after numbered list.  I struggled a
little bit with this text (which is more of a problem statement) in a
section that's providing an overview of scenarios. I would suggest to move
the first of those two paragraphs into section 1 and delete that 2nd
paragraph (in section 2)  as I think what's important is the current last
sentence of the 2nd paragraph in section 1.  Thus, I'm suggesting changing
the 2nd paragraph in section 1 as follows:
OLD:
Although telepresence systems are based on open standards such as RTP[RFC3550],
SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of protocols, they
cannot easily interoperate with each other without operator assistance and
expensive additional equipment which translates from one vendor's protocol
to another. A standard way of describing the multiple streams constituting
the media flows and the fundamental aspects of their behavior, would allow
telepresence systems to interwork.

NEW:
Although telepresence systems are based on open standards such as RTP[RFC3550],
SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of protocols, they
cannot easily interoperate with each other without operator assistance and
expensive additional equipment which translates from one vendor's protocol
to another.
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. Thus,
a standard way of describing the multiple streams constituting the media
flows and the fundamental aspects of their behavior, would allow
telepresence systems to interwork.

- Section 3.4, 5th paragraph :  This seems misplaced as there isn't
anywhere else in the document where we talk about protocols (this is
something which would really be more appropriately discussed in the
solution documents).  I would suggest to delete this paragraph.

Nits:
-------
- Section 1, 3rd paragraph, 1st sentence: "draft"->"document",
"requirements will be derived" -> "requirements are derived"
- Section 1, last paragraph: Need to add two spaces after "This document
structure is as follows:"
- Section 2, "users we will call participant cameras" -> "users are
referred to as participant cameras"  (consistent with wording a couple
sentences down)
- Section 3, first sentence.  Adding spacing after the sentence.
- Section 3.7, first paragraph, 1st sentence.  Adding spacing after the
sentence.
- Section 3.9, first paragraph, last sentence.  This is awkwardly worded. I
suggest changing: "assist the process of the surgery" to simply "assist in
the surgery" or "assist in the surgical process"
- Section 4.  1st para. "draft" -> "document"

---

From: "Roni Even" <[email-masked]>
Date: Tue, 3 Sep 2013 18:29:39 +0300

Hi Mary,

I am OK with the text for section 2 and can update the document if no
objections and fix the nits

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: 03 September, 2013 6:07 PM
To: CLUE
Cc: Roni Even
Subject: [clue] Preparing PROTO Write-up for Use case document

Hi all,

Thanks,

Mary.

Minor issues:

-------------------

- Section 2, first two paragraphs after numbered list.  I struggled a little
bit with this text (which is more of a problem statement) in a section
that's providing an overview of scenarios. I would suggest to move the first
of those two paragraphs into section 1 and delete that 2nd paragraph (in
section 2)  as I think what's important is the current last sentence of the
2nd paragraph in section 1.  Thus, I'm suggesting changing the 2nd paragraph
in section 1 as follows:

OLD:

Although telepresence systems are based on open standards such as
RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of
protocols, they cannot easily interoperate with each other without operator
assistance and expensive additional equipment which translates from one
vendor's protocol to another. A standard way of describing the multiple
streams constituting the media flows and the fundamental aspects of their
behavior, would allow telepresence systems to interwork.

NEW: 

Although telepresence systems are based on open standards such as
RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of
protocols, they cannot easily interoperate with each other without operator
assistance and expensive additional equipment which translates from one
vendor's protocol to another. 

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.
Thus, a standard way of describing the multiple streams constituting the
media flows and the fundamental aspects of their behavior, would allow
telepresence systems to interwork.

- Section 3.4, 5th paragraph :  This seems misplaced as there isn't anywhere
else in the document where we talk about protocols (this is something which
would really be more appropriately discussed in the solution documents).  I
would suggest to delete this paragraph.  

Nits:

-------

- Section 1, 3rd paragraph, 1st sentence: "draft"->"document", "requirements
will be derived" -> "requirements are derived"

- Section 2, "users we will call participant cameras" -> "users are referred
to as participant cameras"  (consistent with wording a couple sentences
down)

---

From: Christian Groves <[email-masked]>
Date: Wed, 04 Sep 2013 12:13:03 +1000

OK for me.

Christian

On 4/09/2013 1:29 AM, Roni Even wrote:
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Mary Barnes
> *Sent:* 03 September, 2013 6:07 PM
> *To:* CLUE
> *Cc:* Roni Even
> *Subject:* [clue] Preparing PROTO Write-up for Use case document
>
> Hi all,
>
> In the process of re-reviewing the use cases document in preparation 
> of the PROTO write-up, I came across the following nits and a couple 
> minor issues that I would like to discuss with the WG.
>
> Thanks,
>
> Mary.
>
> Minor issues:
>
> -------------------
>
> section that's providing an overview of scenarios. I would suggest to 
> move the first of those two paragraphs into section 1 and delete that 
> 2nd paragraph (in section 2)  as I think what's important is the 
> current last sentence of the 2nd paragraph in section 1.  Thus, I'm 
> suggesting changing the 2nd paragraph in section 1 as follows:
>
> OLD:
>
> protocols, they cannot easily interoperate with each other without 
> operator assistance and expensive additional equipment which 
> translates from one vendor's protocol to another. A standard way of 
> describing the multiple streams constituting the media flows and the 
> fundamental aspects of their behavior, would allow telepresence 
> systems to interwork.
>
> NEW:
>
> protocols, they cannot easily interoperate with each other without 
> operator assistance and expensive additional equipment which 
> translates from one vendor's protocol to another.
>
> The basic features that give telepresence its 
> distinctivecharacteristics are implemented in disparate ways in 
> differentsystems. Currently Telepresence systems from diverse 
> vendorsinteroperate to some extent, but this is not supported in a 
> standardsbased fashion. Interworking requires that translation 
> andtranscoding devices be included in the architecture. Such 
> devicesincrease latency, reducing the quality of interpersonal 
> interaction.Use of these devices is often not automatic; it frequently 
> requiressubstantial manual configuration and a detailed understanding 
> of thenature of underlying audio and video streams. This state of 
> affairsis not acceptable for the continued growth of telepresence 
> -telepresence systems should have the same ease of interoperability 
> asdo telephones. Thus, a standard way of describing the multiple 
> streams constituting the media flows and the fundamental aspects of 
> their behavior, would allow telepresence systems to interwork.
>
> - Section 1, last paragraph: Need to add two spaces after "This 
> document structure is as follows:"
>
> - Section 3.7, first paragraph, 1st sentence.  Adding spacing after 
> the sentence.
>
> - Section 3.9, first paragraph, last sentence.  This is awkwardly 
> worded. I suggest changing: "assist the process of the surgery" to 
> simply "assist in the surgery" or "assist in the surgical process"
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Roni Even" <[email-masked]>
Date: Sat, 7 Sep 2013 11:10:02 +0300

Hi,

I submitted 07 version including the comment and nits.

I have problem with removing the following text from section 3.4 so I am
asking for more feedback.

"In H.323[ITU.H323] systems, H.239[ITU.H239] is typically used to

   control the video presentation stream.  In SIP systems, similar

   control mechanisms can be provided using BFCP [RFC4582] for

   presentation token.  These mechanisms are suitable for managing a

   single presentation stream."

My view is that  using H.239 is the current  use case for presentation. 

Roni

Hi all,

Thanks,

Mary.

Minor issues:

-------------------

OLD:

NEW: 

Nits:

-------

---

From: Mary Barnes <[email-masked]>
Date: Mon, 9 Sep 2013 17:57:49 -0500

Thanks Roni.  I have reviewed the updated version and will retract my
comment with regards to the H.239 reference.  I will submit the PROTO
write-up as soon as I have responses from all the authors with regards to
IPR.

Thanks,
Mary.

On Sat, Sep 7, 2013 at 3:10 AM, Roni Even <[email-masked]> wrote:

> Hi,****
>
> I submitted 07 version including the comment and nits.****
>
> asking for more feedback.****
>
> ** **
>
> “In H.323[ITU.H323] systems, H.239[ITU.H239] is typically used to****
>
>    control the video presentation stream.  In SIP systems, similar****
>
>    control mechanisms can be provided using BFCP [RFC4582] for****
>
>    presentation token.  These mechanisms are suitable for managing a****
>
>    single presentation stream.”****
>
> ** **
>
> My view is that  using H.239 is the current  use case for presentation. **
> **
>
> Roni****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mary Barnes
> *Subject:* [clue] Preparing PROTO Write-up for Use case document****
>
> ** **
>
> Hi all,****
>
> ** **
>
> In the process of re-reviewing the use cases document in preparation of
> the PROTO write-up, I came across the following nits and a couple minor
> issues that I would like to discuss with the WG. ****
>
> ** **
>
> Thanks,****
>
> Mary.****
>
> ** **
>
> Minor issues:****
>
> -------------------****
>
> ** **
>
> the 2nd paragraph in section 1 as follows:****
>
> OLD:****
>
> behavior, would allow telepresence systems to interwork.****
>
> ** **
>
> NEW: ****
>
> vendor's protocol to another. ****
>
> 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. Thus, a standard way of describing the
> multiple streams constituting the media flows and the fundamental aspects
> of their behavior, would allow telepresence systems to interwork.****
>
> ** **
>
> solution documents).  I would suggest to delete this paragraph.  ****
>
> ** **
>
> Nits:****
>
> -------****
>
> "requirements will be derived" -> "requirements are derived"****
>
> structure is as follows:"   ****
>
> sentences down) ****
> - Section 3, first sentence.  Adding spacing after the sentence. ****
>
> sentence.****
> - Section 3.9, first paragraph, last sentence.  This is awkwardly worded.
> I suggest changing: "assist the process of the surgery" to simply "assist
> in the surgery" or "assist in the surgical process" ****
>
> - Section 4.  1st para. "draft" -> "document"****
>