Subject: [clue] interim meeting-- Requirements doc

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 6 Oct 2011 15:42:34 -0700

Hi Folks,

Are there issues that people would like to discuss about the
requirements doc at the interim meeting next week?

Thanks,

Allyn

---

From: Christian Groves <[email-masked]>
Date: Fri, 07 Oct 2011 14:00:06 +1100

Hello Allyn,

Unfortunately I won't be at next weeks interim. I'd spend more time in 
the air than at the meeting :-(.

I had two comments on the use cases draft that I didn't get a response 
to which relate to the requirements documents.

5) Section 3: [CNG] Will there be any attempt to link the requirements
to certain uses cases?? For example: The RTCWEB requirements document
indicates which requirements are derived from which use cases.

6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that media
descriptions are dynamic. I.e. capabilities may change. There's nothing
explicit in the requirements to support this. Likewise there doesn't
appear to be a use case to support that. Do we need to add one for
that?

Also a couple of additional comments on 
draft-ietf-clue-telepresence-requirements:

REQMT-1b : This talks about two dimensions x,y. Given the recent 
discussions on capture area do we also need to a third dimension z?
REQMT-2 :Is it also appropriate to add capture area x,y,z
General : Point of Capture? I couldn't see where this is in the 
requirements?

Regards, Christian

On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 6 Oct 2011 21:41:03 -0700

Hi Christian, 
Thanks for your comments-
Here are my thoughts on them- 
Please see inline.

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, October 06, 2011 8:00 PM
> To: Allyn Romanow (allyn)
> Cc: [email-masked]
> Subject: Re: [clue] interim meeting-- Requirements doc
> 
> Hello Allyn,
> 
AR- I don't feel it is necessary, although I know it is a style that
some folks use. If the WG feels it is worthwhile, it can be done.
We had done this in earlier versions as a tool, but removed it in the
most recent draft.
What would be the advantage or usefulness for adding doing it now?

> appear to be a use case to support that. Do we need to add one for
AR- Yes, I agree with you that there isn't a use case that describes a
receiver taking advantage of a change in encoding characteristics, or
other attributes. I don't feel that there needs to a use case, but we
could add one if people feel it is necessary. 

If you were to put in a requirement for this, it would not be to make
capabilities dynamic, as that is tied to the particular solution
mechanism we are proposing. It would be more along the lines that
endpoints may change the characteristics of what they send.. which
doesn't seem to me to be much of a requirement.

> discussions on capture area do we also need to a third dimension z?

AR- I don't think this has been settled yet.

> REQMT-2 :Is it also appropriate to add capture area x,y,z
AR - Again, I don't think this has been settled.

> General : Point of Capture? I couldn't see where this is in the
AR - I think point of capture wouldn't be in the requirements.. it is
part of the necessary mechanism for this proposed solution which enables
spatial arrangement, which is in the requirements.

Regards,
Allyn

---

From: Mary Barnes <[email-masked]>
Date: Fri, 7 Oct 2011 11:52:44 -0500

One comment inline below [MB].

Mary.

> What would be the advantage or usefulness for adding doing it now?
[MB] It would be useful for folks that haven't been involved in
the development of the docs that later are trying to understand the work.
Given that the text linking the use cases was in the individual version
(-03) that was agreed as the basis for the WG document and there was no
agreement on the mailing list to remove that text, I think it needs to be
added back in until there is WG consensus that the text is not necessarily.
 [/MB]

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Fri, 7 Oct 2011 09:58:36 -0700

Hi Mary,

It was taken out before it was a WG doc, not after.

I'm not even sure if it was in a pre-working group i.e., private  draft,
it may have been only in pre-submission versions.

I'd suggest adding it in, only if there is WG consensus that it is
valuable, rather than adding it and then taking it out.

From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, October 07, 2011 9:53 AM
To: Allyn Romanow (allyn)
Cc: Christian Groves; [email-masked]
Subject: Re: [clue] interim meeting-- Requirements doc

Mary.

On Thu, Oct 6, 2011 at 11:41 PM, Allyn Romanow (allyn) <[email-masked]>
wrote:

Hi Christian,

[MB] It would be useful for folks that haven't been involved in the
development of the docs that later are trying to understand the work.
Given that the text linking the use cases was in the individual version
(-03) that was agreed as the basis for the WG document and there was no
agreement on the mailing list to remove that text, I think it needs to
be added back in until there is WG consensus that the text is not
necessarily.  [/MB]
> appear to be a use case to support that. Do we need to add one for

	AR- Yes, I agree with you that there isn't a use case that
