[clue] Consensus Call: WG deliverables - splitting some material from framework document.

[Mary Barnes <[e-mail]>]

I should have changed the title since this discussion has morphed into a
more general discussion of WG deliverables.  Please see the proposal below
and respond as to whether you agree with the discrete deliverables as
listed.  If you don't agree, please explain why.  Please note we're not
discussing details - we just want to know if folks agree with the division
of work.

Thanks,
Mary.

---------- Forwarded message ----------
From: Mary Barnes <[e-mail]>
Date: Tue, Oct 30, 2012 at 4:25 PM
Subject: Re: [clue] Data model - agreement on objective and basic approach
To: CLUE <[e-mail]>
Cc: Christian Groves <[e-mail]>om>, Simon Pietro Romano <
[e-mail]>gt;, Paul Kyzivat <[e-mail]>


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]>wrote;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]] On Behalf Of Paul
>>>>> Kyzivat
>>>>> Sent: 29 October, 2012 9:46 PM
>>>>> To: [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]] *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]>
>>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>>
>>>>>>
>>>>> ______________________________**_________________
>>>>> clue mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>
>>>>>
>>>>>
>>>> ______________________________**_________________
>>>> clue mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> 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: [phone] -- Fax: [phone]
>>>  e-mail: [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]
>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>
>>
>> ______________________________**_________________
>> clue mailing list
>> [e-mail]
>> 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: [phone] -- Fax: [phone]
>                 e-mail: [e-mail]
>           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
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>