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

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

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 <[email-masked]>
Date: Tue, Oct 30, 2012 at 4:25 PM
Subject: Re: [clue] Data model - agreement on objective and basic approach
To: CLUE <[email-masked]>
Cc: Christian Groves <[email-masked]>, Simon Pietro Romano <
[email-masked]>, Paul Kyzivat <[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 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:

> 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]] On Behalf Of Paul
>>>>> Kyzivat
>>>>> Sent: 29 October, 2012 9:46 PM
>>>>> To: [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]] *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]>
>>>>>> 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>
>>>>>
>>>>>
>>>>>
>>>> ______________________________**_________________
>>>> 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 Engineering Department
>>>   Phone: +39 081 7683823 -- Fax: +39 081 7683816
>>>  e-mail: [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]
>>> 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
>               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<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]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

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

Mary,

I am OK with having these four documents as long as we are not stating that
these are the only documents that will be delivered by the WG as first
priority.

As for the content, we will need to discuss since Simon’s proposal makes the
framework an empty document.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: 30 October, 2012 11:42 PM
To: CLUE
Subject: [clue] Consensus Call: WG deliverables - splitting some material
from framework document.

Thanks,

Mary. 

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

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,
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.

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-----
From: [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]>
Subject: Re: [clue] Data model - agreement on objective and basic approach

Hi,

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

draft-presta-clue-data-model-schema describes the data needed by the

Regards,

Mary

as CLUE WG co-chair

_______________________________________________
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

_______________________________________________
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 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]>

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

_______________________________________________
clue mailing list
[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]
          http://www.comics.unina.it/simonpietro.romano

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

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

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 31 Oct 2012 14:38:57 +0100

> As for the content, we will need to discuss since Simon’s proposal makes the framework an empty document.

:-)...I didn't mean that I want the framework document to be an empty one. I just pointed out that it should become the so-called orchestration document, containing the high level view of the entire work we're carrying out in CLUE. After reading the framework, people should be supposed to have a clear idea of the overall architecture, while being 'forwarded' to the other documents for the details. Under this perspective, the framework deserves the most important role among the WG items.
I did not even aim at restricting the scope of the WG, obviously. 

Simon

>  
> Roni
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
> Subject: [clue] Consensus Call: WG deliverables - splitting some material from framework document.
>  
> 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. 
> 
> Cc: Christian Groves <[email-masked]>, Simon Pietro Romano <[email-masked]>, Paul Kyzivat <[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 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:
> 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);
> d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protocol 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
> 
> 
> 
> 
> 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 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
> 
> 
> 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
> 
> 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

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