Subject: [clue] interim meeting agenda for framework doc discussion

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 6 Oct 2011 23:46:39 -0700

HI Folks,

Here is a proposal for the framework portion of the interim meeting.

Goal:  Move the draft-romanow-clue-framework toward acceptance as a WG
draft

Agenda:

Overview - 50 minutes

Overview - presentation by draft authors of new material

*         Area of capture

*         Segment switching. VAD. What information in VAD

Issues

*         Area of Capture

*         3 message exchange - provider and consumer. Devices are both. 

o   Initial capabilities message

*         Measurements - are degrees, radians necessary

*         Definitions - Roni's  email (unless it is sorted out on email)

What  are additional issues people feel need to be agreed upon that
stand in the way of the document becoming a WG draft? In order to make
progress, the discussion will be kept to identified issues. New ones can
be added during the meeting, of course.

If you have a particular viewpoint on an issue, it would help to have
some slides to describe it

---

From: Mary Barnes <[email-masked]>
Date: Fri, 7 Oct 2011 13:04:36 -0500

Hi folks,

Per Allyn's note below, if you do have some ideas (which we very much
welcome) on particular issues that you would like to present, charts would
be most helpful as we will have some remote participants.  The chairs will
need all charts (including for the framework) no later than 5pm Eastern on
Monday,  October 10th.  Any charts received after that time may not be able
to be presented as the chairs need to get them uploaded and will be busy
with other logistics prior to the meeting.

Thanks,
Mary.

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

>  HI Folks,****
>
> ** **
>
> Here is a proposal for the framework portion of the interim meeting.****
>
> ** **
>
> ** **
>
> draft****
> ** **
> Agenda:****
> Overview – 50 minutes****
>
> *Overview – presentation by draft authors of new material*
>
> **·         **Area of capture****
>
> **·         **Segment switching. VAD. What information in VAD****
>
> ** **
>
> *Issues*
>
> ** **
>
> **·         **Area of Capture****
>
> **·         **3 message exchange – provider and consumer. Devices are
> both. ****
>
> **o   **Initial capabilities message****
>
> **·         **Measurements – are degrees, radians necessary****
>
> **·         **Definitions – Roni’s  email (unless it is sorted out on
> email)****
>
> ** **
>
> What  are additional issues people feel need to be agreed upon that stand
> in the way of the document becoming a WG draft? In order to make progress,
> the discussion will be kept to identified issues. New ones can be added
> during the meeting, of course.****
>
> ** **
>
> If you have a particular viewpoint on an issue, it would help to have some
> slides to describe it****
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: Roni Even <[email-masked]>
Date: Fri, 07 Oct 2011 20:16:48 +0200

Hi Mary,

I assume that the comments sent to the list before Monday will also be
discussed.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: Friday, October 07, 2011 8:05 PM
To: Allyn Romanow (allyn)
Cc: [email-masked]
Subject: Re: [clue] interim meeting agenda for framework doc discussion

Hi folks,

Thanks,

Mary. 

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

HI Folks,

 

Goal:  Move the draft-romanow-clue-framework toward acceptance as a WG draft

Agenda:

Overview - 50 minutes

.         Area of capture

.         Segment switching. VAD. What information in VAD

Issues

.         Area of Capture

.         3 message exchange - provider and consumer. Devices are both. 

.         Measurements - are degrees, radians necessary

.         Definitions - Roni's  email (unless it is sorted out on email)

What  are additional issues people feel need to be agreed upon that stand in
the way of the document becoming a WG draft? In order to make progress, the
discussion will be kept to identified issues. New ones can be added during
the meeting, of course.

slides to describe it

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Oct 2011 15:02:47 -0400

Roni,

> I assume that the comments sent to the list before Monday will also be

It may be logistically difficult to formally address them all, since 
they may be happening concurrently with the development of the charts 
used to guide discussion. People who have provided comments recently 
would be well advised to be prepared to bring them up again in context 
during the meeting.

	Thanks,
	Paul

