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

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 19 Apr 2010 16:28:55 +0200

Dear all,

we just submitted a new version of the draft (now available at
http://www.ietf.org/id/draft-niccolini-sipclf-ipfix-02.txt).

This version improves the example where we used a real private 
enterprise (PEN) number 35566 (which is controlled by one of 
the authors of the draft).

We also added a list of open points that we think should be 
addressed in future version of the draft.

Before moving into addressing those, we would appreciate feedback
to the example that was explicitly requested by the WG and the AD.

Thanks,
Saverio

============================================================
Dr. Saverio Niccolini
Manager, Real-Time Communications Group
NEC Laboratories Europe, Network Research Division     
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked]
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]]
> Sent: 19 April 2010 16:26
> To: Saverio Niccolini
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: New Version Notification for draft-niccolini-sipclf-ipfix-02
> 
> 
> A new version of I-D, draft-niccolini-sipclf-ipfix-02.txt has been
> successfully submitted by Saverio Niccolini and posted to the IETF
> repository.
> 
> Filename:	 draft-niccolini-sipclf-ipfix
> Revision:	 02
> Title:		 Advantages of using an IPFIX File Format for SIPCLF
> Creation_date:	 2010-04-19
> WG ID:		 Independent Submission
> Number_of_pages: 16
> 
> Abstract:
> The SIPCLF WG is currently trying to identify file format(s) suitable
> for its scope as defined in the current charter.  The group has so
> far received proposals for a text format and an indexed-text format
> that are going to be soon combined.  Several people believe that
> IPFIX could be a valid alternative to these two proposals for several
> reasons detailed in this document.
> 
> This document discusses the main advantages related to the usage of
> IPFIX file format for SIPCLF.  Additionally it gives preliminary
> indications on the basic set of information elements that would need
> to be defined by the SIPCLF WG.
> 
> 
> 
> The IETF Secretariat.
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 19 Apr 2010 17:22:29 -0500

> to the example that was explicitly requested by the WG and the AD.

Saverio: Thanks for getting this out.  I am not sure I understand
the mechanics of ipfix completely, but the draft helps me
conceptualize the approach a bit more.

In any case, I had one comment on Section 5.  The text presented
in S5 is more of a data model than an information model.  If I
read rfc3444 correctly, a "data model" determines the structure
of data elements (including legal values for the contents of these)
and the relationship among the data elements.  An "information
model", on the other hand, is the modeling of entities in a
system and their relationship (these are, fortunately, the
most generally accepted definitions for the terms in the
industry and academia.)

The problem-statement draft already contains a data model [1]
that I have been using for a long time [2].  In the next revision
of the problem-statement draft I am working on now, I will
present a more formal definition of the data model, including
the relationship between the data elements (some of which is
captured in the precursor draft [2].)  I think it may be best
to leave the data model in one place --- the problem-statement
draft --- and have the individual solution drafts show the
format of the sipclf record.

I would love your feedback on the data model and its contents
once I get the updated problem-statement draft out later this
week.

[1] http://tools.ietf.org/html/draft-ietf-sipclf-problem-statement-01
[2] http://tools.ietf.org/html/draft-gurbani-sipping-clf-01

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/

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 20 Apr 2010 09:44:47 +0200

Dear Vijay,

> conceptualize the approach a bit more.

If there is something unclear, let us know such that we can improve it
in the next version of the draft.

> in S5 is more of a data model than an information model. 

Indeed, we supposed we refer to your draft for the place where the
information model is defined (or any draft that does that), we just 
follow what the draft say and we implement it in a data model following 
IPFIX principles.

> If I read rfc3444 correctly, a "data model" determines the structure

yes, we are on the same page.

> format of the sipclf record.

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)

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

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? 

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?

> once I get the updated problem-statement draft out later this

I can give feedback on that but would like to clarify the strategy moving
forward and which draft needs to address which points (problem statement,
information model, data models)

Thanks,
Saverio

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 20 Apr 2010 09:01:44 -0500

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

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

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

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

> -- another draft where we describe the information model and the two data

I think we can revisit the drafts decision once we reach some
consensus on the information model vs. data model.

Thoughts?

Thanks,

- vijay

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 20 Apr 2010 16:33:18 +0200

Dear Vijay,

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

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

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

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

> 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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 20 Apr 2010 09:56:19 -0500

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

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

> model and the data model (where the information model defines the

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

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 20 Apr 2010 17:57:18 +0200

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

> From: Vijay K. Gurbani [mailto:[email-masked]]
> 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
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 20 Apr 2010 11:17:57 -0500

> -b- the other drafts will define the "encoding" of the above

Dear Saverio: OK.  I will respin a new version of the problem-
statement shortly (probably this week.)  Please do have a look
at it then and make sure that I do not deviate too much from
above.  I will also define the terminology, etc. that we
hashed out in the emails.

Thank you much.

- vijay