Re: [sip-clf] IETF 76 Minutes posted -> IPFIX questions

Hadriel Kaplan <> Thu, 03 December 2009 04:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 454073A67EA for <>; Wed, 2 Dec 2009 20:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 03t05H4XgrlE for <>; Wed, 2 Dec 2009 20:57:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 331A03A67C2 for <>; Wed, 2 Dec 2009 20:57:45 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 2 Dec 2009 23:57:36 -0500
Received: from ([]) by mail ([]) with mapi; Wed, 2 Dec 2009 23:57:35 -0500
From: Hadriel Kaplan <>
To: David B Harrington <>, 'SIP-CLF Mailing List' <>
Date: Wed, 2 Dec 2009 23:57:34 -0500
Thread-Topic: [sip-clf] IETF 76 Minutes posted -> IPFIX questions
Thread-Index: AcpzT0+vwKyeCHsER1OaA4fuiZY9wAAACZugABPLnxA=
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC31A12FB3B08@mail>
References: <> <108601ca7354$69e0d5b0$>
In-Reply-To: <108601ca7354$69e0d5b0$>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sip-clf] IETF 76 Minutes posted -> IPFIX questions
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Common Log File format discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Dec 2009 04:57:46 -0000

Right, I agree with you.  The trouble is we really do want it for multiple purposes. :)

But then I'm one of the ones who think IPFIX _is_ the right way to go anyway, because it has solved the problems and there's no point re-inventing the wheel.  I think it's just a bit daunting to people at first because they see a bunch of big RFC docs and assume it means a lot of work or complexity in implementation.

As for your question of: "Where does SIP typically run? on hosts? on routers? on middleboxes? in embedded systems? Would these environments have the same resources that web server environments typically have?"
The answer is it runs on all the above, and no not all of them have the same resources as web server environments. (which you probably knew when you asked it ;)


> -----Original Message-----
> From: [] On Behalf
> Of David B Harrington
> Sent: Wednesday, December 02, 2009 8:36 AM
> To: 'SIP-CLF Mailing List'
> Subject: Re: [sip-clf] IETF 76 Minutes posted -> IPFIX questions
> Hi,
> I have a concern with sipclf.
> I have been looking at "How to have a successful BOF":
> the goal of the
>    BOF is to demonstrate that the community has agreement that:
>       - there is a problem that needs solving, and the IETF is the
> right
>         group to attempt solving it.
>       - the scope of the problem is well defined and understood, that
>         is, people generally understand what the WG will work on (and
>         what it won't) and what its actual deliverables will be.
> Note the emphasis on what ***problem*** needs to be solved.
> The sipclf community decided "we need a logging file format"
> That is not a clear problem description; that is a solution - a
> partial solution.
> The members of the sipclf WG have very different problems they are
> trying to solve.
> Some want to dump everything so they can later grep to find entries.
> Some express concern about dumping everything and think maybe filters
> are needed to limit what gets dumped.
> Some want a dump from a single device.
> Some want to be able to reconstruct SIP conversations across multiple
> devices.
> I do not think the WG has consensus on what ***problem*** is being
> solved.
> The appropriate file format to use for a solution depends a lot on
> what problem you are trying to solve, and how the information will get
> used (and possibly moved).
> Some think the apache file format is a great starting place. I have
> concerns about modeling sipclf after a web-server logging format. Web
> servers typically run on hosts, with lots of CPU cycles and lots of
> disk storage. Very appropriate for logging EVERYTHING. Maybe I just
> don't know SIP well enough to understand the environments in which it
> runs. Where does SIP typically run? on hosts? on routers? on
> middleboxes? in embedded systems? Would these environments have the
> same resources that web server environments typically have?
> IPFIX may not be the right solution. But IPFIX has considered issues
> of CPU impact, limited storage, filters to select subsets of
> information to log, how to move the data off the box quickly, etc. The
> sipclf WG has not done that analysis because it is starting with a
> presumption of what they want for a solution, apparently without
> agreement on the problem to be solved.
> I question whether a simple ascii dump is the right answer. And I
> don't think the WG has done the necessary analysis of requirements
> based on the various problems to be solved, and the environments that
> must be supported.
> dbh
> _______________________________________________
> sip-clf mailing list