Re: [Sipping] Alternate CLF syntax proposal

Hadriel Kaplan <HKaplan@acmepacket.com> Tue, 31 March 2009 16:41 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B142F3A6D9D for <sipping@core3.amsl.com>; Tue, 31 Mar 2009 09:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level:
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 JquQhC7WP9oZ for <sipping@core3.amsl.com>; Tue, 31 Mar 2009 09:41:54 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 764C13A69CD for <sipping@ietf.org>; Tue, 31 Mar 2009 09:41:54 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 31 Mar 2009 12:42:51 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 31 Mar 2009 12:42:51 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Theo Zourzouvillys <theo@crazygreek.co.uk>, Jiri Kuthan <jiri@iptel.org>
Date: Tue, 31 Mar 2009 12:42:51 -0400
Thread-Topic: [Sipping] Alternate CLF syntax proposal
Thread-Index: Acmw4ndkYg2mw20JRamZps8m0xRlyAAJ78rw
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC31503229BAE@mail>
References: <49CAE21C.5060309@nostrum.com> <c164605b0903260836p45a8bd8eg9ad50f670ef82302@mail.gmail.com> <167dfb9b0903290326t519e6df8naacdb396a259f8f2@mail.gmail.com> <49CFCD7B.5020304@iptel.org> <167dfb9b0903291950s17559a41s6a8ab01cee1e3650@mail.gmail.com>
In-Reply-To: <167dfb9b0903291950s17559a41s6a8ab01cee1e3650@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_002_E6C2E8958BA59A4FB960963D475F7AC31503229BAEmail_"
MIME-Version: 1.0
Cc: Jason Fischl <jason.fischl@gmail.com>, sipping WG <sipping@ietf.org>, "draft-gurbani-sipping-clf@tools.ietf.org" <draft-gurbani-sipping-clf@tools.ietf.org>, Adam Roach <adam@nostrum.com>
Subject: Re: [Sipping] Alternate CLF syntax proposal
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 16:41:55 -0000

That depends on what you think a "Common Log Format" would be useful for.  The premise was that it's for troubleshooting and analysis systems.  AFAICT, nothing short of the entire SIP message sequence, including contents, and even IP/UDP or TCP headers, would be sufficient for that in practice.

But anyway, attached is an example CLF file using only the currently defined fields from draft-gurbani-sipping-clf-01, I think, encoded in a different format from the draft.  It just happens to be that there are already tools which can even read this file and allow the user to view its contents in a meaningful way.  For example, you can open this attachment in wireshark.

-hadriel

> -----Original Message-----
> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf
> Of Theo Zourzouvillys
> Sent: Sunday, March 29, 2009 10:51 PM
> To: Jiri Kuthan
> Cc: Jason Fischl; sipping WG; draft-gurbani-sipping-clf@tools.ietf.org;
> Adam Roach
> Subject: Re: [Sipping] Alternate CLF syntax proposal
> 
> On Sun, Mar 29, 2009 at 8:35 PM, Jiri Kuthan <jiri@iptel.org> wrote:
> 
> > Why aren't we happy then just with PCAP -- that's a de-facto standard.
> 
> what does the pcap format give us? see:
> 
>   http://wiki.wireshark.org/Development/LibpcapFileFormat
> 
> ... it doesn't really solve any of the problems except provide a
> struct header and record header, much of which we don't even need (and
> missing stuff we do need).
> 
> We'd just be shoving whatever formats we defined into a record in
> them.  None of the pcap tools would work on records except raw
> packets, which most of the time i don't want to be collecting or
> sending across the network to a collector - a port mirror already does
> that pretty well :-)
> 
>  ~ Theo
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP