Re: [sip-clf] draft CLF charter

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Tue, 21 July 2009 22:25 UTC

Return-Path: <vkg@alcatel-lucent.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 1486F3A67F9 for <sip-clf@core3.amsl.com>; Tue, 21 Jul 2009 15:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.469
X-Spam-Level:
X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0qbtKLhEOROI for <sip-clf@core3.amsl.com>; Tue, 21 Jul 2009 15:25:29 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E1A233A6AC0 for <sip-clf@ietf.org>; Tue, 21 Jul 2009 15:25:28 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n6LMPNI7016703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 17:25:23 -0500 (CDT)
Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n6LMPN7a026015; Tue, 21 Jul 2009 17:25:23 -0500 (CDT)
Message-ID: <4A664053.7070603@alcatel-lucent.com>
Date: Tue, 21 Jul 2009 17:25:23 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
References: <3B33A97D-7E19-4A08-A431-A085D53A2A6E@nostrum.com> <D5E606B8-0811-4D40-AA76-ED989B00FD02@nostrum.com> <EDC652A26FB23C4EB6384A4584434A0401892AF4@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0401892AF4@307622ANEX5.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: sip-clf@ietf.org
Subject: Re: [sip-clf] draft CLF charter
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, 21 Jul 2009 22:25:30 -0000

Romascanu, Dan (Dan) wrote:
> A few comments after the first reading of the charter. 

Dan: Thanks for your feedback; more inline.

> - Is it Common Log File as it appears at the first instance, or Common
> Log Format? 

CLF expands to Common Log File, though colloquially you will
see references to "the CLF format", which simply means the
specific fields and their representation.

> - What does 'efficient processing' mean? More clarity and details here
> would be welcome (is it at client, at server, both? 

Efficiency is envisioned here to encompass both the server and the
client.  From the server's perspective, the generation of the
CLF should not cause an unnecessarily burden so as to slow the
normal processing done by the server.

 From the client perspective, the processing of the file should
not take undue time.  Some clients may consume data produced
in CLF format in real time while others may do so in "batch"
mode (i.e., find all the SIP messages corresponding to a
certain dialog.)  To do such batch mode processing, it is
advantageous if the CLF data is so structured as to aid in
skipping records that are not part of the search criteria.

> Is it efficiency on storage, on transmission? etc.)

More than storage costs or transmission overhead, efficiency
is measured in processing time at the clients and servers.

> - Would it be useful to include (maybe as part of the problem statement
> work, maybe as a separate item) a look at what is already available as
> standards for logging events (e.g. syslog is discussing rechartering at
> the same IETF meeting - can syslog format be used? pcap? Other? Are
> there any initial proposals?)

The members of the sip-clf list have experimented with ASCII-,
binary- as well as a hybrid-based approach to producing the CLF.
While pcap is good for capturing network traffic, requiring a SIP
entity to expressly produce CLF in pcap format will be burdening
it to spend CPU cycles in converting the SIP message from its
internal representation to the pcap format -- this may not
be sustainable in a high transaction volume SIP proxy, for
instance.  With respect to syslog, SIP CLF is more than an
event notification message -- it is essentially continuous
spooling of the messages that a SIP entity is processing.
It could well be that the SIP entity, if it detects something amiss
in a message, emits a syslog message; however, SIP CLF itself
was not viewed as an event notification mechanism.  Hence the
charter leaves out of scope mechanisms of exchanging, transporting,
and storing CLF format records.

> - if the WG ends by doing both a bit-field oriented and a text-oriented
> format will these end being separate deliverables? 

Possibly; or they could be different sections in the same
document.  The CLF fields will be the same, just the representation
of them will differ.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/