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

From: Mary Barnes <[email-masked]>
Date: Thu, 1 Nov 2012 08:12:54 -0500

On Wed, Oct 31, 2012 at 7:45 PM, Christian Groves <
[email-masked]> wrote:

> 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?

[MB] The benefit of the data model is that it takes the data as defined in
the framework to a lower level of abstraction that can be thus used as
elements in a protocol.  [/MB]

Is it to help implementers?

[MB] The implementers will use it as a reference within the context of the
protocol. [/MB]

Is it to help us as specifiers?
[MB] Yes. This is an objected oriented design model - you define the data
you need for the functionality and then define the mechanisms for creating,
updating, etc. [/MB]

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.

[MB] The data model was the last thing that kept any of these WGs from
making good progress. The XCON data model was started well before any of
the other aspects of the protocol.  SIPREC is moving along about as a good
of a piece as many other WGs, so I'm not sure why you have that specific
perception of that WG. [/MB]

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.
>
[MB] I personally find that quite silly since XML schemas are very, very
commonly used in IETF protocol documents these days.  You haven't been on
the design team calls, but we had some very useful discussions using the
schema as a starting point.  It helps very much to have something concrete
on the table and think most folks are now pretty familiar with ready XML
schemas.  For folks that aren't, there are quite a few useful books and
websites.  There are certainly some nuances that you need to be aware of to
use properly, but it's pretty easy to learn enough to interpret the schema.
 We would get the XML gurus to review the schema before progressing
anything.
[/MB]

>
> 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,
>>     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]>
>>     [mailto:[email-masked] <mailto:[email-masked]>**] On
>>     Behalf Of
>>     Simon Pietro Romano
>>     Sent: 30 October, 2012 12:24 PM
>>     To: Christian Groves
>>     Cc: [email-masked] <mailto:[email-masked]>
>>     Subject: Re: [clue] Data model - agreement on objective and basic
>>     approach
>>
>>     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
>>     >
>>     > 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).
>>     >>
>>     >> 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:
>>     >>
>>     >>> On 10/29/12 6:23 PM, Roni Even wrote:
>>     >>>> 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.
>>     >>>
>>     >>> 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
>>     >>>
>>     >>>> 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
>>     >>>>
>>     >>>> 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.
>>     >>>>>
>>     >>>>> 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
>>     >>>>
>>     >>>> 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]>
>>     <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
>>     >>>>>
>>     >>>>> 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
>>     >>>>>
>>     >>>>>
>>     >>>>>
>>     >>>>> ______________________________**_________________
>>     >>>>> clue mailing list
>>     >>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>>
>>     <mailto:[email-masked]>>
>>     >>>>> https://www.ietf.org/mailman/**listinfo/clue<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<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<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]>>
>>
>>     >>
>>     >> <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli  idioti. Ci
>>     >> rifletto un istante; e mi scoraggio>>. Magritte.
>>     >>                      oooO
>>     >>   ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>>     >>        \ (            (   )
>>     >>                         \_)          ) /
>>     >>                          (_/
>>     >>
>>     >>
>>     >>
>>     >>
>>     >>
>>     >>
>>     >>
>>     >> ______________________________**_________________
>>     >> clue mailing list
>>     >> [email-masked] <mailto:[email-masked]>
>>     >> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>     >
>>     > ______________________________**_________________
>>     > clue mailing list
>>     > [email-masked] <mailto:[email-masked]>
>>     > https://www.ietf.org/mailman/**listinfo/clue<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<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~~~~~~~~~~~~~~~~~~~~~~~~~
>>                                \ (    (   )
>>                                 \_)    ) /
>>                                       (_/
>>
>>     ______________________________**_________________
>>     clue mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>>     ______________________________**_________________
>>     clue mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>>
>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Nov 2012 11:21:28 -0400

On 10/30/12 4:03 AM, 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.

I agree with the above.

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

I don't want this to become a point of disagreement.

I think it is important to formally define the data and data 
relationships we are talking about. UML and XML both do that, using 
different approaches and at somewhat different levels of abstraction.

*My* preference for UML is that it is at a higher level of abstraction - 
it is entirely divorced from encodings. But XML can be used as a 
modeling tool even when it is not intended to be used as an encoding.

The most important thing is that the people doing the work all 
understand the model. More people are comfortable that they can 
understand an XML model, so I agreed with going that way.

But then we need need to be careful that people understand when the XML 
is intended as a *model*, and when it is intended to be used as an 
*encoding*.

> 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';

IMO, regardless of intent, it is currently hard to tell by looking 
whether the current version of the model is a representation of an 
*instance* or of an *advertisement*.

ISTM that the "clueInfo" element maps almost 1:1 onto an advertisement.

An instance will require more state. E.g.
- the content of the most recently sent advertisement
- the content of the most recently received configuration
- the content of the most recently completed SDP O/A exchange
- the mapping of the configuration to physical resources such as
   physical devices, encoders, decoders, etc.

This is tricky. Some of the information about resources is fundamentally 
implementation specific, so finding where to draw the line between what 
must be modeled and what must not is hard.

	Thanks,
	Paul

> 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
>
>
>>> 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.
>>
>> Mary can comment, but my take was that the point of her question was
>> - the data model represents the data to be exchanged in
>>  clue messages.
>>
>> 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
>>>
>>> [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
>>>
>>> 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
>>> 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
>>>> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> clue mailing list
>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> https://www.ietf.org/mailman/listinfo/clue
>>>
>>>
>>
>> _______________________________________________
>> clue mailing list
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
>        _\\|//_
>        ( O-O )
>     ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> Simon Pietro Romano
>               Phone: +39 081 7683823 -- Fax: +39 081 7683816
>      <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Nov 2012 11:55:10 -0400

Simon,

It is good to get a fresh perspective from someone who hasn't lived 
through the evolution of the current documents.

I don't really know whether to comment on this as a chair or as an 
individual, or even how to distinguish the two. For the moment lets 
assume that the following comments are from me as an individual.

> b) move sections 5 through 8 to the data model document

IMO *moving* 5-8 to the data model would "gut" the framework.
A lot of the descriptive information in these sections still needs to be 
in the framework. Some of the detail about specific elements, such as 
the lowest level elements and/or the values they can take on, would 
perhaps be better if moved to the data model, near to the schema 
definitions of them. (That will help minimize the chances for divergence 
with the schema, and remove unnecessary detail from the framework.) The 
stuff that remains in the framework will of course need to be repeated, 
with more detail, in 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);

