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

[Benoit Claise <[e-mail]>]

Dear all,
> 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.
>    
Exactly.
My main concern is that this WG is thinking about yet another data 
modelling language, which implies correlation tools and proxy in the future
because we can see it coming, one day this WG will require flow related 
information elements such as the ones defined in 
http://www.iana.org/assignments/ipfix/ipfix.xhtml. And one day, SIP 
related information elements will be required in IPFIX. And that day, we 
will left with two different data models.


My concern is that, the way the charter is written, any common log 
format is certainly fine.
But then what is the next step? Information transfer, correlation with 
other data model such as flow related information, etc...

Note: I just give my feedback to Saverio in helping to write a draft 
called " Advantages of using an IPFIX File Format for SIPCLF". Hopefully 
this draft will be out soon. It will contain more detailed information.
Note2: It's not because I've been involved in IPFIX that I try to push 
IPFIX at all costs... Numerous performance management partners have been 
stressing the cost/pain of correlation tools and proxies.

So my message is: let's avoid to have yet another data model. And if we 
think about the problems we want to solve from a little bit long term 
point of view, I believe the conclusion will be obvious.

Regards, Benoit.

> 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
>>
>>      
> _______________________________________________
> sip-clf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-clf
>