> Roni
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mary Barnes
> *Sent:* Friday, October 07, 2011 8:05 PM
> *To:* Allyn Romanow (allyn)
> *Cc:* [email-masked]
> *Subject:* Re: [clue] interim meeting agenda for framework doc discussion
>
> Hi folks,
>
> welcome) on particular issues that you would like to present, charts
> would be most helpful as we will have some remote participants. The
> chairs will need all charts (including for the framework) no later than
> 5pm Eastern on Monday, October 10th. Any charts received after that time
> may not be able to be presented as the chairs need to get them uploaded
> and will be busy with other logistics prior to the meeting.
>
> Thanks,
>
> Mary.
>
> On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> HI Folks,
>
> Overview – 50 minutes
> ·Area of capture
> ·Segment switching. VAD. What information in VAD
>
> *Issues*
>
> ·Area of Capture
>
> ·3 message exchange – provider and consumer. Devices are both.
>
> oInitial capabilities message
>
> ·Measurements – are degrees, radians necessary
>
> ·Definitions – Roni’s email (unless it is sorted out on email)
>
> in the way of the document becoming a WG draft? In order to make
> [email-masked] <mailto:[email-masked]>

---

From: Roni Even <[email-masked]>
Date: Fri, 07 Oct 2011 23:31:38 +0200

Hi,
I think that the major topics I see for discussion are:

1. The capture area, point and scale attributes.
2. The architecture, relation between EPs, Scene, capture set and how does
presentation or presentations fit in the model.
3. Hierarchy of attributes, should they be available for each layer of the
model. Scene, capture set, media captures?
4. Where should the protocol be specified, do we split this document to two?
And what is the extensibility mechanism.
5. Relation of attributes and encoding parameters to SDP (duplicate?)

I can prepare a presentation but is this the chairs want to do it. I was
thinking that the chairs will define the discussion topics, I know that the
framework is an individual draft but I was under the impression that the
chairs will treat it as if we are discussing a WG document and not an
individual draft and this was the major reason for having the interim
meeting, discussing a WG document. I was considering to prepare an
individual draft with other members of the group, was told to wait and see
the new revision of the individual draft which is better than the previous
one but I expect the discussion to be managed by the WG chairs and based on
the document and other inputs including comments that were sent to the list.

Please let me know if I should prepare a presentation or are the chairs
going to accumulate the issues and present them for better efficiency

Regards
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Friday, October 07, 2011 9:03 PM
> To: [email-masked]
> > *Overview - presentation by draft authors of new material*
> >
> > .Area of capture
> >
> > .Segment switching. VAD. What information in VAD
> >
> > *Issues*
> >
> > .Area of Capture
> >
> > .3 message exchange - provider and consumer. Devices are both.
> >
> > .Measurements - are degrees, radians necessary
> >
> > .Definitions - Roni's email (unless it is sorted out on email)
> >
> stand

---

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

We would very much appreciate it if you could prepare a presentation.  The
chairs have a proposed agenda in terms of order of topics to be discussed,
but it was the expectation that the document authors lead the discussion,
with the chairs facilitating in order to get consensus on specific issues.
 Really, no different than how we do things during the WG sessions - we just
have more time to discuss issues and we'll have the opportunity to revisit
things if we get stuck on a specific issue.   I apologize as I should have
put names against the agenda items to make that more clear.

I don't recall that we told anyone to wait to submit ideas/drafts until the
romanow-dispatch-framework document was updated.  That document is not a WG
document - it is just the only proposal we have on the table that could be
considered as a WG deliverable, but that decision has not been made by the
WG.  We do need input from all WG members to determine the best approach for
the CLUE framework deliverable.

Thanks,
Mary.

---

From: Roni Even <[email-masked]>
Date: Sat, 08 Oct 2011 01:58:01 +0200

OK,

I will prepare a presentation on issues with the framework version 01 and
the way forward and would like to get some time to present it. It will be
based on the issues I mentioned here and the comments I sent to the list.

I am afraid that part of it will repeat other presentations but this is how
you want to handle it.

Roni

From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, October 07, 2011 11:44 PM
To: Roni Even
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [clue] interim meeting agenda for framework doc discussion

Thanks,

Mary. 

Hi,

Regards
Roni

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Fri, 7 Oct 2011 23:03:38 -0700

Hi Roni and folks,

I'm really glad that you will prepare slides on your thoughts. Similarly
that Marshall will do a presentation on his views of locating scenes. 

Here are some further thoughts in the hope of preparing a good list of
issues in advance of the meeting.

I had listed as an issue the messaging model-- the fact that an entity
has to be both sender and receiver. We had thought that might need to be
gone over, since the model is different than the SDP offer answer
messaging style. But perhaps it is not necessary? What do people think?
If it's clear and not an issue, then we don't need to spend time on it.
I'm fine either way, but I'm not sure if there is a desire/need for
this?