At the expense of some difficulty in maintaining the document, I would 
find it helpful to have *elements* of the schema defined "in line" in 
the data model document, with the textual description of the element. 
Then a consolidated schema at the end.

> d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the

Again, I think it would gut the framework to move this entirely.

Now that I look again, I find an asymmetry in the document. Section 9 is 
largely a discussion of what will be a Configuration message. But the 
description of what will be the Advertisement is spread across section 
6-8. And 9.4 is really a high level intro to the complete protocol.

I think the framework certainly needs something akin to the figure in 
9.4. (But not precisely that figure.) I expect a protocol document to 
extensively elaborate on this and coordinate it with the information 
conveyed in sip.

> e) move subsection 9.4 to the call flows document;

No. *This* (or an improved version) is much more abstract that what I 
expect in a call flow document. I don't see how we can have a framework, 
or a protocol document, that doesn't have something like this in it.

> f) move section 10 to the data model document;

I agree that the framework is probably the wrong place for a discussion 
of extensibility. But addressing extensibility only in the data model 
document also isn't the answer.

Certainly the protocol document needs to discuss extensibility.

Depending on details of the division between protocol and data model, 
the data model doc may also need to address it.

(The *encodings* of information from the data model that are exchanged 
via the protocol need to have and extensibility story. If those 
encodings are defined in the data model doc, then that is where to 
address it.)

> g) move section 11 to the call flows document.

Yes.

	Thanks,
	Paul

