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

["David Harrington" <[e-mail]>]

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
[e-mail]
[e-mail]
[e-mail]


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 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 
>
http://www.ietf.org/id/draft-gurbani-sipclf-problem-statement-01.txt).
> 
> 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:
> >
http://www.ietf.org/id/draft-gurbani-sipclf-problem-statement-01.txt
> >
> > The IETF tools page should be updated shortly so you can perform
> > a diff against -00 (until then, use the following tiny URL:
> > http://tinyurl.com/00-01-diff).
> >
> > 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@{alcatel-lucent.com,bell-labs.com,acm.org}
> > Web:   http://ect.bell-labs.com/who/vkg/
> > _______________________________________________
> > sip-clf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sip-clf
> > 
> 
> _______________________________________________
> sip-clf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-clf
>