Subject: [clue] Data model - agreement on objective and basic approach

From: Mary Barnes <[email-masked]>
Date: Mon, 29 Oct 2012 12:52:10 -0500

On the call earlier today, we also discussed the data model.  The general
agreement on the call is that the data model as reflected in
draft-presta-clue-data-model-schema describes the data needed by the CLUE
application - i.e., it's the CLUE instance concept.  It does not directly
reflect the contents of a CLUE message.  The application data would be used
to populate CLUE messages, as well as SDP and would reflect updates based
on both the CLUE and SDP signaling.

If we can get agreement on that before the meeting, I believe our
discussions can be much more productive. If folks could please reply "Yes"
or "No" reflecting agreement with the above, that would be helpful.  If you
reply "No", please explain why.

Regards,
Mary
as CLUE WG co-chair

---

From: "Roni Even" <[email-masked]>
Date: Mon, 29 Oct 2012 21:19:11 +0200

Hi,

My view is 'no". I still fail to see the need for the encoding groups and
individual encodes. 

In the current definition of capture scene, I am not sure what is the
meaning of different individual encodes and eventually the receiver can
define what it can receive (Typically H.264 is symmetric in terms of profile
but does not need to be in the level) and can ask for specific resolution
with the SDP image attribute

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: 29 October, 2012 7:52 PM
To: CLUE
Subject: [clue] Data model - agreement on objective and basic approach

On the call earlier today, we also discussed the data model.  The general
agreement on the call is that the data model as reflected in
draft-presta-clue-data-model-schema describes the data needed by the CLUE
application - i.e., it's the CLUE instance concept.  It does not directly
reflect the contents of a CLUE message.  The application data would be used
to populate CLUE messages, as well as SDP and would reflect updates based on
both the CLUE and SDP signaling.  

Regards,

Mary

as CLUE WG co-chair

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Oct 2012 15:25:36 -0400

On 10/29/12 1:52 PM, Mary Barnes wrote:
> On the call earlier today, we also discussed the data model.  The
> general agreement on the call is that the data model as reflected in
> draft-presta-clue-data-model-schema describes the data needed by the
> CLUE application - i.e., it's the CLUE instance concept.  It does not
> directly reflect the contents of a CLUE message.  The application data
> would be used to populate CLUE messages, as well as SDP and would
> reflect updates based on both the CLUE and SDP signaling.
>
> discussions can be much more productive. If folks could please reply
> "Yes" or "No" reflecting agreement with the above, that would be
> helpful.  If you reply "No", please explain why.

Well, while that is *possible*, it seems odd to me. The XML schema 
defines an *encoding*. What you are describing would make more sense to 
me if we were doing a more abstract model, such as via UML, that isn't 
directly tied to an encoding.

What is in the data model right now doesn't exactly map onto clue 
messages. But the "clueInfo" element comes very close to mapping onto an 
Advertisement as described in the framework. And there isn't (yet) 
anything in the schema that maps in an obvious way to a Configure message.