#1 below I believe this is what we have identified as capture area,
mostly. Brian will do a presentation based on the new material on this
in the draft.
Then we also listed it as a primarily issue to discuss. It will be good
to have your thoughts laid out as a basis for discussion.

I think #2 - architecture and
#3 - attributes  didn't really show up in the issues that I proposed.
I'm not sure specifically what you have in mind and I'm glad you will
bring these issues up fully.  

#4 seems two issues to me.
One is extensibility. We have mostly thought of this in terms of
attributes, so it will be good to hear your thoughts.

The second issues is specifying the protocol.

#5 relation to SDP

On Specifying the protocol and relation to SDP, until now I have been
trying to defer talking much about these -- Saying that we should settle
on a framework and data model, before talking about how we would
implement it in IETF protocols.  However, time is passing and it is
certainly getting to be time to talk about this.  I think that it may be
easier to have this discussion in face of a particular proposal. I'm not
sure how the chairs want to prioritize these 2 issues for this interim
meeting.

Best,
Allyn

> Roni Even
> Sent: Friday, October 07, 2011 2:32 PM
> To: 'Paul Kyzivat'; [email-masked]
> 4. Where should the protocol be specified, do we split this document
to
> two?
> thinking that the chairs will define the discussion topics, I know
that
> the
> > > I assume that the comments sent to the list before Monday will
also
> > be
> > > 5pm Eastern on Monday, October 10th. Any charts received after
that
> > time
> > > progress, the discussion will be kept to identified issues. New
> ones
> > can

---

From: Mary Barnes <[email-masked]>
Date: Sat, 8 Oct 2011 12:24:38 -0500

It's not a problem if there might be some duplication at this point as it's
very important to get multiple perspectives on the issues.  Discussing two
different viewpoints might help us coalesce into a single one that we could
then put on the table to revisit on Wed. morning.   The advantage of the
presentation is that we'll have your thoughts and ideas more precisely
recorded as part of the proceedings and that should also be helpful for
remote participants.

Thanks much,
Mary.

On Fri, Oct 7, 2011 at 6:58 PM, Roni Even <[email-masked]> wrote:

> OK,****
> based on the issues I mentioned here and the comments I sent to the list.*
> ***
>
> you want to handle it.****
>
> Roni****
>
> ** **
>
> *From:* Mary Barnes [mailto:[email-masked]]
> *Sent:* Friday, October 07, 2011 11:44 PM
> *To:* Roni Even
> *Cc:* Paul Kyzivat; [email-masked]
>
> *Subject:* Re: [clue] interim meeting agenda for framework doc discussion*
> ***
>
> ** **
>
> put names against the agenda items to make that more clear.  ****
>
> ** **
>
> the CLUE framework deliverable.  ****
>
> ** **
>
> Thanks,****
>
> Mary. ****
>
> On Fri, Oct 7, 2011 at 4:31 PM, Roni Even <[email-masked]> wrote:***
> *
>
> Hi,
> Roni****
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of*
> ***
>
> > Paul Kyzivat
> > Subject: Re: [clue] interim meeting agenda for framework doc discussion*
> ***
>
> >
> > Roni,
> >
> https://www.ietf.org/mailman/listinfo/clue****
>
> ** **
>

---

From: Mary Barnes <[email-masked]>
Date: Sat, 8 Oct 2011 12:34:13 -0500

Hi Allyn,

Responses inline below [MB].

Thanks,
Mary.

> I'm fine either way, but I'm not sure if there is a desire/need for
[MB] I think it would be worthwhile to have some discussion on this.  We
will need to be very clear about this in the framework document as folks
outside CLUE will want to know why it is different - in particular since the
solution will (most likely) use SDP for describing the information about the
streams and their relationships. It might actually be useful to add a
section in the framework around all of this. [/MB]

> sure how the chairs want to prioritize these 2 issues for this interim
[MB] While the other items are higher priority (we really want to ensure we
leave this meeting with resolution to issues identified thus far), starting
to think about this is a good idea. In particular given that RTCWEB is
looking at the relationship to SDP as well.  If someone does have a strawman
proposal to put forth, that would be great.  [/MB]

---

From: Jonathan Lennox <[email-masked]>
Date: Sun, 9 Oct 2011 22:20:33 -0400

