Re: [sip-clf] WGLC: SIPCLF Problem Statement(draft-gurbani-sipclf-problem-statement-01)

"Spencer Dawkins" <> Tue, 02 February 2010 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3639A3A6803 for <>; Tue, 2 Feb 2010 08:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WFRPEj2l6gpI for <>; Tue, 2 Feb 2010 08:54:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 74E733A67B1 for <>; Tue, 2 Feb 2010 08:54:08 -0800 (PST)
Received: from S73602b ( []) by (node=mrus3) with ESMTP (Nemesis) id 0Lreg1-1NkQaZ1EmT-013FOC; Tue, 02 Feb 2010 11:54:41 -0500
Message-ID: <>
From: "Spencer Dawkins" <>
To: "David Harrington" <>, "'SIP-CLF Mailing List'" <>
References: <> <00ce01caa41e$fe5a5ef0$>
Date: Tue, 2 Feb 2010 10:54:25 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX18mZxyBlHY5I1hn1sKkgVJ/6vA7tBsYMz74Fgb BsUn24cYFv2IVTgIy+hxP7+ZRGl1GqTDgAFNZ01tIJEJ+RzmXe RUAwIgcMJstzZdYKOami3pnWX4R3RG7YevBrd4psOk=
Subject: Re: [sip-clf] WGLC: SIPCLF Problem Statement(draft-gurbani-sipclf-problem-statement-01)
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: Tue, 02 Feb 2010 16:54:10 -0000

Hi, Dave,

Thanks for the comments.

Just a point of clarification - my purpose in starting WGLC was to encourage 
people to see whether this draft is ready for publication, because we 
haven't gotten a lot of post-Hiroshima feedback.

In my opinion, we either work on documents or forward them for publication 
("hatching" documents by sitting on them for extended periods of time isn't 
actually part of the workflow).

I'm reading most of your comments as things we should consider before 
requesting publication of this document. I can agree with that.


Spencer, as co-chair, who's looking for other people to express opinions on 
the draft...