Nevertheless I'm ok with acknowledging that some of the stuff in the 
model may end up in the SDP until we get this sorted out and find a 
better way to represent it.

	Thanks,
	Paul (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Oct 2012 15:45:43 -0400

On 10/29/12 3:19 PM, Roni Even wrote:
> Hi,
>
> My view is ‘no”. I still fail to see the need for the encoding groups
> and individual encodes.
>
> define what it can receive (Typically H.264 is symmetric in terms of
> profile but does not need to be in the level) and can ask for specific
> resolution with the SDP image attribute

ISTM that you are answering a different question than the one Mary 
asked. You seem to be saying that you disagree with the framework as it 
is - that it can/should be simpler.

That is a separate question. If such changes were made it might affect a 
lot.

	Thanks,
	Paul

> Roni Even
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mary Barnes
> *Sent:* 29 October, 2012 7:52 PM
> *To:* CLUE
> *Subject:* [clue] Data model - agreement on objective and basic approach
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Mary Barnes <[email-masked]>
Date: Mon, 29 Oct 2012 16:19:06 -0500

This was the discussion we had on one of the calls a while back, although,
I can't find the specific one quickly reviewing the minutes, so it may not
have been appropriately captured but I am recalling we had an email thread.
 I'll dig for that.

One of the key points was that you will have user actions that result in
changes to the information that may or may not result in new signaling -
e.g., a Configure. So, you need to keep some form of an instance and some
form of state.

We agreed to use XML rather than UML. I can envision as you note that some
of the XML blobs from the schema would be carried in a CLUE message.  And
other information is used to inform what should be carried in the SDP.

Mary.

On Mon, Oct 29, 2012 at 2:25 PM, Paul Kyzivat <[email-masked]> wrote:

>> draft-presta-clue-data-model-**schema describes the data needed by the
> Well, while that is *possible*, it seems odd to me. The XML schema defines
> an *encoding*. What you are describing would make more sense to me if we
> were doing a more abstract model, such as via UML, that isn't directly tied
> to an encoding.
>
> Advertisement as described in the framework. And there isn't (yet) anything
> in the schema that maps in an obvious way to a Configure message.
>
> Nevertheless I'm ok with acknowledging that some of the stuff in the model
> may end up in the SDP until we get this sorted out and find a better way to
> represent it.
>
>         Thanks,
>         Paul (as individual)
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 30 Oct 2012 00:23:14 +0200

Paul,
This was the statement I answered "no"
" The general agreement on the call is that the data model as reflected in
draft-presta-clue-data-model-schema describes the data needed by the CLUE
application"
I disagree that it reflects that data needed by a CLUE application and I
explained why. 

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: 29 October, 2012 9:46 PM
To: [email-masked]
Subject: Re: [clue] Data model - agreement on objective and basic approach

On 10/29/12 3:19 PM, Roni Even wrote:
> Hi,
>
> My view is 'no". I still fail to see the need for the encoding groups 
> and individual encodes.
>
> meaning of different individual encodes and eventually the receiver 
> can define what it can receive (Typically H.264 is symmetric in terms 
> of profile but does not need to be in the level) and can ask for 
> specific resolution with the SDP image attribute

ISTM that you are answering a different question than the one Mary asked.
You seem to be saying that you disagree with the framework as it is - that
it can/should be simpler.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Tue, 30 Oct 2012 00:26:38 +0200

Hi,

Small question

Is there a difference in the data model if we decide to support delta
advertisement?

Roni

Regards,

Mary

as CLUE WG co-chair

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Oct 2012 19:00:49 -0400

> I disagree that it reflects that data needed by a CLUE application and I

OK, fair enough.

Mary can comment, but my take was that the point of her question was to 
distinguish between two alternatives:
- the data model represents all the data needed by the clue app.
   (which implies to me that it encompasses all the data in the
   framework.)
- the data model represents the data to be exchanged in
   clue messages.

It is a bigger deal if the framework includes things that are not needed 
by the clue application. I was of the impression that, except for some 
fine tuning, we were largely in agreement on the framework.

If we don't have consensus on *that* then resolving that is of higher 
priority that much of the other stuff we are discussing.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Oct 2012 19:02:02 -0400

> Is there a difference in the data model if we decide to support delta

IMO - NO.

	Thanks,
	Paul (as individual)

---

From: Christian Groves <[email-masked]>
Date: Tue, 30 Oct 2012 12:53:04 +1100

Hello Mary,

I haven't been party to the telephone discussions but I wonder why we 
need an abstraction like a CLUE instance concept in what is a pretty 
simple protocol? I wonder what the benefit would be in having a data 
model based on a CLUE instance and then a seperate XML to define the 
actual messages?

I think it would be good to understand the rationale why the data model 
schema was written in this way and what the benefit is. I think this 
would be good background before one can definitely say yes or no. If you 
want a definite answer now, then no.

Regards, Christian

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 30 Oct 2012 09:03:00 +0100

Hi all,

just to be clear on the current structure of the data model schema: all the things you find there were 'extracted' (by Roberta and me) from information currently contained inside the framework draft (as well as from some side documents, associated with either the data model or the envisaged call flows). So, unless we have misinterpreted the above document(s) (which is obviously possible), we should first of all focus on the framework in order to try and converge on an agreed-upon CLUE architecture. Once done with this, we can fine-tune the data model. As I already stated on this list, it is my personal opinion that we should remove from the framework document all of the data-model stuff that it currently contains, and rather focus on a clear definition of framework components and interfaces. I might look naif, but I would like to arrive at an 'ordinary' set of documents: (i)  general framework; (ii) data model; (iii) clue protocol (with advertisement and configuration messages); (iv) call flows (showing how SDP O/A and CLUE protocol messages concur in effectively setting up a CLUE session).

As to the 'UML vs XML' querelle, I would suggest that:

1. Both UML class diagrams and XML schema can be adopted for the description of the data model, i.e., the STATIC part of the framework, associated with the description of what some of you properly called a 'CLUE instance';
2. UML sequence diagrams can be adopted to describe CLUE call flows, i.e. the DYNAMIC part of the framework, which clearly envisages the co-existence of SDP and CLUE protocol messages. XML schemas are not suitable for this dynamic part.

This said, it is clear that CLUE protocol messages  (in particular, CLUE advertisements) will be constructed by leveraging information contained inside a CLUE instance. Which parts of a CLUE instance should go into an advertisement and which should be carried inside SDP can be a matter of discussion.

My 2 cents,

Simon

Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto:

> Mary can comment, but my take was that the point of her question was to distinguish between two alternatives:
> It is a bigger deal if the framework includes things that are not needed by the clue application. I was of the impression that, except for some fine tuning, we were largely in agreement on the framework.
> 
> If we don't have consensus on *that* then resolving that is of higher priority that much of the other stuff we are discussing.
> 
> 	Thanks,
> 	Paul
> 
>> Roni
>> 

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Christian Groves <[email-masked]>
Date: Tue, 30 Oct 2012 20:33:52 +1100

Hello Simon,

When you say that you want to remove "all" the data model stuff from the 
framework can you be a bit more specific as to what parts you want removed?

Regards, Christian

On 30/10/2012 7:03 PM, Simon Pietro Romano wrote:
> Hi all,
>
> just to be clear on the current structure of the data model schema: 
> all the things you find there were 'extracted' (by Roberta and me) 
> from information currently contained inside the framework draft (as 
> well as from some side documents, associated with either the data 
> model or the envisaged call flows). So, unless we have misinterpreted 
> the above document(s) (which is obviously possible), we should first 
> of all focus on the framework in order to try and converge on an 
> agreed-upon CLUE architecture. Once done with this, we can fine-tune 
> the data model. As I already stated on this list, it is my personal 
> opinion that we should remove from the framework document all of the 
> data-model stuff that it currently contains, and rather focus on a 
> clear definition of framework components and interfaces. I might look 
> naif, but I would like to arrive at an 'ordinary' set of documents: 
> (i)  general framework; (ii) data model; (iii) clue protocol (with 
> advertisement and configuration messages); (iv) call flows (showing 
> how SDP O/A and CLUE protocol messages concur in effectively setting 
> up a CLUE session).
>
> 1. Both UML class diagrams and XML schema can be adopted for the 
> description of the data model, i.e., the STATIC part of the framework, 
> associated with the description of what some of you properly called a 
> 'CLUE instance';
> 2. UML sequence diagrams can be adopted to describe CLUE call flows, 
> i.e. the DYNAMIC part of the framework, which clearly envisages the 
> co-existence of SDP and CLUE protocol messages. XML schemas are not 
> suitable for this dynamic part.
>
> This said, it is clear that CLUE protocol messages  (in particular, 
> CLUE advertisements) will be constructed by leveraging information 
> contained inside a CLUE instance. Which parts of a CLUE instance 
> should go into an advertisement and which should be carried inside SDP 
> can be a matter of discussion.
>
> My 2 cents,
>
> Simon
>
>
>>> CLUE
>> It is a bigger deal if the framework includes things that are not 
>> needed by the clue application. I was of the impression that, except 
>> for some fine tuning, we were largely in agreement on the framework.
>>
>>> From: [email-masked] <mailto:[email-masked]> 
>>> [mailto:[email-masked]] On Behalf Of Paul
>>> Kyzivat
>>> To: [email-masked] <mailto:[email-masked]>
>>> asked.
>>>> *From:[email-masked] <mailto:[email-masked]> 
>>>> [mailto:[email-masked]] *On Behalf
>>>> Of *Mary Barnes
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
>  e-mail: [email-masked] <mailto:[email-masked]>
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 30 Oct 2012 11:23:56 +0100

Hi Christian,

a rough estimation would be the following:

a) keep sections 1 through 4 inside the framework document;
b) move sections 5 through 8 to the data model document
c) move the XML schema to the data model document (final section of the 
data model, which provides 'one possible' example of how to formally 
describe the things in the document);
d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the 
protocol document;
e) move subsection 9.4 to the call flows document;
f) move section 10 to the data model document;
g) move section 11 to the call flows document.

