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

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

Dear Vijay,

> > Here we need some clarifications:
> >
> > -- (in my opinion) you can not define a data model if you first do
> > not define an information model, the data model is a mapping of your
> > information model into particular data structures (it is like the
> "implementation" of the "concepts" defined in the information model,
> > the relationship needs first of all to be defined in the information 
> > model)
>
> Thanks for starting off the conversation.  So let's drill down
> a bit on this to uncover the details of these models.
>
> In SIPCLF, the information model seems fairly simple to me.  We have
> two entities -- a SIPCLF producer (proxy, UAC, UAS, B2BUA, Registrar,
> Redirect server) and a SIPCLF consumer.  There is a one-to-many
> relationship between the producer and consumer (i.e., for a single
> SIPCLF producer, many consumers may be interested in the content
> it is producing.)  The producer and consumer do not communicate
> directly with each other, where communications is defined as sending
> direct messages over some channel.  Rather, the producer and the
> consumer have a synchronous I/O relationship between them based on a
> shared resource --- the SIPCLF file.
>
> The information model does not seem to be too complex here, but
> perhaps I am missing something...?  Would such an information model
> work for ipfix?  Or do we need to include other entities in the
> mix, like the collector, etc.?

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

> > -- (in my opinion) Section 8. of your draft [1] contains a start to
> > the definition of information elements to be included in the
> > information model, the information elements are independent from the
> > particular data model chosen, the relationship needs still to be
> defined
>
> It seems --- and please do correct me if I am in error --- that you
> view S8 of [1] as an information model.  That was not my intent.  My
> intent was for it to be a data model; i.e., define in some detail
> the contents of the individual data elements that will be logged;
> i.e., the structure of data elements (including legal values for the
> contents of these) and the relationship among the data elements (and
> by relationship I mean the idea that the server transaction ID can
> be used to create a call-tree of the session as it forked.)

A data model for me is something that specifies how to encode the
elements of the information model.
E.g., binary (like MIB or IPFIX) or textual (like XML).

> > If you want to see what I mean by the differences between information
> > model and data model, you can refer to another piece of work I did
> for
> > the traceroute use case: http://tools.ietf.org/html/rfc5388
> > My understanding was that the information model should be common and
> > thus described in only one place, but we will have multiple data
> models
> > (one ASCII and one binary/IPFIX).
> >
> > What is your view on that?
>
> I scanned at rfc5388, and it seems that ipfix consider the data
> elements
> themselves to be the part of the information model.  I think that is
> where the disconnect is.  My view of information model is what I
> presented above -- a rough ER diagram.  The data model then drills
> down to the "byte order level" to fill in the details of the
> communication primitives between the entities.
>
> What needs to be logged --- the specific SIP headers, etc. --- needs
> to be defined at one place.  How they are logged --- indexed ASCII,
> ipfix --- will be described in separate drafts.  In other words, we
> cannot have indexed-ASCII draft accord one set of semantics to the
> server transaction ID while the ipfix accords a completely different
> set to the same logged header.

I agree with that. I think the problem here is just terminology, nothing more.

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.

> > Also: I do not think a problem statement draft is the right place to
> > place an information model and a data model, maybe we need separate
> drafts
> > for that.
> >
> > Maybe we need:
> > -- one problem statement
> > -- another draft where we describe the information model and the two
> data
> > models?
>
> I think we can revisit the drafts decision once we reach some
> consensus on the information model vs. data model.

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
among the information elements that are linked to particular data types)
-- other draft(s) specifying the encodings

My fear is that if your drafts describes problem statement, info model and
data model then is getting quite overloaded and my suggestion would be to
split this in two drafts, but we can discuss that later on, I agree.

Other than terminology, I will be happy to review and help defining your
information/data model and the information elements you are defining...

Let me know what you think,
Saverio

>
> Thoughts?
>
> 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/

============================================================
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