describes a
	receiver taking advantage of a change in encoding
characteristics, or
	other attributes. I don't feel that there needs to a use case,
but we
	could add one if people feel it is necessary.
	
	If you were to put in a requirement for this, it would not be to
make
	capabilities dynamic, as that is tied to the particular solution
	mechanism we are proposing. It would be more along the lines
that
	endpoints may change the characteristics of what they send..
which
	doesn't seem to me to be much of a requirement.

	> General : Point of Capture? I couldn't see where this is in
the

	AR - I think point of capture wouldn't be in the requirements..
it is
	part of the necessary mechanism for this proposed solution which
enables
	spatial arrangement, which is in the requirements.
	
	Regards,
	Allyn

---

From: Mary Barnes <[email-masked]>
Date: Fri, 7 Oct 2011 12:28:20 -0500

The diff shows that the text was removed between the -03 of the individual
and the -00 of the WG document:
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-clue-telepresence-requirements-00.txt

It was the - 03 that was agreed as the basis of the WG document, which means
that any changes beyond those discussed/agreed at the meeting (per the
minutes) should have been discussed on the mailing list:
http://tools.ietf.org/wg/clue/minutes?item=minutes81.html

Mary.

On Fri, Oct 7, 2011 at 11:58 AM, Allyn Romanow (allyn) <[email-masked]>wrote:

>  Hi Mary,****
>
> It was taken out before it was a WG doc, not after.****
>
> I’m not even sure if it was in a pre-working group i.e., private  draft, it
> may have been only in pre-submission versions.****
>
> ** **
>
> I’d suggest adding it in, only if there is WG consensus that it is
> valuable, rather than adding it and then taking it out.****
>
> ** **
>
> *From:* Mary Barnes [mailto:[email-masked]]
> *Sent:* Friday, October 07, 2011 9:53 AM
> *To:* Allyn Romanow (allyn)
> *Cc:* Christian Groves; [email-masked]
>
> *Subject:* Re: [clue] interim meeting-- Requirements doc****
>
>   ** **
>
> One comment inline below [MB].****
>
>  ****
>
> Mary.****
>
> wrote:****
> Please see inline.****
> > indicates which requirements are derived from which use cases.****
>
> What would be the advantage or usefulness for adding doing it now?****
>
> >****
> doesn't seem to me to be much of a requirement.****
>
>
> > discussions on capture area do we also need to a third dimension z?****
>
> AR- I don't think this has been settled yet.****
>
>
> > REQMT-2 :Is it also appropriate to add capture area x,y,z****
>
> AR - Again, I don't think this has been settled.****
>
>
> > requirements?****
> Allyn****
> https://www.ietf.org/mailman/listinfo/clue****
>
> ** **
>

---

From: Christian Groves <[email-masked]>
Date: Mon, 10 Oct 2011 11:41:48 +1100

Hello Allyn,

Please see my response below.

Regards, Christian

> What would be the advantage or usefulness for adding doing it now?
[CNG] I think the advantage is traceability. As Mary mentioned it helps 
new people figure out the link between requirements and use cases. It I 
think would also provide us with a checklist to ensure that both the use 
cases and requirements align.

> doesn't seem to me to be much of a requirement.
[CNG] Why isn't it much of a requirement? It does have eventual 
non-neglible protocol and system impacts about described how data is 
removed, replaced, flow are co-ordinated etc.
> AR- I don't think this has been settled yet.
[CNG] Its in the current framework document. I guess if the framework is 
accepted as a WG document then it is settled?
> AR - Again, I don't think this has been settled.
[CNG] As above.
> spatial arrangement, which is in the requirements.
[CNG] I guess I don't have a good understanding of what should be in the 
requirements and what shouldn't be. For me point of capture doesn't come 
from the "spatial" arrangement requirement but from the need to support 
the "multiview" use case (at least according to the framework draft 
text). I.e. multiple cameras pointed at the same capture area. I didn't 
find a clear requirement in the requirements document linking to the 
multiview use case in the use case document.

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 9 Oct 2011 20:30:25 -0700

Hi Christian,
Comments inline

> Sent: Sunday, October 09, 2011 5:42 PM
AR- yes, Mary has asked for this, so it is settled to put it in the
document.

make
> removed, replaced, flow are co-ordinated etc.

