[sip-clf] One possible Information model for SIP CLF

Cullen Jennings <fluffy@cisco.com> Tue, 12 January 2010 22:22 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: sip-clf@core3.amsl.com
Delivered-To: sip-clf@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id F0B0A3A686A for <sip-clf@core3.amsl.com>; Tue, 12 Jan 2010 14:22:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id R4X4chkAyTZX for <sip-clf@core3.amsl.com>; Tue, 12 Jan 2010 14:22:03 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com []) by core3.amsl.com (Postfix) with ESMTP id 91FE03A68AF for <sip-clf@ietf.org>; Tue, 12 Jan 2010 14:22:02 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuoFACOETEurR7Hu/2dsb2JhbAAswU6Ud4QwBA
X-IronPort-AV: E=Sophos;i="4.49,264,1262563200"; d="scan'208";a="232336576"
Received: from sj-core-5.cisco.com ([]) by sj-iport-2.cisco.com with ESMTP; 12 Jan 2010 22:22:00 +0000
Received: from [] (rcdn-fluffy-8711.cisco.com []) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0CMLxKm010737 for <sip-clf@ietf.org>; Tue, 12 Jan 2010 22:21:59 GMT
From: Cullen Jennings <fluffy@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Impp: xmpp:cullenfluffyjennings@jabber.org
Date: Tue, 12 Jan 2010 15:21:58 -0700
Message-Id: <1AE77C97-EA66-406E-8EC0-4FFA63DA5F74@cisco.com>
To: SIP-CLF Mailing List <sip-clf@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1077)
X-Mailer: Apple Mail (2.1077)
Subject: [sip-clf] One possible Information model for SIP CLF
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, 12 Jan 2010 22:22:08 -0000

David raises and excellent point that we are unclear about our information model and that makes it harder for us to get work done quickly. I encourage people to read RFC 3444.

I think there is a very clear and well define information model for what we need in SIP CLF. 

For each SIP message that is logged, there is a Status-Line or Request-Line, an ordered list of pairs of where each pair has a header-name and a header-value, and finally there may be zero or one message-bodies. We also have where the message was coming from and going to from the transport layer as well as a timestamp. These are defined in RFC 3261. Formal language descriptions of one possible data model for them are provided in section 25.1. If people feel the strong need to have this information model in say UML, I suspect I could do the UML for this in ASCII. 

This is it. 

As usual, I don't claim to have a good handle on where this slides from being an IM to DM but it barely seems relevant for getting the job done. Now of course we could slide the IM differently, such as pulling out the SIP to and from tags as elements in the information model. I don't really care how we slice it apart but the key thing to me that doing so is really easy and largely already defined. I think that on a single 1 hour phone call we could probably come to consensus on what the information model needed to be. 

I would strongly argue that what we don't need is an extensible information model or a formal language schema for describing and extensible data model. SIP 2.0 is not going to be extended in a way that adds elements outside the above items. 

Keep it simple. You are trying to convince someone that currently has an fprintf to replace the it with this so make it easy.