Subject: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Fri, 22 Apr 2011 00:48:18 -0700

Folks, 
I revised my requirement document based on the numerous helpful comments made during the WG meeting in Prague. An appendix outlines the main changes.

I’m delighted that Stephan Wenger has significantly contributed to the draft and agreed to be a co-author - much appreciation, Stephan. 

Looking forward to discussion of the draft-

Best regards,
Allyn

-------

A new version of I-D, draft-romanow-clue-telepresence-requirements-02.txt has been successfully submitted by Allyn Romanow and posted to the IETF repository.

Filename:	 draft-romanow-clue-telepresence-requirements
Revision:	 02
Title:		 Requirements for Telepresence Multi-Streams
Creation_date:	 2011-04-22
WG ID:		 Independent Submission
Number_of_pages: 10

Abstract:
This memo discusses the requirements for a specification that enables
telepresence interoperability, by describing the relationship between
multiple RTP streams.  In addition, the problem statement and
definitions are also covered herein.

The IETF Secretariat.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Apr 2011 09:37:09 -0400

[as individual]

> Looking forward to discussion of the draft-

Allyn,

This is a great improvement - the document hangs together quite nicely.
A few comments:

Why is REQMT-4 SHOULD while REQMT-5 is MUST?
It seems that REQMT-7/REQMT-8 is a similar pairing, but in that case 
both are MUST strength.

    REQMT-6:   The solution MUST include a mechanism to support a means
               of describing dynamic changes in the streams offered by
               the sender; and dynamic changes in the streams requested
               by the receiver.

IMO "a mechanism to support a means" is excessive. How about

    REQMT-6:   The solution MUST include a mechanism to support
               describing dynamic changes in the streams offered by
               the sender; and dynamic changes in the streams requested
               by the receiver.

I don't understand exactly what point REQMT-10 is trying to make that is 
different from REQMT-9. I think maybe REQMT-10 needs a few more words.

	Thanks,
	Paul

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 22 Apr 2011 10:41:32 -0700

Hi Paul, group,
Some of the issues you raised are based on my input, so I think it's only
fair if I answer them.
Please see inline.
Stephan

On 4.22.2011 06:37 , "Paul Kyzivat" <[email-masked]> wrote:

>[...]

It's an IPR concern that led to the SHOULD.  I prefer the WG has the
freedom to leave out specification text addressing this requirement if IPR
surfaces, which (in this case) seems likely to me.  Sorry for not being
more specific on this public mailing list.

As a general comment, IIRC the previous revision of the draft contained
only MUST requirements.  I personally prefer "soft" requirement language,
so to be able to address concerns of whatever nature (including, but by no
means limited to IPR) without having to abandon one of our own
requirements.

>               the sender; and dynamic changes in the streams requested

Sounds OK to me.

Allyn and I had a discussion about this requirement.  I was worried that
it would not be within the charter.  Allyn proved me wrong.  However, it
is my understanding that implementing this "solution" requires technology
that goes beyond the exchange of properties and capabilities during
session setup.  We are not talking about a bunch of SDP codepoints here.
This is real-time conference control for media.  Is this really what we
want to do in this WG?  It's conceptually a different problem than just
announcing "this session comes from the right camera".  Do we have an idea
what we want to use here?  Mediactl?

>different from REQMT-9. I think maybe REQMT-10 needs a few more words.

Agreed.  10 seems to be a generalization of 9.

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

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 22 Apr 2011 11:39:36 -0700

I like the improvements in this new draft.
I don't understand the difference between requirements 4 and 7.

REQMT-4: The solution SHOULD support a mechanism by which a sending
         endpoint or MCU can describe aspects of its
         characteristics and attributes.

REQMT-7: The solution MUST include a mechanism by which the
         receiver can learn the description of the streams the
         sender can send it.

REQMT-4 is about describing the sender, while REQMT-7 is about describing the streams that are sent.  How are these different?  I would think that describing the sender is only relevant if the description pertains to the streams being sent, otherwise what good is it?

Some examples of things that might be described  for REQMT-7 are: number of streams, spatial relationship between streams, association of audio and video streams, scale of video streams, viewpoint of the camera for video streams, and which site (or even which camera within a site) is the source of a stream.  Are there additional characteristics and attributes that would be relevant for REQMT-4 that are not included in REQMT-7?

Mark Duckworth

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Fri, 22 Apr 2011 19:43:53 -0700

Hi Paul and Stephan,
Let me just address quickly  a couple of your points.. 
I agree with you that Reqmt 10 requires more description. It is not
meant as a generalization of of 9. Reqmt 9 talks about the specific case
where the number of media devices varies at different endpoints
participating in the conference. It is specific difficult case to
handle. 

Reqmt 10 refers to the capabilities of the endpoints, such as the codec
capabilities.  I will suggest text to make this more clear.

See below for comment on necessity of handling dynamic changes in media.

Thanks,
Allyn

> -----Original Message-----
> From: Stephan Wenger [mailto:[email-masked]]
> Sent: Friday, April 22, 2011 10:42 AM
> To: Paul Kyzivat (pkyzivat); Allyn Romanow (allyn)
> Cc: CLUE
> Subject: Re: [clue] FW: New Version Notification for draft-romanow-
> clue-telepresence-requirements-02
> 
> Hi Paul, group,
> so to be able to address concerns of whatever nature (including, but
by
> no

Since characteristics of media streams during a telepresence conference
may change, such as bandwidth, resolution,  and since those changes
affect interoperability, it's necessary to handle communication of
relevant information about those changes. This was discussed and decided
upon during the charter discussion and I don't think we should be
re-opening charter now. The fact that this may not fit into SDP
codepoints is irrelevant. I don't believe that we chartered the group
with the stipulation that the solution must be implementable wholly
within SDP.

---

From: Peter Musgrave <[email-masked]>
Date: Sat, 23 Apr 2011 13:51:35 -0400

Hi Stephan

Do I understand this to mean that you are concerned about IPR regarding the mechanism of describing the aspects and characteristics? 

Or do you mean that there might be IPR associated with the characteristics/attributes themselves?

If the later, then I think a MUST would be ok, since the requirement is for a mechanism.

I have the opposite bias - I prefer MUST for requirements - otherwise why call them requirements?

A section which describes additional goals (as opposed to requirements) could be a place for SHOULD clauses.

Peter

---

From: Peter Musgrave <[email-masked]>
Date: Sat, 23 Apr 2011 14:02:03 -0400

Hi all, 

> what we want to use here?  Mediactl?

I guess I share Stephan's concern. Perhaps part of the issue is the phrase "dynamic changes in the streams"?

Arguably, frame rate could be viewed as such a change - but I don't think that is what we mean. IIUC what we mean are things like:
"This stream now has video from the Paris endpoint center camera (since that person is now speaking). "

Is that the kind of thing we mean?

Could we refine "dynamic changes in the streams" to "a change in stream content (e.g.. a voice activated stream selection switch)" (maybe someone can improve on this?)

This would make it clear that we are not doing floor control type stuff - but we are conveying semantic information about stream changes. 

Peter

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 24 Apr 2011 07:06:06 -0700

Hi Mark - yes, I agree they are redundant. Reqmt 7 can be removed. 

Best regards,
Allyn

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Duckworth, Mark
> Sent: Friday, April 22, 2011 11:40 AM
> To: CLUE
> Subject: Re: [clue] FW: New Version Notificationfor
draft-romanow-clue-
> telepresence-requirements-02
> 
> REQMT-4 is about describing the sender, while REQMT-7 is about
> describing the streams that are sent.  How are these different?  I
> would think that describing the sender is only relevant if the
> description pertains to the streams being sent, otherwise what good is
> it?
> 
> Some examples of things that might be described  for REQMT-7 are:
> number of streams, spatial relationship between streams, association
of
> audio and video streams, scale of video streams, viewpoint of the
> camera for video streams, and which site (or even which camera within
a
> site) is the source of a stream.  Are there additional characteristics
> and attributes that would be relevant for REQMT-4 that are not
included
> in REQMT-7?

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 25 Apr 2011 09:39:37 -0700

I was thinking REQMT-7 is more clear, so it makes more sense to remove REQMT-4 and keep REQMT-7.

Mark

> From: Allyn Romanow (allyn) [mailto:[email-masked]]
> Sent: Sunday, April 24, 2011 10:06 AM
> To: Duckworth, Mark; CLUE
> Subject: RE: [clue] FW: New Version Notificationfor draft-romanow-clue-

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 25 Apr 2011 09:51:28 -0700

Thanks for your comment, we can take it into account in the next
version.

Of
> Duckworth, Mark
> Sent: Monday, April 25, 2011 9:40 AM
> To: CLUE
> Subject: Re: [clue] FW: New VersionNotificationfor draft-romanow-clue-
> > > description pertains to the streams being sent, otherwise what
good
> > is

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 25 Apr 2011 09:58:54 -0700

What we decided to do in SIPREC for such things is say that there MUST
be mechanism for xyz, and then leave it up to implementations to
use/support the mechanism.

Cheers,
Charles 

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Peter Musgrave
> Sent: Saturday, April 23, 2011 10:52 AM
> To: Stephan Wenger
> Cc: CLUE
> Subject: Re: [clue] FW: New Version Notification
fordraft-romanow-clue-telepresence-requirements-02
> Do I understand this to mean that you are concerned about IPR
regarding the mechanism of describing
> the aspects and characteristics?
> 
> 
> A section which describes additional goals (as opposed to
requirements) could be a place for SHOULD
> clauses.