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

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

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/