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

[Paul Kyzivat <[e-mail]>]

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

> Roni
>
> *From:*[e-mail] [mailto:[e-mail]] *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
>
> 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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
> 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:*[e-mail] <mailto:[e-mail]>
> [[e-mail] <mailto:[e-mail]>] on behalf of Mary
> Barnes [[e-mail] <mailto:[e-mail]>]
> *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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
> 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]
> https://www.ietf.org/mailman/listinfo/clue
>