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

["Vijay K. Gurbani" <[e-mail]>]

On 04/20/2010 02:44 AM, Saverio Niccolini wrote:
> If there is something unclear, let us know such that we can improve it
> in the next version of the draft.

Dear Saverio: I am not sure whether my doubts stem from the
draft being unclear or my lack of familiarity with ipfix.  It is
probably the latter, if anything; in that case, you of
course do not have to do any changes to the draft.

More inline.

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

> -- (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.)

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

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

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/