The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model
draft-ietf-sipclf-problem-statement-13

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.

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.

I've cleared my DISCUSS and COMMENT positions.  Thanks
for addressing the issues I raised.

I support Stephen's discuss.