On Oct 7, 2011, at 2:46 AM, Allyn Romanow (allyn) wrote:

What  are additional issues people feel need to be agreed upon that stand in the way of the document becoming a WG draft? In order to make progress, the discussion will be kept to identified issues. New ones can be added during the meeting, of course.

One issue which I think would be useful to discuss would be a clearer explanation of what the framework signaling looks like in a multi-point session, specifically down from an MCU to a receiver.

I think it's important that the protocol support, at least, a mode where there's full "transparency" of all the participants in a conference -- so that a receiver can say, for instance, "I want to see this scene, permanently", it can, and it has enough information to do so meaningfully.

--
Jonathan Lennox
[email-masked]<mailto:[email-masked]>

---

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

Sounds good.

From: Jonathan Lennox [mailto:[email-masked]] 
Sent: Sunday, October 09, 2011 7:21 PM
To: Allyn Romanow (allyn)
Cc: [email-masked]
Subject: Re: [clue] interim meeting agenda for framework doc discussion

	What  are additional issues people feel need to be agreed upon
that stand in the way of the document becoming a WG draft? In order to
make progress, the discussion will be kept to identified issues. New
ones can be added during the meeting, of course.

One issue which I think would be useful to discuss would be a clearer
explanation of what the framework signaling looks like in a multi-point
session, specifically down from an MCU to a receiver.

I think it's important that the protocol support, at least, a mode where
there's full "transparency" of all the participants in a conference --
so that a receiver can say, for instance, "I want to see this scene,
permanently", it can, and it has enough information to do so
meaningfully. 

--

Jonathan Lennox
[email-masked]

---

From: "Roni Even" <[email-masked]>
Date: Mon, 10 Oct 2011 17:42:50 +0200

Hi Jonathan,

I fully agree that the current section on MCU is very basic and need more
information. I have included some issue in my presentation

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Lennox
Sent: Monday, October 10, 2011 4:21 AM
To: Allyn Romanow (allyn)
Cc: [email-masked]
Subject: Re: [clue] interim meeting agenda for framework doc discussion

I think it's important that the protocol support, at least, a mode where
there's full "transparency" of all the participants in a conference -- so
that a receiver can say, for instance, "I want to see this scene,
permanently", it can, and it has enough information to do so meaningfully. 

--

Jonathan Lennox
[email-masked]

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 6528 (20111009) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 6528 (20111009) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

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

On 10/8/11 1:34 PM, Mary Barnes wrote:
...
>
> On Sat, Oct 8, 2011 at 1:03 AM, Allyn Romanow (allyn) <[email-masked]
...
> outside CLUE will want to know why it is different - in particular since
> the solution will (most likely) use SDP for describing the information
> about the streams and their relationships. It might actually be useful
> to add a section in the framework around all of this. [/MB]

Hand waving can only go on for so long.
While its not rocket science, there will be some knotty issues to sort 
out around this. For instance:
- will the messaging for (sender:A,receiver:B) be interleaved with
   that for (sender:B,receiver:A)?
- Is there any synchronization of those two sets of exchanges?
- Is there any required coupling between those exchanges and the
   O/A exchanges between A and B?

Some of this could probably be resolved at the framework level, 
independent of mechanism.

...
> [MB] While the other items are higher priority (we really want to ensure
> we leave this meeting with resolution to issues identified thus far),
> starting to think about this is a good idea. In particular given that
> RTCWEB is looking at the relationship to SDP as well.  If someone does
> have a strawman proposal to put forth, that would be great.  [/MB]

At the very least, I think it would be good to identify who is 
interested in working on this, and then encourage getting started on 
some individual drafts covering it. A little informal brainstorming 
might help kick this off.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Oct 2011 16:48:54 -0400

Jonathan,

On 10/9/11 10:20 PM, Jonathan Lennox wrote:
>> progress, the discussion will be kept to identified issues. New ones
>> can be added during the meeting, of course.
>

This is starting to smell like a new requirement.

Can you frame it that way?

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 11 Oct 2011 09:46:52 -0400

> This is starting to smell like a new requirement.

Hm, yes, good point.

> Can you frame it that way?

Sure.  Here's a first cut:

The solution MUST support a mechanism by which one party in a multi-point conference can choose to permanently view ("pin") a view of a selected other endpoint, a selected specific segment of another endpoint, or a specific presentation, independent of a MCU's selection policy.

--
Jonathan Lennox
[email-masked]