Obviously, the resulting framework document should be revised (and 
enriched) in view of the proposed distribution of work inside the WG. I 
would like it to represent an orchestration document, providing an 
overview of issues, requirements, architecture and protocols. A sort of 
summary reference for all of the related "drill-down" documents, each 
expanding on a specific WG item (data model, protocol, call flows, etc.).

I acknowledge the fact that this looks much like a revolution, but I 
nonetheless believe that we already have most of the needed material at 
hand and just need to better distribute it across the documents produced 
by the WG.

Cheers,

Simon

Il 30/10/2012 10:33, Christian Groves ha scritto:
> Hello Simon,
>
> When you say that you want to remove "all" the data model stuff from 
> the framework can you be a bit more specific as to what parts you want 
> removed?
>
> Regards, Christian
>
>> description of the data model, i.e., the STATIC part of the 
>> framework, associated with the description of what some of you 
>> properly called a 'CLUE instance';
>> should go into an advertisement and which should be carried inside 
>> SDP can be a matter of discussion.
>>
>> My 2 cents,
>>
>> Simon
>>
>>
>>> If we don't have consensus on *that* then resolving that is of 
>>> higher priority that much of the other stuff we are discussing.
>>>
>>> Thanks,
>>> Paul
>>>
>>>> Roni
>>>>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Mary Barnes <[email-masked]>
Date: Tue, 30 Oct 2012 16:25:03 -0500

I think this is a reasonable split and I don't think it's that much of a
killer task to do so.  We have talked in the past about whether we should
split some material from the framework.  I think doing so will make it
easier for individuals to edit the various pieces.  We will of course have
to ensure consistency.  However,  this approach adds some good checks and
balances, I believe.   This model is quite similar to what worked very well
for the XCON work and it's quite similar to what other WGs are doing (e.g.,
SIPREC).

The chairs have delayed updating our milestones since we had not decided
individual deliverables related to the solution.

As chair I would like to gauge consensus on this approach.  So, if people
could please respond as to whether they support the general idea of
splitting the work into the following documents/deliverables:
1) Framework
2) Data model
3) Protocol
4) Call Flows

If we can get consensus on the basic idea, then we can work out the details
starting with Simon's suggestion.

I do have one comment about the "orchestration document" as I think that
might be appropriate for the framework, but we could certainly work on that
separately and decide later.

Thanks,
Mary.

On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano <[email-masked]>wrote:

> would like it to represent an orchestration document, providing an overview
> of issues, requirements, architecture and protocols.