> Hi,
> I think the problem statement should be adopted as a WG item.
> I agree with Cullen that it is a good starting place for a WG problem
> statement doc.
> I definitely do NOT agree this is ready for WGLC.
> There are multiple use cases that lead to different requirements. Some
> people want to correlate flows of conversation; others only want to
> pay attention to the data dumped by one server. I think there are lots
> of conflicting requirements.
> This problem statement document lacks any analysis of existing
> protocols
> that might address the different problems people seek to address.
> Everything is just munged together into one problem statement, as if
> everybody was in agreement about a single problem to be solved, and
> the single solution that should solve all those problems.
> Different use cases can already be dealt with, to varying degrees,
> using existing standards, such as syslog and ipfix.
> I am very concerned about developing a logging standard for one single
> protocol. Following this approach could easily lead to standards for a
> MPLS CLF and a PCE CLF and a XYZ-protocol CLF. IETF is a standards
> organization and we should be striving to reduce the number of
> protocols and data modeling langauges that need to be learned by
> operators
> in order to run their networks, not developing a totally new standard
> for every use case.
> I disagree with the following analysis in the document:
>   It can be argued
>   that a good part of the success of Apache has been its CLF because
> it
>   allowed third parties to produce tools that analyzed the data and
>   generated traffic reports and trends.  The Apache CLF has been so
>   successful that not only did it become the de-facto standard in
>   producing logging data for web servers, but also many commercial
> web
>   servers can be configured to produce logs in this format.
> I think Apache was successful because it was widely available,
> strongly supported in the open source community, and free. The Apache
> CLF became the defacto standard for web server logging because Apache
> became the defacto standard for web servers. If Apache had a high
> price tag, was not widely available, and was not supported by the open
> source community, do you still think the Apache CLF would have become
> the defacto standard for web server logging?
> I think claiming Apache was successful because it supported a common
> log format would be akin to claiming that UNIX was successful because
> it supported a common logging format (syslog).
> I think the document is claiming the wide deployment of the Apache CLF
> as a reason to model a solution on that approach. If wide deployemnt
> is the justification for choosing a solution, then we really should
> also be considering other "common logging formats" that are already
> used widely, such as syslog.
> This WG needs to really understand the **multiple** problems that
> people are trying to solve, and the different requirements these
> different use cases place on the solution space. The abstract talks
> about problems such as mining the log files to produce reports and
> trends, training anomaly detection systems and feeding events into a
> security event management system. But nowhere in this document is
> there an analysis of the requirements that must be met to address
> producing reports and trends, training anomaly detection systems, or
> feeding events into a security event management system, such as
> aggregation and correlation.
> I think the section on "Alternative approaches to SIP CLF" is woefully
> inadquate. Existing IETF standards, such as syslog, ipfix, and SNMP
> are already being used to address some of the problems WG contributors
> have stated they want to address. The data from these existing
> standards is already being widely used to produce reports and trends,
> train anomaly detection systems, and feed events into a security event
> management system. These existing standards already support a wide
> array of technologies, and have been developed to be extensible by
> defining new data models for new targeted technologies. These existing
> standards are already often used in combination to correlate events
> reported by different mechanisms to help pinpoint the cause of
> reported problmes, to better analyze trends, to reduce false positives
> in intrusion detection systems, and to recognize potential security
> breaches. Yet this document does not even **mention** these existing
> IETF standards as possible alternative approaches.
> I support adoption of the document as a working group item, as a
> starting place for a WG problem statement doc, but I do not think the
> WG's work is done yet. This document is NOT ready for WGLC.
> David Harrington
>> -----Original Message-----
>> From:
>> [] On Behalf Of Spencer Dawkins
>> Sent: Monday, January 18, 2010 1:44 PM
>> To: SIP-CLF Mailing List
>> Subject: [sip-clf] WGLC: SIPCLF Problem
>> Statement(draft-gurbani-sipclf-problem-statement-01)
>> Just to let people know, Theo and I agree that this draft
>> should be adopted
>> as a working group draft. After a quick once-over, I think
>> it's solid enough
>> to start WGLC now.
>> WGLC will end on 2010/02/05, which gives nearly three weeks
>> for people to
>> post and discuss comments on the mailing list.
>> Once WGLC is completed, I will ask Vijay to post a
>> draft-ietf-sipclf 00
>> version addressing WGLC comments. I hope to be able to
>> request publication
>> for that version of the draft-ietf-sipclf version, so please
>> don't be shy
>> about sending comments on the individual draft currently posted (at
>> Thanks,
>> Spencer, as co-chair
>> > Folks: I have updated the SIPCLF problem statement draft
>> > pursuant to the discussion we had in Hiroshima.  Sorry for
>> > the delay in getting this out.
>> >
>> > By far, the biggest discussion point in Hiroshima for the
>> > problem statement was to provide reasons for what we have
>> > today (CDR, Wireshark) and why it does not work.  To that extent,
>> > I have done the following:
>> >
>> > 1) I have added a new Section 5 (Alternative approaches to SIP
>> >  CLF);
>> > 2) I have added an explicit section that contains the problem
>> >  statement (newly added Section 3.)
>> > 3) I have taken out the old S7 (Relationship to other
>> >  protocols.)  In Hiroshima, we discarded syslog; no one spoke
>> >  for or against IDMEF.
>> >
>> >  The only other protocol that is being considered right now
>> >  is IPFIX.
>> >
>> > Another point of discussion in Hiroshima was that some manner
>> > of correlation to trace a call end-to-end is needed and should
>> > be supported by the SIP CLF mechanism.  As far as SIP CLF
>> > supporting such a mechanism is concerned, it will do so since
>> > it is designed to extensible (and in fact, in S6, one of the
>> > use cases --- the third one --- is exactly this one.)  As to
>> > the problem statement draft or the solutions draft specifying
>> > such a correlation header, my understanding is that this is
>> > out of scope for the working group.
>> >
>> > Certainly the solutions exist in form of Hadriel's session
>> > correlation header that can be used or some ad-hoc means
>> > between two enterprises to correlate calls [1].  But whether
>> > or not the problem statement or the solutions draft should spell
>> > out explicitly how to standardize this correlation primitive
>> > and perform this correlation, I believe that is currently out
>> > of scope.
>> >
>> > The URL for the -01 version is:
>> >
>> >
>> > The IETF tools page should be updated shortly so you can perform
>> > a diff against -00 (until then, use the following tiny URL:
>> >
>> >
>> > I suspect that at least one more revision will be required, but
>> > I promise to get the revision out as soon as I have some
>> > sizable review comments in.  Please do review the -01 revision
>> > and post your comments.
>> >
>> > [1] Adam Roach mentioned in Hiroshima at the mic that even
>> >  without an explicit correlation header, one could correlate
>> >  calls simply by noting that the request left my network with a
>> >  Call-ID of X and shows up at your network with a Call-ID of Y,
>> >  etc.
>> >
>> > Thank you,
>> >
>> > - vijay
>> > -- 
>> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>> > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
>> > Email: vkg@{,,}
>> > Web:
>> > _______________________________________________
>> > sip-clf mailing list
>> >
>> >
>> >
>> _______________________________________________
>> sip-clf mailing list