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

Hadriel Kaplan <HKaplan@acmepacket.com> Tue, 09 November 2010 07:52 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: sip-clf@core3.amsl.com
Delivered-To: sip-clf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2853A6889 for <sip-clf@core3.amsl.com>; Mon, 8 Nov 2010 23:52:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.171
X-Spam-Level:
X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4LIdD4smrNB for <sip-clf@core3.amsl.com>; Mon, 8 Nov 2010 23:52:09 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 283C43A6807 for <sip-clf@ietf.org>; Mon, 8 Nov 2010 23:52:09 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 9 Nov 2010 02:52:30 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 9 Nov 2010 02:52:30 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Cullen Jennings <fluffy@cisco.com>
Date: Tue, 09 Nov 2010 02:52:27 -0500
Thread-Topic: [sip-clf] Defining Pros and Cons of ASCII/IPFIX
Thread-Index: Act/4w8ok0LesYdOTjiTRIB7x+2lXQ==
Message-ID: <0AD10257-D7F7-42FB-8CC4-E4A4FB17F63F@acmepacket.com>
References: <AANLkTin3+_+-ARa29=o4V8-Pp-TS0Xc5S04CYhy0sT=r@mail.gmail.com> <D2591488-77F2-423D-B2AE-187E627D4489@acmepacket.com> <752EDF9B02C09847950620E262C45431845234@PALLENE.office.hd> <AANLkTikQ-gV-tja_LnQx7X-4uScpnAi=oNVAj3xQe_2J@mail.gmail.com> <DF0E148F-CA21-4373-92FF-A777A27A76EE@cisco.com> <9172F3B8-339B-4F2A-B7DF-A620C408E934@acmepacket.com> <119C6B38-825F-4074-9D3C-8A91A8E3454D@cisco.com>
In-Reply-To: <119C6B38-825F-4074-9D3C-8A91A8E3454D@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: List SIP-CLF Mailing <sip-clf@ietf.org>
Subject: Re: [sip-clf] Defining Pros and Cons of ASCII/IPFIX
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-clf>
List-Post: <mailto:sip-clf@ietf.org>
List-Help: <mailto:sip-clf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2010 07:52:10 -0000

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.  

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 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?  

You're not worried because 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. :(

-hadriel