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

"Spencer Dawkins" <spencer@wonderhamster.org> Wed, 03 February 2010 16:45 UTC

Return-Path: <spencer@wonderhamster.org>
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 ED08D28C17E for <sip-clf@core3.amsl.com>; Wed, 3 Feb 2010 08:45:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level:
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
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 rmzTLPfkEnO6 for <sip-clf@core3.amsl.com>; Wed, 3 Feb 2010 08:45:33 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 13BBF28C163 for <sip-clf@ietf.org>; Wed, 3 Feb 2010 08:45:33 -0800 (PST)
Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lhgtt-1O75JD2M9x-00mSct; Wed, 03 Feb 2010 11:46:14 -0500
Message-ID: <DCBC0046E3434E519A2E9EDB4071C7B6@china.huawei.com>
From: "Spencer Dawkins" <spencer@wonderhamster.org>
To: "David Harrington" <ietfdbh@comcast.net>, "'Vijay K. Gurbani'" <vkg@alcatel-lucent.com>, <sip-clf@ietf.org>
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>
Date: Wed, 3 Feb 2010 10:45:57 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX18em2YjAzDAjOP+jEhNLQJq5nerDiTGe+LFKHt UX/dhuCqj+mMnw4fGBQuqrIcOsnG+LOHcYUhxo7p1mPY3woZte z6eBM8ARgC9Ej5DRyyT3X/caBEbqaiVqvvWPR/y1CU=
Subject: Re: [sip-clf] WGLC: SIPCLF ProblemStatement(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: Wed, 03 Feb 2010 16:45:34 -0000

Hi, Dave,

<as-co-chair>

Thanks for clarifying your role - it's helpful.

</as-co-chair>

<as-participant>

On one specific point:
>
> As I read the problem-statement-01, my
> impression is syslog and/or ipfix might fit well to meet certain
> goals, however, it is highly possible that syslog and ipfix are WRONG
> to solve the sipclf problem.
>
> As Technical Advisor - not as technical contributor - I recommend that
> the WG consider syslog and ipfix seriously. My advice as Technical
> Advisor is to do a real analysis about the applicability of existing
> standards like syslog and ipfix to the various sip clf use cases. This
> should not be just a cursory analysis; we spent probably less than one
> minute talking about syslog at the last IETF meeting.

I think the discussion lasted longer than a minute, but I suspect the longer 
time I'm remembering included people walking to the mike :D

So, my understanding of the pushback on SYSLOG in Hiroshima - and I think 
this is what Vijay was saying in his followup - was that SYSLOG entries 
become really important when Bad Things Happen(TM), and people weren't sure 
that producing a lot of SIPCLF SYSLOG entries, which might even be 
message-by-message for a large SIP proxy, that you needed to prune through 
in order to find more "interesting" SYSLOG entries like "file system full", 
was the right thing to do.

Since you are a smart guy about SYSLOG - is this a realistic concern for us 
to have? and, if the answer is "yes", does modern SYSLOG with structured 
data elements provide a way to either (1) quickly separate the SIPCLF SYSLOG 
entries from other "oh, no" SYSLOG entries, or (2) send SIPCLF log entries 
using the same protocol to two different destinations, one potentially 
containing massive amounts of SIPCLF log entries, and the other containing 
"everything else"?

I would really like to use one of the existing management frameworks (still 
speaking as a participant here), IFF it's the right thing to do.

</as-participant>

Thanks,

Spencer