[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 _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
