The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model
Note: This ballot was opened for revision 11 and is now closed.
(Robert Sparks) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Benoît Claise) (was Discuss) No Objection
I'm available if you need to discuss those comments. - The field semantic is not clear, at least to me as an non SIP expert. For example: Status - The SIP response status code. Would be great if pointers would be given. Such as: www.iana.org/assignments/sip-parameters Unless all the field semantic and possible values are obvious to all SIP experts. - Section 5.3 And finally, because of the frequency and size of SIP log messages, it is not desirable to send every SIP CLF log message to the collector. Instead, a judicious use of syslog could be that only certain events -- those that are pertinent from a network situational awareness perspective, or those that include a periodic statistical summary of the messages processed -- are sent to the collector. Syslog filtering per collector is a very basic feature on router. I don't understand how this could be an argument. - Regarding Stephen's DISCUSS, see rfc6235 - I'm confused that section 5 (Alternative approaches to SIP CLF) comes before section 6 that explains the use cases. My issue is that you take some use case based arguments to discard some solution. Example: Two, a CDR record will, in all probability, be generated at a SIP entity performing some form of proxy-like functionality of a B2BUA providing some service. By contrast, SIP CLF is light- weight enough that it can be generated by a canonical SIP user agent server and user agent client as well, including those that execute on resource constrained devices (mobile phones). - I've following the SIPCLF work during a couple of meetings. You selected SIPCLF (and not IPFIX) because of this requirement "the log file must be easily accessible by command line tools for simple text processing." Fine, I would advice to add a clarification that there are no requirements/use cases regarding the correlation of SIPCLF with different sources of information, such as IPFIX, syslog, CDR, etc... If it was the case, the conclusions might have been different.
(Ralph Droms) (was Discuss) No Objection
I've cleared my DISCUSS and COMMENT positions. Thanks for addressing the issues I raised.
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
(Brian Haberman) No Objection
(Russ Housley) No Objection
(Barry Leiba) No Objection
(Pete Resnick) No Objection
Comment (2012-12-18 for -11)
Section 8: Some of these fields contain URIs [RFC3986]. If the URI contains an escaped character (""%" HEX HEX" mechanism), the escaped character MUST be logged as received. The maximum size (in number of bytes) for a SIP CLF field is 4096 bytes. Similar to Stephen's concern, how to encode escaped characters and byte length of fields seems like a job for the format, not for the data model. If someone chose to write a binary CLF instead of the UTF-8 one specified in -format, the above wouldn't make sense. If you want this document to actually start talking about those things, the last paragraph of section 2 will need to be fixed. Logging bodies of a SIP message is left optional (and is not shown in the examples of Section 9). If the body is to be logged, the specific syntax and semantics used to log bodies MUST be defined by the specific representation format used to generate the SIP CLF record. The word "optional" looks like it might reasonably be a 2119 term, since it is warning implementers that they might or might not find bodies in a record made by another implementer. Seems like OPTIONAL might be reasonable to say. On the other hand, I can't make heads or tails out of the second sentence. I cannot figure out why it says "MUST be defined" instead of "will be defined". The MUST seems wrong here. (This also occurs in the last sentence of 8.1, and in the 2nd paragraph of 8.2.) 8.1: For the sake of brevity, URI parameters SHOULD NOT be logged. Is brevity the only reason? What interoperability failure or harm will come if an implementation chooses to log them? If none, skip the 2119 nonsense. 8.2: Each SIP CLF record MUST consist of all the mandatory data model elements outlined in Section 8.1. This document does not specify a representation of a logging format; it is expected that other documents will do so. Each SIP CLF record MUST contain the mandatory elements shown below: Timestamp, Message type, Directionality, CSeq-Method, CSeq-Number, Transport, R-URI, Destination-address, Destination-port, Source-address, Source-port, To, To-tag, From, From-tag, Call-ID, Status, Server-Txn, Client-Txn OK, so 8.1 already says that the fields listed there "MUST appear in any SIP CLF record." Here, you repeat that in the first sentence of 8.2, and then repeat the list of fields with yet another MUST. Aside from the redundancy (which I think should call for the elimination of some of this anyway), re-listing the fields with another MUST is inviting a bug: You already, for example, say "Callid" in 8.1 and "Call-ID" in 8.2, and the lists are in slightly different order; as far as I can tell, the lists are otherwise consistent. But this is inviting an editing error down the road, and if someone does an update to the document and updates one section but not the other, you're bound to have an inconsistency. I'd prefer the first paragraph in 8.2 to go away entirely, but at least get rid of the last sentence and the list of fields.
(Martin Stiemerling) No Objection
(Sean Turner) No Objection
Comment (2012-12-17 for -11)
I support Stephen's discuss.