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

[Christian Groves <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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: [e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>] On
>     Behalf Of
>     Simon Pietro Romano
>     Sent: 30 October, 2012 12:24 PM
>     To: Christian Groves
>     Cc: [e-mail] <mailto:[e-mail]>
>     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: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >>>> [mailto:[e-mail] <mailto:[e-mail]>]
>     On Behalf Of Paul Kyzivat
>     >>>> Sent: 29 October, 2012 9:46 PM
>     >>>> To: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >>>> 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:*[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >>>>> [mailto:[e-mail]
>     <mailto:[e-mail]>] *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
>     >>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >>>>> https://www.ietf.org/mailman/listinfo/clue
>     >>>>>
>     >>>>
>     >>>> _______________________________________________
>     >>>> clue mailing list
>     >>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >>>> https://www.ietf.org/mailman/listinfo/clue
>     >>>>
>     >>>>
>     >>>
>     >>> _______________________________________________
>     >>> clue mailing list
>     >>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >>> https://www.ietf.org/mailman/listinfo/clue
>     >>>
>     >>
>     >> _\\|//_
>     >>       ( O-O )
>     >>  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>     >> Simon Pietro Romano
>     >> Universita' di Napoli Federico II
>     >>  Computer Engineering Department
>     >>   Phone: [phone] <tel:%2B39%20081%207683823> -- Fax:
>     [phone] <tel:%2B39%20081%207683816>
>     >>  e-mail: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >>
>     >> <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli  idioti. Ci
>     >> rifletto un istante; e mi scoraggio>>. Magritte.
>     >>                      oooO
>     >>   ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>     >>        \ (            (   )
>     >>                         \_)          ) /
>     >>                          (_/
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> clue mailing list
>     >> [e-mail] <mailto:[e-mail]>
>     >> https://www.ietf.org/mailman/listinfo/clue
>     >
>     > _______________________________________________
>     > clue mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/clue
>     >
>
>     --
>                                  _\\|//_
>                                  ( O-O )
>     ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                          Simon Pietro Romano
>                    Universita' di Napoli Federico II
>                       Computer Science Department
>              Phone: [phone] <tel:%2B39%20081%207683823> --
>     Fax: [phone] <tel:%2B39%20081%207684219>
>                      e-mail: [e-mail] <mailto:[e-mail]>
>     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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/clue
>
>     _______________________________________________
>     clue mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/clue
>
>