Okay, I think the best thing would be if you draft the requirement that
you would like, and then we could discuss that.
thanks
> > AR - Again, I don't think this has been settled.
AR - yes you are quite right that a third dimension is in the draft, I
overlooked that in responding to you. 
If you wish to have a requirement that includes a third dimension,
please draft one, and it can be discussed.

> multiview use case in the use case document.
AR - What should be in the requirements is general functionality that
the protocol needs to accomplish, rather than the mechanisms to make
that function happen.  The requirements were re-written many times to
get away from mechanisms toward functionality.
There was a requirement for multi-view in the personal draft -03.
If you want to add a requirement to support multi-view functionality,
would you draft what you have in mind?

In general, not all the functionality in the spec needs to be in the
requirements, though any functions in the requirement  do need to be in
the spec. If there are functions in requirements that are not wanted in
the spec, the requirements should be updated. 

There is no problem with seeking to add to the requirements - if you
would suggest the text you want to add it would be better because we
could then discuss exactly what you would like to add.

Thanks,
Allyn

---

From: Christian Groves <[email-masked]>
Date: Tue, 11 Oct 2011 11:43:55 +1100

Hello Allyn,

Please see my replies below.

Regards, Christian

On 10/10/2011 2:30 PM, Allyn Romanow (allyn) wrote:
..snip..
> you would like, and then we could discuss that.
[CNG] How about something like?

REQMT-17 The solution MUST allow the endpoints (including MCU) involved 
in a telepresence session to negotiate the characteristics at the start 
of a session and to add/modify/remove characteristics whilst the session 
is ongoing.
Note 1: Negotiation Requirement from use case 3.2 last paragraph.
Note 2: Add/Modify/Move requirement from use case 3.5 first paragraph.

> please draft one, and it can be discussed.
[CNG] There's also requirements that discuss dimensional aspects I would 
propose simply amending these, i.e.

               REQMT-1b:  The solution MUST support a means of allowing
                          the preservation of order of images in the
                          scene in three dimensions- horizontal and
                          vertical and depth.

I'm not sure if we need to be explicit as to depth in the audio 
requirements?

> get away from mechanisms toward functionality.
[CNG] I agree requirements should concentrate on functionality rather 
than the protocol mechanisms.

> the spec, the requirements should be updated.
[CNG] I don't follow. You say there may be additional functionality in 
the spec that's not in the requirements, then how does it get added if 
we don't agree that there is a requirement for it? Then you say 
functions in the requirements do not need to be in the spec? Then why 
are they in the requirements? I would think the goal would be to have 
the requirements and the spec aligned?
> could then discuss exactly what you would like to add.
[CNG] For the multiview case how does this sound?
REQMT-18 The solution MUST support a multi-view case where multiple 
cameras are focussed on the same area of view.
Note: Multiview requirement from use case 3.7 paragraph 2.

---

From: Stephen Botzko <[email-masked]>
Date: Mon, 10 Oct 2011 21:23:36 -0400

in-lint

On Mon, Oct 10, 2011 at 8:43 PM, Christian Groves <
[email-masked]> wrote:

>  6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that
>>>>>
>>>> media
>>>>
>>>>> descriptions are dynamic. I.e. capabilities may change. There's
>>>>>
>>>> nothing
>>>>
>>>>> explicit in the requirements to support this. Likewise there
>>>>>
>>>> doesn't
>>
>>>>>  AR- Yes, I agree with you that there isn't a use case that describes
>>>>
>>> a
>>>
>>>> receiver taking advantage of a change in encoding characteristics,
>>>>
>>> or
>>
>>> other attributes. I don't feel that there needs to a use case, but
>>>>
>>> we
>>
> REQMT-17 The solution MUST allow the endpoints (including MCU) involved in
> a telepresence session to negotiate the characteristics at the start of a
> session and to add/modify/remove characteristics whilst the session is
> ongoing.
>>>>> draft-ietf-clue-telepresence-**requirements:
>>>>>
[sb] I'm not sure what this even means, I don't think that we should adopt
this language without more thought.  How are you thinking this is rendered?
If we can't think up some reasonable way to render it, why should we require
it in the solution?

> [sb] I'm even more confused on rendering audio with depth - as I mentioned
in previous posts, you'd need to be able to place the audio at the specified
apparent depths behind wall-mounted monitors.  I don't think that's
possible, certainly not in an interoperable way.  I also don't think its
needed.

