Re: [sip-clf] FW: New Version Notification for draft-niccolini-sipclf-ipfix-02

["Saverio Niccolini" <[e-mail]>]

Hi Vijay,

what about the following:
-a- what you need to define in your draft are the "semantics",
the "cardinality" and the "inter-relations" of the information 
to appear in the record
-b- the other drafts will define the "encoding" of the above

Cheers,
Saverio

P.S.: in my view of the world (reflected in RFC5388) -a- is the 
information model, while -b- is the data model, but this is not
important now...

============================================================
Dr. Saverio Niccolini
Manager, Real-Time Communications Group
NEC Laboratories Europe, Network Research Division     
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     [phone]
Fax:     [phone]
e-mail:  [e-mail]
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

  


> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[e-mail]]
> Sent: 20 April 2010 16:56
> To: Saverio Niccolini
> Cc: SIP-CLF Mailing List
> Subject: Re: [sip-clf] FW: New Version Notification for draft-
> niccolini-sipclf-ipfix-02
> 
> Dear Saverio: Thank you for the response.  I think we are
> getting closer to an agreement.  More inline.
> 
> On 04/20/2010 09:33 AM, Saverio Niccolini wrote:
> > Well, I do not think what you described above is an information
> model,
> > at least not the way I mean it.
> >
> > I would rather call it: "high level architecture", an information
> model
> > is something completely different (in my opinion):
> >
> > -a- the information model is composed of information elements; for
> defining
> > these information elements, a template is used
> >
> > for the SIPCLF a template for the information element would be
> something like:
> > -- name of the information element
> > -- description
> > -- data type
> > -- units
> > something like the first table in
> > http://tools.ietf.org/html/draft-niccolini-sipclf-ipfix-02#section-5
> > (here we are missing units but we have name, description and data
> type)
> > to be univocally identified, data types needs to be defined (e.g.,
> what a
> > string is, etc.)
> >
> > -b- the information model defines also the way the information
> elements are
> > linked together in records:
> > one record has 1 (optional) element of name1, 1..4 elements of name2,
> etc.
> > something like the request record template that is also in the same
> section 5
> > of our draft
> 
> But this is a very ipfix-centric view of laying out an information
> model.  There is nothing wrong with this, of course, just that I don't
> think we should define the bounds of the sipclf problem in these terms.
> 
> I would really like to keep the information model as generic as
> possible --- i.e., an ER diagram is a valid information model in
> many accepted contexts, and it is not necessary that the ER diagram
> contain discrete information elements exchanged between the entities.
> What it does contain are the relationships between the entities
> and the cardinalities of the entities with respect to each other.
> 
> > I agree with that. I think the problem here is just terminology,
> nothing more.
> 
> Yes, I agree.  We have to get to a common terminology.
> 
> > You are saying "information model" for what I think can be called
> "high level
> > architecture"
> > You are saying "data model" for what I think can be called
> "information model
> > plus data model"
> > You are saying "how they are logged" for what I think can be called
> "encoding
> > formats"
> >
> > I am fine with any definition, we just need to start speaking the
> same
> > language to avoid misunderstandings, what would you prefer in terms
> of
> > terminology? I am open to anything that makes sense.
> 
> Fair enough.  Let me suggest that we talk of a "high level
> architecture"
> and a "data model".  The high level architecture is essentially what I
> alluded to in my previous email --- a producer and a consumer and their
> relationship.  The data model is the set of SIP headers that will need
> to be logged and inter-data relationships.
> 
> Encoding formats is the specific realization of the SIPCLF process ---
> at this time we have two formats: indexed-ASCII and ipfix.
> 
> Please comment and provide some thoughts on the above.  If we agree
> then we can document and use the above terminology.
> 
> > Ok, after having seem your answer it seems you are driving towards:
> > -- one draft (yours) specifying the problem statement, the
> information
> > model and the data model (where the information model defines the
> > relationships
> 
> I am open to breaking apart the problem statement in its own draft
> and having a separate draft for the high level architecture and
> data model.  If we go that route, then we will need to modify the
> charter deliverable since it now states that "... [the problem
> statement draft] analysis will identify the required minimal
> information that must appear in any record."
> 
> Alternatively, I don't think that the high-level architecture is that
> complex and given the fact that the current problem statement already
> contains a data model, we can continue that path.
> 
> I am open to anything the WG decides.
> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> Web:   http://ect.bell-labs.com/who/vkg/