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

Hadriel Kaplan <HKaplan@acmepacket.com> Sat, 27 March 2010 04:09 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 CCCBC3A6C87 for <sip-clf@core3.amsl.com>; Fri, 26 Mar 2010 21:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.793
X-Spam-Level:
X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 2l3DuPc2CbBp for <sip-clf@core3.amsl.com>; Fri, 26 Mar 2010 21:09:38 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E73373A6B3C for <sip-clf@ietf.org>; Fri, 26 Mar 2010 21:09:37 -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.375.2; Sat, 27 Mar 2010 00:10:01 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 27 Mar 2010 00:10:01 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Cullen Jennings <fluffy@cisco.com>, SIP-CLF Mailing List <sip-clf@ietf.org>
Date: Sat, 27 Mar 2010 00:10:00 -0400
Thread-Topic: [sip-clf] WGLC: SIPCLF Problem Statement (draft-gurbani-sipclf-problem-statement-01)
Thread-Index: AcqlUXV9GOxuyMO5RCy9llA3w8UCLwoD7GHQ
Message-ID: <430FC6BDED356B4C8498F634416644A91A79E926A0@mail>
References: <7505A2C58D8F4FD88B47D10EA74649CD@china.huawei.com> <C1B972DA-0118-4E3F-8C5F-970BE4238577@cisco.com>
In-Reply-To: <C1B972DA-0118-4E3F-8C5F-970BE4238577@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
Subject: Re: [sip-clf] WGLC: SIPCLF Problem Statement (draft-gurbani-sipclf-problem-statement-01)
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: Sat, 27 Mar 2010 04:09:38 -0000

Sorry for dredging up an old email, but I was scanning old ones and came upon this... [I removed lots of text from the original]

> -----Original Message-----
> From: sip-clf-bounces@ietf.org [mailto:sip-clf-bounces@ietf.org] On Behalf
> Of Cullen Jennings
> Sent: Wednesday, February 03, 2010 11:21 PM
> 
> I don't think this information model need to be extensible. In fact the
> one thing I am going to continue to strongly argue is that it should not
> be extensible. Note this does not mean we can not have new sip headers or
> new body types, we can, they just go in the list of sip headers or body
> type.

I don't understand that statement.  You don't want it to be extensible, but you're ok with adding more headers and bodies? 

> I'm against the needless complexity or arbitrary extensibility and would
> want to see a good argument made for adding things.

1) We won't get the list right.  We'll try, but odds are some admin will want header Foo which we thought she wouldn't want.
2) Some products should/need to record things others don't.  SBC's for example need to record some stuff that make no sense for a proxy, and likewise a forking proxy might need to record stuff a simple UAC wouldn't. We won't want to clutter the list of fields up to accommodate the different product types.
3) We haven't really talked about events or processing results, but I can imagine someday we might want to record more than just headers as part of the message record.  For example, if we ever make a deployable version of rfc4474, then a verifier generating a clf entry for a received Invite might want to add "verified" vs. not, or some such. ;)

-hadriel