[sip-clf] Updated SIPCLF problem statement (draft-gurbani-sipclf-problem-statement-01)

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Fri, 15 January 2010 22:08 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 E4B923A6820 for <sip-clf@core3.amsl.com>; Fri, 15 Jan 2010 14:08:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 oHC4bgmU9H7s for <sip-clf@core3.amsl.com>; Fri, 15 Jan 2010 14:08:42 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id B02CD3A67E5 for <sip-clf@ietf.org>; Fri, 15 Jan 2010 14:08:42 -0800 (PST)
Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o0FM8cMN023417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <sip-clf@ietf.org>; Fri, 15 Jan 2010 16:08:38 -0600 (CST)
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 o0FM8cUG029890 for <sip-clf@ietf.org>; Fri, 15 Jan 2010 16:08:38 -0600 (CST)
Message-ID: <4B50E766.2090201@alcatel-lucent.com>
Date: Fri, 15 Jan 2010 16:08:38 -0600
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: "sip-clf@ietf.org" <sip-clf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: [sip-clf] Updated 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: Fri, 15 Jan 2010 22:08:44 -0000

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/