Re: [sip-clf] Defining Pros and Cons of ASCII/IPFIX

[Cullen Jennings <[e-mail]>]

inline ..

On Nov 9, 2010, at 12:52 AM, Hadriel Kaplan wrote:

> 
> On Nov 8, 2010, at 11:49 PM, Cullen Jennings wrote:
> 
>> For CVS and Radius, it was obvious why each would happen. CVS was trivial to implement while Radius is far from that. While on the other hand CVS provided no real interoperability and who knows what fields did what - Radius provided something that was well enough defined you could do something with it. As a streaming format, the IPFIX looks better than syslog for what we need to do but there is no way it will deprecate syslog. HTTP is better in every way possible than TFTP for loading firmware on phones yet it takes an unnatural acts to convince people to use HTTP for that - similarly the bulk of people will use syslog for streaming logging.
> 
> Right we all do syslog for exporting stuff (as well as a bunch of other means).  But unfortunately doing syslog is like saying we all do TCP.  The real data is not only proprietary in semantics, but proprietary in syntax too.  It's one big string.  

yah - agree and understand, but my point was we will still be doing syslog no matter what we do here

> 
> This isn't the same issue as HTTP vs. TFTP - in those choices the content being pulled is still by nature a blob. (and for some devices doing TFTP is better because it can be easily hardcoded in ROM/PROM, so I can understand why folks lean that way)
> 
> Look... it's not like I expect all SIP devices to suddenly switch to supporting SIPCLF, no matter what format we do.  Some folks just won't care.  Cisco, for example, may never care - it's Cisco, after all. (and by that I don't mean they're bad - I mean they're a big company and sell a whole "solution" and may not care about what other people do for this)  That's ok.  No one's forcing anyone to do format XYZ.  We're just offering a standardized syntax/semantics in case you want to interop with readers/collectors/whatever without asking them to do your proprietary format/info and waiting for them to change their code.
> 
> 
>> So I know sip servers I have to deal with will be doing syslog, and I know they will be writing unstructured printf style logs to a local disk, the questions is how much more do I have to implement - I can see the advantage of having a interoperable structured format: both the indexed ascii and ipfix can be fixed to meet that need. I'm just not seeing any advantage to doing both. 
> 
> The proposal Peter suggested was to pick Ascii.  Are you ok with that?

I'm fine with pick either but that was not the proposal. The proposal was effectively to pick both. 

> 
> 
>> I'm not worried about the tools that read these logs being able to import either - that's easy because the systems that want the data will do what they need to get it.  
> 
> Then why bother with any standard format to begin with?  

Customers like it - it helps reduce vendor lock in among other reasons. 

> 
> You're not worried

Oh, I'm worried. I got two solutions, both of which have Cisco authors on them, both will work, and no clear direction. That's a receipt for for all the bolts to have left hand thread and all the nuts to have right hand thread. 

> ecause you're Cisco, and frankly the brand name alone is sufficient to get tools to do whatever you do, without even asking.  My world is different.  I have to call monitoring vendors and get the "who's Acme Packet??", then send them docs on the formats we use, and hope they will implement support for it. :(

wow - the grass is greener on the other side. I'm always thinking, if only I was the SBC in the call flow this would be so easy to fix. And I have to call customers and get the "What's an SBC? Oh, you mean an Acme box".

> 
> -hadriel
>