> enriched) in view of the proposed distribution of work inside the WG. I
> 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.).
>
> 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
>
>
>
>
>> the framework can you be a bit more specific as to what parts you want
>> removed?
>>
>> Regards, Christian
>>
>>> model or the envisaged call flows). So, unless we have misinterpreted
>>> the above document(s) (which is obviously possible), we should first
>>> agreed-upon CLUE architecture. Once done with this, we can fine-tune
>>> opinion that we should remove from the framework document all of the
>>> clear definition of framework components and interfaces. I might look
>>> how SDP O/A and CLUE protocol messages concur in effectively setting
>>> up a CLUE session).
>>>
>>> properly called a 'CLUE instance';
>>>>> You seem to be saying that you disagree with the framework as it is
>>>>> - that
>>>>> affect a
>>> [email-masked]
>> [email-masked]

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 01 Nov 2012 17:04:45 +0100

Hi Paul,

I'm ok with your revised view of my rough guess at documents optimization. As I said, it really was just a rough approach. I'll be happy to further elaborate on all this, if you all think this can prove useful. Most importantly, I would like, together with you and Roberta, to focus on your call flows skeleton and ladder diagram, so to arrive at a first detailed idea of the structure of the CLUE protocol, in terms of proper interaction between O/A, advertisement and configure messages.

Simon

Paul Kyzivat <[email-masked]> ha scritto:

>>>>>> and I
>>>>>>> directly reflect the contents of a CLUE message.  The
>application
>>>>>>> data
>reply

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Nov 2012 12:15:48 -0400

On 11/1/12 12:04 PM, Simon Pietro Romano wrote:
> Hi Paul,
>
> I'm ok with your revised view of my rough guess at documents
> optimization. As I said, it really was just a rough approach. I'll be
> happy to further elaborate on all this, if you all think this can prove
> useful.

Next week should provide good opportunity to discuss this.

> Most importantly, I would like, together with you and Roberta,
> to focus on your call flows skeleton and ladder diagram, so to arrive at
> a first detailed idea of the structure of the CLUE protocol, in terms of
> proper interaction between O/A, advertisement and configure messages.

I hope you can tell that I also consider this a priority!

I am finding it remarkably difficult to sort out. IMO this is exposing 
differences of opinion about stuff that we seemingly had already agreed 
upon. That tells me that what we have written in the framework, etc. is 
not sufficiently detailed for everyone to understand in a consistent way.

I hope we make progress on this next week.

	Thanks,
	Paul

