Re: [sip-clf] A primer on syslog.

"Rainer Gerhards" <rgerhards@hq.adiscon.com> Thu, 04 February 2010 11:50 UTC

Return-Path: <rgerhards@hq.adiscon.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 87CF028C0FE for <sip-clf@core3.amsl.com>; Thu, 4 Feb 2010 03:50:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 IUIO4HlvzwaV for <sip-clf@core3.amsl.com>; Thu, 4 Feb 2010 03:50:52 -0800 (PST)
Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 716BF28C181 for <sip-clf@ietf.org>; Thu, 4 Feb 2010 03:50:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 5EF7A241C005; Thu, 4 Feb 2010 12:37:46 +0100 (CET)
Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1JI7TZuzfZ7; Thu, 4 Feb 2010 12:37:46 +0100 (CET)
Received: from GRFEXC.intern.adiscon.com (pd95c774a.dip0.t-ipconnect.de [217.92.119.74]) by mailin.adiscon.com (Postfix) with ESMTP id 2855D241C004; Thu, 4 Feb 2010 12:37:46 +0100 (CET)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 4 Feb 2010 12:51:36 +0100
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103809@GRFEXC.intern.adiscon.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sip-clf] A primer on syslog.
Thread-Index: AcqlMKjUR8HC0H1jRmer31mp3poB9QAXxsVw
References: <7505A2C58D8F4FD88B47D10EA74649CD@china.huawei.com><00ce01caa41e$fe5a5ef0$0600a8c0@china.huawei.com><4B68920B.5090908@alcatel-lucent.com><81F3AF977ADD49E7A883F138ECCC71D0@china.huawei.com><01eb01caa4ec$0fbe0930$0600a8c0@china.huawei.com><DCBC0046E3434E519A2E9EDB4071C7B6@china.huawei.com><023501caa50a$16943c70$0600a8c0@china.huawei.com> <A90FB013-09CB-43B3-A7AC-7F7A27F9EF6B@cisco.com>
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Cullen Jennings" <fluffy@cisco.com>
Cc: SIP-CLF Mailing List <sip-clf@ietf.org>
Subject: Re: [sip-clf] A primer on syslog.
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: Thu, 04 Feb 2010 11:50:54 -0000

> -----Original Message-----
> From: sip-clf-bounces@ietf.org [mailto:sip-clf-bounces@ietf.org] On
> Behalf Of Cullen Jennings
> Sent: Thursday, February 04, 2010 1:26 AM
> To: David Harrington
> Cc: SIP-CLF Mailing List
> Subject: Re: [sip-clf] A primer on syslog.
> 
> 
> On Feb 3, 2010, at 12:50 PM, David Harrington wrote:
> 
> > There are 23
> > different facilities defined for use in the <priority field>, ranging
> > from "kernel" to system daemons to mail to security to local
> > applications. A SIP application would use one of the "local"
> > facilities to log messages.
> 
> 
> 
> Just out of curiosity, would it ever make sense for the IETF to
> designate an facilities value for SIP?

Actually, the syslog WG was (very unfortunately) forced to stick with this
too-small set of facilities in order to keep compatible with existing
implementations. Other than facility 0, which seems to be universally used by
the OS kernel, there is no exact semantic for the facility codes. Think about
how many important subsystems we have and how small this facility set is...
The rest of the header provides ample ways to express this is a sip packet,
but an operator will still assign a facility and filter on it simply because
that is the fastest way to do it. This is another thing where some operator
configuration is required, at least in a reasonable busy envrionment.

Rainer