Re: [sip-clf] draft CLF charter

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Wed, 22 July 2009 13:56 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 19DD728C0F1 for <sip-clf@core3.amsl.com>; Wed, 22 Jul 2009 06:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.034
X-Spam-Level:
X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, 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 qtupcUnMM5WR for <sip-clf@core3.amsl.com>; Wed, 22 Jul 2009 06:56:24 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id E35F628C0EA for <sip-clf@ietf.org>; Wed, 22 Jul 2009 06:56:23 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n6MDaBKN023819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 08:36:11 -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 n6MDaAjf001423; Wed, 22 Jul 2009 08:36:10 -0500 (CDT)
Message-ID: <4A6715CA.4000709@lucent.com>
Date: Wed, 22 Jul 2009 08:36:10 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
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> <4A664053.7070603@alcatel-lucent.com> <EDC652A26FB23C4EB6384A4584434A0401892EB9@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0401892EB9@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.35
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: Wed, 22 Jul 2009 13:56:25 -0000

Romascanu, Dan (Dan) wrote:
> Thanks for the answers. Most clarifications are fine with me, a
> couple of observations in line.

Dan: Thank you.  I am suggesting some changes to the charter based
on your comments.  Could the sip-clf list participants and
the AD please review and comment.

dromasca> Is it efficiency on storage, on transmission? etc.)
vkg> More than storage costs or transmission overhead, efficiency
vkg> is measured in processing time at the clients and servers.
dromasca> Some clarification in the text of the charter would be welcome.

OLD:
The format will anticipate being used both for off-line
analysis and on-line real-time processing applications. The
working group will consider the need for efficient processing
in its design of this format.

NEW:
The format will anticipate being used both for off-line
analysis and on-line real-time processing applications. The
working group will consider the need for efficient processing
in its design of this format, where efficiency is measured
in processing time of the CLF at the clients and servers (i.e.,
the generation of the CLF should not cause an unnecessarily
burden so as to slow the normal processing done by a server,
and the processing of the file should not take undue time by
a client.)

dromasca> - if the WG ends by doing both a bit-field oriented and a
dromasca> text-oriented format will these end being separate deliverables?
vkg> Possibly; or they could be different sections in the same
vkg> document.  The CLF fields will be the same, just the
vkg> representation of them will differ.
dromasca> So, basically we are talking about fields definition (one)
dromasca> and mapping of the fields to different formats (one
dromasca> or more). Again, clarifying this in text may help.

OLD:
The working group is not pre-constrained to producing either a
bit-field oriented or text-oriented format, and may choose to
provide both.  If the group chooses to specify both, it must be
possible to mechanically translate between the formats without
loss of information.

NEW:
The working group is not pre-constrained to producing either a
bit-field oriented or text-oriented format, and may choose to
provide both.  The nature of the CLF information contained in
a bit-field or text-oriented format will be the same, it is
the representation that will differ.  If the group chooses to
specify both, it must be possible to mechanically translate
between the formats without loss of information.

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/