> A sort of summary reference for all of the related "drill-down" documents,
> each expanding on a specific WG item (data model, protocol, call flows,
> etc.).
>
> hand and just need to better distribute it across the documents produced by
> the WG.
>
> Cheers,
>
> Simon
>
>
>
>
>>> just to be clear on the current structure of the data model schema: all
>>> the things you find there were 'extracted' (by Roberta and me) from
>>> information currently contained inside the framework draft (as well as from
>>> some side documents, associated with either the data model or the envisaged
>>> call flows). So, unless we have misinterpreted the above document(s) (which
>>> is obviously possible), we should first of all focus on the framework in
>>> order to try and converge on an agreed-upon CLUE architecture. Once done
>>> with this, we can fine-tune the data model. As I already stated on this
>>> list, it is my personal opinion that we should remove from the framework
>>> document all of the data-model stuff that it currently contains, and rather
>>> focus on a clear definition of framework components and interfaces. I might
>>> look naif, but I would like to arrive at an 'ordinary' set of documents:
>>> advertisement and configuration messages); (iv) call flows (showing how SDP
>>> O/A and CLUE protocol messages concur in effectively setting up a CLUE
>>> session).
>>>
>>> associated with the description of what some of you properly called a 'CLUE
>>> instance';
>>> This said, it is clear that CLUE protocol messages  (in particular, CLUE
>>> advertisements) will be constructed by leveraging information contained
>>> inside a CLUE instance. Which parts of a CLUE instance should go into an
>>> advertisement and which should be carried inside SDP can be a matter of
>>> discussion.
>>>
>>> My 2 cents,
>>>
>>> Simon
>>>
>>>
>>>>> draft-presta-clue-data-model-**schema describes the data needed by
>>>>> the CLUE
>>>>> application"
>>>> needed by the clue application. I was of the impression that, except for
>>>> some fine tuning, we were largely in agreement on the framework.
>>>>
>>>>> From: [email-masked] <mailto:[email-masked]> [mailto:
>>>>> [email-masked]] On Behalf Of Paul
>>>>> Kyzivat
>>>>>> *From:[email-masked] <mailto:[email-masked]> [mailto:
>>>>>> [email-masked]] *On Behalf
>>>>>> Of *Mary Barnes
>>>>>> ______________________________**_________________
>>>>>> clue mailing list
>>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>>
>>>>>>
>>>>> ______________________________**_________________
>>>>> clue mailing list
>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>
>>>>>
>>>>>
>>>> ______________________________**_________________
>>>> clue mailing list
>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>
>>>>
>>> _\\|//_
>>>       ( O-O )
>>>  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>>> Simon Pietro Romano
>>> ______________________________**_________________
>>> 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>
>>
>>
> --
>                             _\\|//_
>                             ( O-O )
>    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                     Simon Pietro Romano
>           http://www.comics.unina.it/**simonpietro.romano<http://www.comics.unina.it/simonpietro.romano>
>
>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Roni Even <[email-masked]>
Date: Tue, 30 Oct 2012 21:42:49 +0000

Hi Mary,

What about the mapping of RTP streams to Media Captures, where does it fall

BTW: the mapping may require an identfier for the media capture

Roni

________________________________
From: [email-masked] [[email-masked]] on behalf of Mary Barnes [[email-masked]]
Sent: Tuesday, October 30, 2012 11:25 PM
To: CLUE
Subject: Re: [clue] Data model - agreement on objective and basic approach

I think this is a reasonable split and I don't think it's that much of a killer task to do so.  We have talked in the past about whether we should split some material from the framework.  I think doing so will make it easier for individuals to edit the various pieces.  We will of course have to ensure consistency.  However,  this approach adds some good checks and balances, I believe.   This model is quite similar to what worked very well for the XCON work and it's quite similar to what other WGs are doing (e.g., SIPREC).

The chairs have delayed updating our milestones since we had not decided individual deliverables related to the solution.

As chair I would like to gauge consensus on this approach.  So, if people could please respond as to whether they support the general idea of splitting the work into the following documents/deliverables:
1) Framework
2) Data model
3) Protocol
4) Call Flows

If we can get consensus on the basic idea, then we can work out the details starting with Simon's suggestion.

I do have one comment about the "orchestration document" as I think that might be appropriate for the framework, but we could certainly work on that separately and decide later.

Thanks,
Mary.

On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano <[email-masked]<mailto:[email-masked]>> wrote:
Hi Christian,

a) keep sections 1 through 4 inside the framework document;
b) move sections 5 through 8 to the data model document
c) move the XML schema to the data model document (final section of the data model, which provides 'one possible' example of how to formally describe the things in the document);
d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protocol document;
e) move subsection 9.4 to the call flows document;
f) move section 10 to the data model document;
g) move section 11 to the call flows document.

Obviously, the resulting framework document should be revised (and enriched) in view of the proposed distribution of work inside the WG. I would like it to represent an orchestration document, providing an overview of issues, requirements, architecture and protocols.

A sort of summary reference for all of the related "drill-down" documents, each expanding on a specific WG item (data model, protocol, call flows, etc.).

I acknowledge the fact that this looks much like a revolution, but I nonetheless believe that we already have most of the needed material at hand and just need to better distribute it across the documents produced by the WG.

Cheers,

Simon

Hello Simon,

When you say that you want to remove "all" the data model stuff from the framework can you be a bit more specific as to what parts you want removed?

Regards, Christian

My 2 cents,

Simon

OK, fair enough.

Thanks,
Paul

Roni

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Paul
Kyzivat
Sent: 29 October, 2012 9:46 PM
To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
Subject: Re: [clue] Data model - agreement on objective and basic approach

Thanks,
Paul

Roni Even

*From:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf
Of *Mary Barnes
*Sent:* 29 October, 2012 7:52 PM
*To:* CLUE
*Subject:* [clue] Data model - agreement on objective and basic
approach

Regards,

Mary

as CLUE WG co-chair

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/clue

_\\|//_
      ( O-O )
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
Simon Pietro Romano
Universita' di Napoli Federico II
 Computer Engineering Department
  Phone: +39 081 7683823<tel:%2B39%20081%207683823> -- Fax: +39 081 7683816<tel:%2B39%20081%207683816>
 e-mail: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