>>>> AR - I think point of capture wouldn't be in the requirements.. it
>>>>
>>> is
>>
>>> from the "spatial" arrangement requirement but from the need to
>>>
>> support
>>
>>> text). I.e. multiple cameras pointed at the same capture area. I
>>>
>> didn't
>>
> [CNG] I agree requirements should concentrate on functionality rather than
> the protocol mechanisms.
>
>
> [CNG] I don't follow. You say there may be additional functionality in the
> spec that's not in the requirements, then how does it get added if we don't
> agree that there is a requirement for it? Then you say functions in the
> requirements do not need to be in the spec? Then why are they in the
> requirements? I would think the goal would be to have the requirements and
> the spec aligned?
>
>
> REQMT-18 The solution MUST support a multi-view case where multiple cameras
> are focussed on the same area of view.
>>>>>> ______________________________**_________________
>>>>>> clue mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>>
>>>>> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Oct 2011 22:05:45 -0400

> the requirements and the spec aligned?

IMO it is best that the functionality derive from the requirements. But 
there probably will come a time when the requirements have been 
finalized and we are still working on the mechanism.

At that point, if we find something else that is needed, we can be 
obsessive-compulsive and reopen the the requirements, or we can just go 
ahead and add what is needed. Realistically I expect we will do the latter.

But while the requirements are still open, it makes sense to establish 
requirements for the intended functions.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 11 Oct 2011 13:17:52 +1100

Hello Paul,

I agree with you, when we're reaching completion we can be pragmatic but 
whilst the requirements are still open we should be looking for alignment.

Regards, Christian

On 11/10/2011 1:05 PM, Paul Kyzivat wrote:
> IMO it is best that the functionality derive from the requirements. 
> But there probably will come a time when the requirements have been 
> obsessive-compulsive and reopen the the requirements, or we can just 
> go ahead and add what is needed. Realistically I expect we will do the 
> latter.
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 11 Oct 2011 13:22:31 +1100

Hello Stephen,

Please see my reply below.

Regards, Christian
..snip..
> [sb] I'm not sure what this even means, I don't think that we should 
> adopt this language without more thought.  How are you thinking this 
> is rendered?  If we can't think up some reasonable way to render it, 
> why should we require it in the solution?

[CNG] I just added "three" and "and depth". Is this what you have the 
problem with or the wording of the whole requirement? I'm not trying to 
introduce anything other than allowing the capture to indicate the area 
x,y,z it is capturing. This would allows preservation of the spatial 
information of a scene.

> [sb] I'm even more confused on rendering audio with depth - as I 
> mentioned in previous posts, you'd need to be able to place the audio 
> at the specified apparent depths behind wall-mounted monitors.  I 
> don't think that's possible, certainly not in an interoperable way.  I 
> also don't think its needed.
[CNG] Do we need to reflect that in the framework? i.e. depth (z) is not 
valid for audio captures?

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 11 Oct 2011 06:41:45 -0400

in-line
Stephen

On Mon, Oct 10, 2011 at 10:22 PM, Christian Groves <
[email-masked]> wrote:

>>  If we can't think up some reasonable way to render it, why should we
>> require it in the solution?
>>
>
> [sb] The images themselves are 2D representations of the full 3D volume
that is in the field of view of the corresponding camera.  The image itself
has no depth information, and the various pixels in it are reflected from
various depths in the room.  So I am not sure what "preservation of order of
images ... in three dimensions" means.  Getting a full description of the
camera placement, orientation, and field of view might help receivers make
choices on what images they wish to receive, and might also help them
rescale those images appropriately for their viewers (and displays).  But I
think that is different from from your modified 1b.

Marshal's "ypoint" is the distance between the camera and objects of
interest (e.g., rows of people) - not really the depth of the image itself.
That might be useful (or perhaps even essential), but it not really about
preservation of order.

> valid for audio captures?
[sb] depth is actually y in the current framework draft, not sure if that it
confusing or not. Generally receivers are more interested in height and
width.

[sb] Similar to video, a single channel audio capture is a 1D representation
of the full 3D volume that is in its microphone pickup pattern (which
attenuates, but will pick up some level of sound from the entire room).  We
need to provide enough information to allow panning of the room audio so the
sound matches the receiver's video display choice, and also enough
information to match up voice activity detected in that capture with one or
more cameras that cover the volume that the microphone picks up.  Matching
audio pickup to camera pickup might require some depth description.