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

["Spencer Dawkins" <[e-mail]>]

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 
http://www.ietf.org/id/draft-gurbani-sipclf-problem-statement-01.txt).

Thanks,

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-clf
>