--
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department
        Phone: +39 081 7683823<tel:%2B39%20081%207683823> -- Fax: +39 081 7684219<tel:%2B39%20081%207684219>
                e-mail: [email-masked]<mailto:[email-masked]>
          http://www.comics.unina.it/simonpietro.romano

                          \ (    (   )
                           \_)    ) /
                                 (_/

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

---

From: Mary Barnes <[email-masked]>
Date: Tue, 30 Oct 2012 16:44:54 -0500

As Paul noted, you are not answering the question that was posed and you
are bringing up a framework issue.  I believe you are getting into the
discussion as to what we can carry in SDP, which is the topic of your draft
that we will discuss at the meeting next week.   As noted, by Simon later
in this thread, the information in the data model has been taken *directly*
from the framework.  I think we are having some cross-talk and
misunderstandings.   If you don't agree with some fundamentals in the
framework, please identify specific sections independent of how we agree to
signal (i.e., SDP versus CLUE signaling).

Mary.

On Mon, Oct 29, 2012 at 2:19 PM, Roni Even <[email-masked]> wrote:

> Hi,****
>
> My view is ‘no”. I still fail to see the need for the encoding groups and
> individual encodes. ****
>
> resolution with the SDP image attribute****
>
> ** **
>
> Roni Even****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mary Barnes
> *Subject:* [clue] Data model - agreement on objective and basic approach**
> **
>
> ** **
>
> on both the CLUE and SDP signaling.  ****
>
> ** **
>
> reply "No", please explain why.  ****
>
> ** **
>
> Regards,****
>
> Mary****
>
> as CLUE WG co-chair****
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 30 Oct 2012 16:49:10 -0500

I think that would belong in the protocol document - that is where the
SIPREC WG has described their usage of RTP.   Any specific changes to the
RTP and SDP would of course be submitted as documents in the AVTCORE and
MMUSIC WGs.

However, it may be better to keep that document separate for a while - that
is also the model that SIPREC used/

Mary.

On Tue, Oct 30, 2012 at 4:42 PM, Roni Even <[email-masked]>wrote:

>  ------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of Mary
> Barnes [[email-masked]]
> *Sent:* Tuesday, October 30, 2012 11:25 PM
> *To:* CLUE
>
> *Subject:* Re: [clue] Data model - agreement on objective and basic
> approach
>
>  As chair I would like to gauge consensus on this approach.  So, if
> people could please respond as to whether they support the general idea of
>  If we can get consensus on the basic idea, then we can work out the
> details starting with Simon's suggestion.
>
>> A sort of summary reference for all of the related "drill-down"
>> documents, each expanding on a specific WG item (data model, protocol, call
>> flows, etc.).
>>
>>>> contained inside a CLUE instance. Which parts of a CLUE instance should go
>>>> into an advertisement and which should be carried inside SDP can be a
>>>> matter of discussion.
>>>>
>>>> My 2 cents,
>>>>
>>>> Simon
>>>>
>>>>
>>>>>>> the

---

From: "Roni Even" <[email-masked]>
Date: Wed, 31 Oct 2012 01:01:44 +0200

Mary,

Just as a point that CLUE does not work if you cannot say which SSRC is a
specific media capture in CLUE

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: 30 October, 2012 11:49 PM
To: Roni Even
Cc: CLUE
Subject: Re: [clue] Data model - agreement on objective and basic approach

Mary.   

On Tue, Oct 30, 2012 at 4:42 PM, Roni Even <[email-masked]>
wrote:

Hi Mary,

Roni

  _____  

From: [email-masked] [[email-masked]] on behalf of Mary Barnes
[[email-masked]]
Sent: Tuesday, October 30, 2012 11:25 PM
To: CLUE

1) Framework

2) Data model

3) Protocol

4) Call Flows

Thanks,

Mary. 

On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano <[email-masked]>
wrote:

Hi Christian,

a) keep sections 1 through 4 inside the framework document;
b) move sections 5 through 8 to the data model document
c) move the XML schema to the data model document (final section of the data
model, which provides 'one possible' example of how to formally describe the
things in the document);
d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the
protocol document;
e) move subsection 9.4 to the call flows document;
f) move section 10 to the data model document;
g) move section 11 to the call flows document.

Obviously, the resulting framework document should be revised (and enriched)
in view of the proposed distribution of work inside the WG. I would like it
to represent an orchestration document, providing an overview of issues,
requirements, architecture and protocols.

I acknowledge the fact that this looks much like a revolution, but I
nonetheless believe that we already have most of the needed material at hand
and just need to better distribute it across the documents produced by the
WG.

Cheers,

Simon

Hello Simon,

Regards, Christian

Hi all,

just to be clear on the current structure of the data model schema: all the
things you find there were 'extracted' (by Roberta and me) from information
currently contained inside the framework draft (as well as from some side
documents, associated with either the data model or the envisaged call
flows). So, unless we have misinterpreted the above document(s) (which is
obviously possible), we should first of all focus on the framework in order
to try and converge on an agreed-upon CLUE architecture. Once done with
this, we can fine-tune the data model. As I already stated on this list, it
is my personal opinion that we should remove from the framework document all
of the data-model stuff that it currently contains, and rather focus on a
clear definition of framework components and interfaces. I might look naif,
but I would like to arrive at an 'ordinary' set of documents: (i)  general
framework; (ii) data model; (iii) clue protocol (with advertisement and
configuration messages); (iv) call flows (showing how SDP O/A and CLUE
protocol messages concur in effectively setting up a CLUE session).