>     A lot of the descriptive information in these sections still!
>        needs
>     to be
>     find it helpful to have *elements* of the schema defined "in l!
>       ine" in
>
>     conveyed in si!
>       p.
>     the data model doc may also !
>       need to
>     address it.
>
>         e! xpanding on a specific WG item (data model, protocol, call
>         flows, etc.).
>
>         material at
>                 just to be clear on ! the current structure of the data
>                 model schema:
>                 (i) general framework; (ii) data model; (iii) clue
>                 protocol (wi! th
>                         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.
>
>                         Sent: 29 October, 2012 9:46 PM!
>                         ISTM that you are answering a different question
>                         than the one Mary
>                         asked.
>                             directly reflect the contents of a CLUE
>                             message. The application
>                             data
>                             ------------------------------------------------------------------------
>
>                             clue mailing list
>                         ------------------------------------------------------------------------
>
>                         clue mailing list
>                     ------------------------------------------------------------------------
>
>                     clue mailing list
>                 ------------------------------------------------------------------------
>
>                 clue mailing list
>                 [email-masked]
>             ------------------------------------------------------------------------
>
>             clue mailing list
>             [email-masked]
>     ------------------------------------------------------------------------
>
>     clue mailing list
>     [email-masked]

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Nov 2012 20:24:45 +1100

Hello Mary,

Please see my replies below.

Regards, Christian
On 2/11/2012 12:12 AM, Mary Barnes wrote:
> On Wed, Oct 31, 2012 at 7:45 PM, Christian Groves 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     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?
>
> [MB] The benefit of the data model is that it takes the data as 
> defined in the framework to a lower level of abstraction that can be 
> thus used as elements in a protocol.  [/MB]
[CNG] If the CLUE data instance equals the CLUE advertisement then to me 
the most important documents will be the framework which gives the 
overview of how CLUE works and the protocol document itself.

> [MB] The implementers will use it as a reference within the context of 
> the protocol. [/MB]
[CNG] I assume that the protocol document will take precedence in case 
of any discrepancies?

> [MB] Yes. This is an objected oriented design model - you define the 
> data you need for the functionality and then define the mechanisms for 
> creating, updating, etc. [/MB]
>
>     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.
>
> making good progress. The XCON data model was started well before any 
> of the other aspects of the protocol.  SIPREC is moving along about as 
> a good of a piece as many other WGs, so I'm not sure why you have that 
> specific perception of that WG. [/MB]
>
>     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.
>
> [MB] I personally find that quite silly since XML schemas are very, 
> very commonly used in IETF protocol documents these days.  You haven't 
> been on the design team calls, but we had some very useful discussions 
> using the schema as a starting point.  It helps very much to have 
> something concrete on the table and think most folks are now pretty 
> familiar with ready XML schemas.  For folks that aren't, there are 
> quite a few useful books and websites.  There are certainly some 
> nuances that you need to be aware of to use properly, but it's pretty 
> easy to learn enough to interpret the schema.  We would get the XML 
> gurus to review the schema before progressing anything.
> [/MB]
[CNG] Silly? I seen enough protocol development over the years to know 
that people have different strengths in different schemes. I though it 
would be worth raising this to see if any people on the list weren't 
comfortable with XML. I'm glad to hear that it has been useful on the 
phone calls.

>         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]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>             Hi Simon,
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>] On
>             Behalf Of
>             Simon Pietro Romano
>         protocol (with
>             >>>> reflected in draft-presta-clue-data-model-schema
>         describes
>             the data
>             >>>> From: [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>             <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>]
>             <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>             >>>>> *From:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[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
>
>             >>>>> in draft-presta-clue-data-model-schema describes the
>         data needed
>         <mailto:[email-masked] <mailto:[email-masked]>
>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>             >>   Phone: +39 081 7683823 <tel:%2B39%20081%207683823>
>         <tel:%2B39%20081%207683823> -- Fax:
>         <tel:%2B39%20081%207683816>
>             <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>             >>
>          idioti. Ci
>                      Phone: +39 081 7683823
>         <tel:%2B39%20081%207683823> <tel:%2B39%20081%207683823> --
>         <tel:%2B39%20081%207684219>
>                              e-mail: [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>         http://www.comics.unina.it/simonpietro.romano
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Nov 2012 20:36:14 +1100

Hello Paul,

I had the same confusion and concern as you below. I think that keeping 
the data model just to the advertisement would simplify things. If an 
*instance* includes the things you mention below it seems to me that the 
data model is going beyond a protocol to communicate captures. The model 
starts to get into the realm of defining overall multistream conference 
state.

Regards, Christian

> This is tricky. Some of the information about resources is 
> fundamentally implementation specific, so finding where to draw the 
> line between what must be modeled and what must not is hard.
>
>     Thanks,
>     Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Nov 2012 09:42:30 -0400

Christian,

> comfortable with XML. I'm glad to hear that it has been useful on the

At the end of the day we have to adopt *some* formalism about data - at 
least the data carried in protocol messages. Most new things being 
developed today are using XML.

I expect that people involved in IETF at a deep enough level to care 
about the details of the protocol will learn the formalisms needed to 
understand the protocol definitions. IMO people who can't at least 
*read* an xml schema should consider a new line of work.

(I feel the same about UML, but it is used less often in this context so 
I am willing to cut people a little slack on it.)

That does't mean everyone has to be an expert on XML. I'm certainly not. 
I can construct most of a simple schema using some cut and paste. But 
I'm not competent make good decisions on the best way to represent 
things, or how to represent some complex things. So I look for someone 
like Roberta to help with things like that.

	Thanks,
	Paul