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

"Spencer Dawkins" <spencer@wonderhamster.org> Mon, 18 January 2010 18:44 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 []) by core3.amsl.com (Postfix) with ESMTP id 700403A68B2 for <sip-clf@core3.amsl.com>; Mon, 18 Jan 2010 10:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
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 ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0+37wgGCkuAd for <sip-clf@core3.amsl.com>; Mon, 18 Jan 2010 10:44:50 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net []) by core3.amsl.com (Postfix) with ESMTP id 243363A6901 for <sip-clf@ietf.org>; Mon, 18 Jan 2010 10:44:50 -0800 (PST)
Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net []) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MUp6q-1NKsr23qW4-00YJg6; Mon, 18 Jan 2010 13:44:46 -0500
Message-ID: <7505A2C58D8F4FD88B47D10EA74649CD@china.huawei.com>
From: "Spencer Dawkins" <spencer@wonderhamster.org>
To: "SIP-CLF Mailing List" <sip-clf@ietf.org>
Date: Mon, 18 Jan 2010 12:44:22 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
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: V01U2FsdGVkX19oB7UZBE/s76gnYPdeQD6tzD1nZ0V4fsDu0Sc bhELi2wBE3WTBmzngxtYG2x5o1ieSqdNaD+AlKReONSwvGPqGh 0iUjzqWCe4Dz8RVsSn5126jlU5hZtpEH5glQocVPDQ=
Subject: [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: Mon, 18 Jan 2010 18:44:51 -0000

Just to let people know, Theo and I agree that this draft should be adopted 
as a working group draft. After a quick once-over, I think it's solid enough 
to start WGLC now.

WGLC will end on 2010/02/05, which gives nearly three weeks for people to 
post and discuss comments on the mailing list.

Once WGLC is completed, I will ask Vijay to post a draft-ietf-sipclf 00 
version addressing WGLC comments. I hope to be able to request publication 
for that version of the draft-ietf-sipclf version, so please don't be shy 
about sending comments on the individual draft currently posted (at 


Spencer, as co-chair

> Folks: I have updated the SIPCLF problem statement draft
> pursuant to the discussion we had in Hiroshima.  Sorry for
> the delay in getting this out.
> By far, the biggest discussion point in Hiroshima for the
> problem statement was to provide reasons for what we have
> today (CDR, Wireshark) and why it does not work.  To that extent,
> I have done the following:
> 1) I have added a new Section 5 (Alternative approaches to SIP
>  CLF);
> 2) I have added an explicit section that contains the problem
>  statement (newly added Section 3.)
> 3) I have taken out the old S7 (Relationship to other
>  protocols.)  In Hiroshima, we discarded syslog; no one spoke
>  for or against IDMEF.
>  The only other protocol that is being considered right now
>  is IPFIX.
> Another point of discussion in Hiroshima was that some manner
> of correlation to trace a call end-to-end is needed and should
> be supported by the SIP CLF mechanism.  As far as SIP CLF
> supporting such a mechanism is concerned, it will do so since
> it is designed to extensible (and in fact, in S6, one of the
> use cases --- the third one --- is exactly this one.)  As to
> the problem statement draft or the solutions draft specifying
> such a correlation header, my understanding is that this is
> out of scope for the working group.
> Certainly the solutions exist in form of Hadriel's session
> correlation header that can be used or some ad-hoc means
> between two enterprises to correlate calls [1].  But whether
> or not the problem statement or the solutions draft should spell
> out explicitly how to standardize this correlation primitive
> and perform this correlation, I believe that is currently out
> of scope.
> The URL for the -01 version is:
> http://www.ietf.org/id/draft-gurbani-sipclf-problem-statement-01.txt
> The IETF tools page should be updated shortly so you can perform
> a diff against -00 (until then, use the following tiny URL:
> http://tinyurl.com/00-01-diff).
> I suspect that at least one more revision will be required, but
> I promise to get the revision out as soon as I have some
> sizable review comments in.  Please do review the -01 revision
> and post your comments.
> [1] Adam Roach mentioned in Hiroshima at the mic that even
>  without an explicit correlation header, one could correlate
>  calls simply by noting that the request left my network with a
>  Call-ID of X and shows up at your network with a Call-ID of Y,
>  etc.
> Thank you,
> - 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/
> _______________________________________________
> sip-clf mailing list
> sip-clf@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-clf