1. Both UML class diagrams and XML schema can be adopted for the description
of the data model, i.e., the STATIC part of the framework, associated with
the description of what some of you properly called a 'CLUE instance';
2. UML sequence diagrams can be adopted to describe CLUE call flows, i.e.
the DYNAMIC part of the framework, which clearly envisages the co-existence
of SDP and CLUE protocol messages. XML schemas are not suitable for this
dynamic part.

My 2 cents,

Simon

Paul,

OK, fair enough.

It is a bigger deal if the framework includes things that are not needed by
the clue application. I was of the impression that, except for some fine
tuning, we were largely in agreement on the framework.

Thanks,
Paul

Roni

-----Original Message-----

Hi,

Thanks,
Paul

Roni Even

Regards,

Mary

as CLUE WG co-chair

_\\|//_
      ( O-O )
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
Simon Pietro Romano
Universita' di Napoli Federico II
 Computer Engineering Department
  Phone: +39 081 7683823 <tel:%2B39%20081%207683823>  -- Fax: +39 081
7683816 <tel:%2B39%20081%207683816> 
 e-mail: [email-masked] <mailto:[email-masked]>

-- 

                            _\\|//_
                            ( O-O )

                 Computer Science Department
        Phone: +39 081 7683823 <tel:%2B39%20081%207683823>  -- Fax: +39 081
7684219 <tel:%2B39%20081%207684219> 
                e-mail: [email-masked]
          http://www.comics.unina.it/simonpietro.romano 

                          \ (    (   )
                           \_)    ) /
                                 (_/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Oct 2012 20:21:33 -0400

On 10/30/12 7:01 PM, Roni Even wrote:
> Mary,
>
> Just as a point that CLUE does not work if you cannot say which SSRC is
> a specific media capture in CLUE

I have now gotten lost in this thread. I don't understand what in the 
thread this comment was intended to respond to.

But responding to just this statement, it sounds like a denial of the 
dynamic mapping, which explicitly separates the identification of a 
capture (actually capture encoding) from an SSRC.

So are you saying thata CLUE does not work with the dynamic mapping?

	Thanks,
	Paul

> *Sent:* 30 October, 2012 11:49 PM
> *To:* Roni Even
> *Cc:* CLUE
> *Subject:* Re: [clue] Data model - agreement on objective and basic approach
>
> SIPREC WG has described their usage of RTP.   Any specific changes to
> the RTP and SDP would of course be submitted as documents in the AVTCORE
> and MMUSIC WGs.
>
> However, it may be better to keep that document separate for a while -
> that is also the model that SIPREC used/
>
> Mary.
>
> On Tue, Oct 30, 2012 at 4:42 PM, Roni Even <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Hi Mary,
>
> ------------------------------------------------------------------------
>
> [[email-masked] <mailto:[email-masked]>] on behalf of Mary
> Barnes [[email-masked] <mailto:[email-masked]>]
> *Subject:* Re: [clue] Data model - agreement on objective and basic approach
>
> killer task to do so.  We have talked in the past about whether we
> should split some material from the framework.  I think doing so will
> make it easier for individuals to edit the various pieces.  We will of
> course have to ensure consistency.  However,  this approach adds some
> good checks and balances, I believe.   This model is quite similar to
> what worked very well for the XCON work and it's quite similar to what
> other WGs are doing (e.g., SIPREC).
>
> people could please respond as to whether they support the general idea
> of splitting the work into the following documents/deliverables:
>
> 1) Framework
>
> 2) Data model
>
> 3) Protocol
>
> 4) Call Flows
>
> might be appropriate for the framework, but we could certainly work on
> that separately and decide later.
>
> Thanks,
>
> Mary.
>
> overview of issues, requirements, architecture and protocols.
>
>     documents, each expanding on a specific WG item (data model,
>     protocol, call flows, etc.).
>
>     nonetheless believe that we already have most of the needed material
>     at hand and just need to better distribute it across the documents
>     produced by the WG.
>
>     Cheers,
>
>     Simon
>
>
>
>
>         When you say that you want to remove "all" the data model stuff
>         from the framework can you be a bit more specific as to what
>         parts you want removed?
>
>         Regards, Christian
>
>         just to be clear on the current structure of the data model
>         schema: all the things you find there were 'extracted' (by
>         Roberta and me) from information currently contained inside the
>         framework draft (as well as from some side documents, associated
>         with either the data model or the envisaged call flows). So,
>         unless we have misinterpreted the above document(s) (which is
>         obviously possible), we should first of all focus on the
>         framework in order to try and converge on an agreed-upon CLUE
>         architecture. Once done with this, we can fine-tune the data
>         model. As I already stated on this list, it is my personal
>         opinion that we should remove from the framework document all of
>         the data-model stuff that it currently contains, and rather
>         focus on a clear definition of framework components and
>         interfaces. I might look naif, but I would like to arrive at an
>         'ordinary' set of documents: (i)  general framework; (ii) data
>         model; (iii) clue protocol (with advertisement and configuration
>         messages); (iv) call flows (showing how SDP O/A and CLUE
>         2. UML sequence diagrams can be adopted to describe CLUE call
>         flows, i.e. the DYNAMIC part of the framework, which clearly
>         envisages the co-existence of SDP and CLUE protocol messages.
>         XML schemas are not suitable for this dynamic part.
>
>         This said, it is clear that CLUE protocol messages  (in
>         particular, CLUE advertisements) will be constructed by
>         leveraging information contained inside a CLUE instance. Which
>         parts of a CLUE instance should go into an advertisement and
>         which should be carried inside SDP can be a matter of discussion.
>
>         My 2 cents,
>
>         Simon
>
>
>         Mary can comment, but my take was that the point of her question
>         was to distinguish between two alternatives:
>         It is a bigger deal if the framework includes things that are
>         not needed by the clue application. I was of the impression
>         that, except for some fine tuning, we were largely in agreement
>         on the framework.
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         [mailto:[email-masked] <mailto:[email-masked]>] On
>         Behalf Of Paul
>         Kyzivat
>         To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         [mailto:[email-masked] <mailto:[email-masked]>]
>         *On Behalf
>         Of *Mary Barnes
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>            Phone: +39 081 7683823 <tel:%2B39%20081%207683823> -- Fax:
>         +39 081 7683816 <tel:%2B39%20081%207683816>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>              Phone: +39 081 7683823 <tel:%2B39%20081%207683823> -- Fax:
>     +39 081 7684219 <tel:%2B39%20081%207684219>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 31 Oct 2012 08:43:19 +0200

Paul,
I am saying that CLUE does not work without mapping of RTP streams
(identified by SSRC) and Media Captures, it is true for static or dynamic
mapping. 
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: 31 October, 2012 2:22 AM
To: [email-masked]
Subject: Re: [clue] Data model - agreement on objective and basic approach

On 10/30/12 7:01 PM, Roni Even wrote:
> Mary,
>
> Just as a point that CLUE does not work if you cannot say which SSRC 
> is a specific media capture in CLUE

I have now gotten lost in this thread. I don't understand what in the thread
this comment was intended to respond to.

But responding to just this statement, it sounds like a denial of the
dynamic mapping, which explicitly separates the identification of a capture
(actually capture encoding) from an SSRC.

	Thanks,
	Paul

> the RTP and SDP would of course be submitted as documents in the 
> AVTCORE and MMUSIC WGs.
>
> On Tue, Oct 30, 2012 at 4:42 PM, Roni Even 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Hi Mary,
>
> [[email-masked] <mailto:[email-masked]>] on behalf of 
> Mary Barnes [[email-masked] 
> <mailto:[email-masked]>]
> I think this is a reasonable split and I don't think it's that much of 
> a killer task to do so.  We have talked in the past about whether we 
> The chairs have delayed updating our milestones since we had not 
> decided individual deliverables related to the solution.
>
> people could please respond as to whether they support the general 
> idea of splitting the work into the following documents/deliverables:
>
> 1) Framework
>
> 2) Data model
>
> 3) Protocol
>
> 4) Call Flows
>
> I do have one comment about the "orchestration document" as I think 
> that might be appropriate for the framework, but we could certainly 
> work on that separately and decide later.
>
> Thanks,
>
> Mary.
>
> On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Hi Christian,
>
> c) move the XML schema to the data model document (final section of 
> the data model, which provides 'one possible' example of how to 
> formally describe the things in the document);
> enriched) in view of the proposed distribution of work inside the WG. 
> I would like it to represent an orchestration document, providing an

