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

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

Hi, Dave,

<as-co-chair>

Thanks for clarifying your role - it's helpful.

</as-co-chair>

<as-participant>

On one specific point:
>
> As I read the problem-statement-01, my
> impression is syslog and/or ipfix might fit well to meet certain
> goals, however, it is highly possible that syslog and ipfix are WRONG
> to solve the sipclf problem.
>
> As Technical Advisor - not as technical contributor - I recommend that
> the WG consider syslog and ipfix seriously. My advice as Technical
> Advisor is to do a real analysis about the applicability of existing
> standards like syslog and ipfix to the various sip clf use cases. This
> should not be just a cursory analysis; we spent probably less than one
> minute talking about syslog at the last IETF meeting.

I think the discussion lasted longer than a minute, but I suspect the longer 
time I'm remembering included people walking to the mike :D

So, my understanding of the pushback on SYSLOG in Hiroshima - and I think 
this is what Vijay was saying in his followup - was that SYSLOG entries 
become really important when Bad Things Happen(TM), and people weren't sure 
that producing a lot of SIPCLF SYSLOG entries, which might even be 
message-by-message for a large SIP proxy, that you needed to prune through 
in order to find more "interesting" SYSLOG entries like "file system full", 
was the right thing to do.

Since you are a smart guy about SYSLOG - is this a realistic concern for us 
to have? and, if the answer is "yes", does modern SYSLOG with structured 
data elements provide a way to either (1) quickly separate the SIPCLF SYSLOG 
entries from other "oh, no" SYSLOG entries, or (2) send SIPCLF log entries 
using the same protocol to two different destinations, one potentially 
containing massive amounts of SIPCLF log entries, and the other containing 
"everything else"?

I would really like to use one of the existing management frameworks (still 
speaking as a participant here), IFF it's the right thing to do.

</as-participant>

Thanks,

Spencer