[re-send to fix email subject line]
Howdy,
Below are the rough minutes of the Sipping CLF Ad-Hoc meeting.
I'm sure I missed some people's comments (I don't touch-type) - if you find I missed yours please email me and I'll update this.
I also tried to record what I felt was consensus on specific issues, but this is clearly just subjective commentary and this was only an ad-hoc and no hmmm's were taken, etc.
-hadriel


Begin ------------------------------
Ad-hoc Common-Log-File format meeting
Thursday, March 26, 2009

Attendees: many, many (room is packed)


Eric Burger: [gave intro (go read ppt slides)]: Goal is to have usable log file format for tools, but not for billing nor a replacement for syslog or CDR's

Francois: if I'm already doing CDR, why bother doing this?

Umberto: Tools which do stateful parsing of SIP protocol would like this, for example anomaly/problem/IDS type things 

Hadriel: but this log file format isn't nearly enough info/detail for that

Vijay: but we can add them or argue about what we need


Adam Roach: ascii fixed format or space delimited is not efficient and tough to extend

Daryl: how will we get enough detail, compared to CDR's/wireshark?

Vijay: we think the 11 currently defined CLF headers are enough, but we want to learn if others agree

Jiri: is this per message, or per transaction - what about retransmissions?

Daryl: we'll need more detail, for example retransmissions may be important to log for troubleshooting

Vijay: We weren't thinking this will record retransmissions

Daryl: how do we correlate routed requests if b2bua's change call-id?

Dean: stateless proxies will create multiple entries for retransmissions, no matter what

Jason Fishl: no biggie - it records multiple times and we don't need to care

[I think consensus reached: don't need to worry about stateless proxies doing/needing something different]

Daryl: performance is a big deal, it will be some off-box process in some cases because impact on run-time systems won't cut it

Adam R: really we need a TLV-type format, something binary/fast to write and fast to read, so you can seek and skip large chunks fast, and have optionality

[Someone else]: and something which can record enough for troubleshooting and the like

Hadriel: the only thing useful for that would be pcap format

Francois: update the draft for format issues, because it's not decided yet and I'm not sure the format is right

Vijay: are the current fields necessary and/or sufficient?

Hadriel: insufficient fields in current CLF

Adam: we need optional extensibility, because we'll never figure out the right fields right now

Dale: To and From URI may not be useful

Derek: need sub-second accuracy, not just seconds

[people agree with that - I think consensus reached on that]


Vijay: some security folks want privacy of IP/identity

Daryl/Martin: nope, do post-processing to anonymize if you want, but the logs need to show it all

Vijay: ok, we won't anonymize anything in the CLF

[consensus reached: not important]


Vijay: what about the issues with rfc3841, where UAC can make proxy act different

Many people: don't care about that, not an issue

[consensus reached: not important]


Last words: need to update draft, discuss on mailing list

------------------------------End

-hadriel