---

From: "Roni Even" <[email-masked]>
Date: Wed, 31 Oct 2012 15:17:29 +0200

Hi Simon,
This will make the framework empty, section 1-4 do not have any information
that merit a document.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Simon Pietro Romano
Sent: 30 October, 2012 12:24 PM
To: Christian Groves
Cc: [email-masked]
Subject: Re: [clue] Data model - agreement on objective and basic approach

Hi Christian,

Obviously, the resulting framework document should be revised (and
enriched) in view of the proposed distribution of work inside the WG. I
would like it to represent an orchestration document, providing an overview
of issues, requirements, architecture and protocols. A sort of summary
reference for all of the related "drill-down" documents, each expanding on a
specific WG item (data model, protocol, call flows, etc.).

Cheers,

Simon

Il 30/10/2012 10:33, Christian Groves ha scritto:
>> properly called a 'CLUE instance'; 2. UML sequence diagrams can be 
>> adopted to describe CLUE call flows, i.e. the DYNAMIC part of the 
>> framework, which clearly envisages the co-existence of SDP and CLUE 
>> protocol messages. XML schemas are not suitable for this dynamic 
>> part.
>>
>>>> " The general agreement on the call is that the data model as 
>>>> reflected in draft-presta-clue-data-model-schema describes the data 
>>>> needed by the CLUE application"
>>>> I disagree that it reflects that data needed by a CLUE application 
>>>> and I explained why.
>>>
>>> OK, fair enough.
>>>
>>> - the data model represents the data to be exchanged in  clue 
>>> messages.
>>>
>>>> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
>>>>> My view is 'no". I still fail to see the need for the encoding 
>>>>> groups and individual encodes.
>>>>>
>>>>> In the current definition of capture scene, I am not sure what is 
>>>>> the meaning of different individual encodes and eventually the 
>>>>> receiver can define what it can receive (Typically H.264 is 
>>>>> symmetric in terms of profile but does not need to be in the 
>>>>> level) and can ask for specific resolution with the SDP image 
>>>>> attribute
>>>>
>>>> That is a separate question. If such changes were made it might 
>>>> affect a lot.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>>> Roni Even
>>>>>
>>>>> [mailto:[email-masked]] *On Behalf Of *Mary Barnes
>>>>> general agreement on the call is that the data model as reflected 
>>>>> in draft-presta-clue-data-model-schema describes the data needed 
>>>>> by the CLUE application - i.e., it's the CLUE instance concept. It 
>>>>> does not directly reflect the contents of a CLUE message.  The 
>>>>> application data would be used to populate CLUE messages, as well 
>>>>> as SDP and would reflect updates based on both the CLUE and SDP 
>>>>> signaling.
>>>>>
>>>>> discussions can be much more productive. If folks could please 
>>>>> reply "Yes" or "No" reflecting agreement with the above, that 
>>>>> would be helpful.  If you reply "No", please explain why.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Mary
>>>>>
>>>>> as CLUE WG co-chair
>>>>>
>>>>>
>>>>>
>> <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli  idioti. Ci 
>> rifletto un istante; e mi scoraggio>>. Magritte.
>>                      oooO

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Oct 2012 09:34:31 -0400

> (identified by SSRC) and Media Captures, it is true for static or dynamic

Oh, ok. Yes, I thought that was clear. It is my understanding that the 
static mapping intends to associate a particular capture encoding with a 
particular *ssrc*, and so to the RTP stream with that ssrc. That only 
works when the capture encoding has a 1:1 association with a single ssrc.

The point of the RTP extension for the dynamic mapping is to carry an 
identifier for the capture encoding, independent of ssrc. That way the 
capture encoding of an RTP stream can be identified even when the ssrc 
may change over time for that stream.

	Thanks,
	Paul

>>          reflected in
>>          affect a
> in
> reply

---

From: Mary Barnes <[email-masked]>
Date: Wed, 31 Oct 2012 09:05:43 -0500

Simon also suggested that we need to enrich the framework.  We have gotten
feedback in the past that it's difficult to read as I think there is a
middle level of detail that is missing.  We have had wonderful diagrams in
.ppts at the meetings but we have very few diagrams in the FW.  I think it
could help a lot to add some.

Mary.

On Wed, Oct 31, 2012 at 8:17 AM, Roni Even <[email-masked]> wrote:

> data
> hand

---

From: "Roni Even" <[email-masked]>
Date: Wed, 31 Oct 2012 16:03:33 +0200

Hi Paul,
See inline
I am not sure What we are arguing, the mapping is always needed. I do no
understand why you mention static and dynamic mapping.
Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 31 October, 2012 3:35 PM
To: Roni Even
Cc: [email-masked]
Subject: Re: [clue] Data model - agreement on objective and basic approach

On 10/31/12 2:43 AM, Roni Even wrote:
> (identified by SSRC) and Media Captures, it is true for static or 
> dynamic mapping.

Oh, ok. Yes, I thought that was clear. It is my understanding that the
static mapping intends to associate a particular capture encoding with a
particular *ssrc*, and so to the RTP stream with that ssrc. That only works
when the capture encoding has a 1:1 association with a single ssrc.

Roni: the last sentence is the common usage today where the SSRC is fixed by
the sending EP or by the MCU who terminates the RTCP.

The point of the RTP extension for the dynamic mapping is to carry an
identifier for the capture encoding, independent of ssrc. That way the
capture encoding of an RTP stream can be identified even when the ssrc may
change over time for that stream.

Roni: The change may be signaled with the CSRC for the static use case.

	Thanks,
	Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Paul Kyzivat
>> *From:[email-masked] [mailto:[email-masked]] *On 
>> Behalf Of *Mary Barnes
>> However, it may be better to keep that document separate for a while 
>> - that is also the model that SIPREC used/
>>
>> Mary.
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>
>> I think this is a reasonable split and I don't think it's that much 
>> of a killer task to do so.  We have talked in the past about whether 
>> we should split some material from the framework.  I think doing so 
>> will make it easier for individuals to edit the various pieces.  We 
>> will of course have to ensure consistency.  However,  this approach adds
some
>> what worked very well for the XCON work and it's quite similar to 
>> what other WGs are doing (e.g., SIPREC).
>>
>>          draft-presta-clue-data-model-schema describes the data 
>> needed by
> the
>>          CLUE application - i.e., it's the CLUE instance concept. It 
>> does
> not
<mailto:[email-masked]>

---

From: Christian Groves <[email-masked]>
Date: Thu, 01 Nov 2012 11:45:56 +1100

I agree the framework document in its current state isn't the easiest or 
most precise document so we need to do something to make it easier to 
understand. However I agree with Roni that removing sections 1-4 doesn't 
leave much.

I still am not convinced about having a data model document related to a 
CLUE instance. What I'm trying to see is the actual benefit for this 
approach? Is it to help implementers? Is it to help us as specifiers?
I know XCON and SIPREC followed this approach but from my view as a 
casual observer of the process is that these activities took a long time 
to completion. My fear is that Simon will be the only one who actually 
understands the data model well. Others will just be put off from 
looking closely at it because of the syntax.

Regards, Christian

On 1/11/2012 1:05 AM, Mary Barnes wrote:
> Simon also suggested that we need to enrich the framework.  We have 
> gotten feedback in the past that it's difficult to read as I think 
> there is a middle level of detail that is missing.  We have had 
> wonderful diagrams in .ppts at the meetings but we have very few 
> diagrams in the FW.  I think it could help a lot to add some.
>
> Mary.
>
>
> On Wed, Oct 31, 2012 at 8:17 AM, Roni Even <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Simon,
>     Behalf Of
>     Cc: [email-masked] <mailto:[email-masked]>
>     overview
>     >>> Mary can comment, but my take was that the point of her
>     question was
>     >>> to distinguish between two alternatives:
>     On Behalf Of Paul Kyzivat
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>>> You seem to be saying that you disagree with the framework as
>     it is
>     >>>> - that
>     >>>>> [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Mary Barnes
>              Phone: +39 081 7683823 <tel:%2B39%20081%207683823> --
>     Fax: +39 081 7684219 <tel:%2B39%20081%207684219>