I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document provides a set of goals and a data model for a "common logging format" for SIP, in analogy to the widely-used Apache log format for HTTP.  As the document correctly notes, the primary concern for this document is the protection of potentially private data protected in such logs.  I do not think that the document misses any serious security considerations.

A couple of relatively minor comments:

Section 5.1: 
s/of a B2BUA/or a B2BUA/

Section 6: 
It seems to me that the document would read better if this section were swapped with Section 5.

Section 6:
You mention training anomaly-detection systems based on SIPCLF logs.  It seems to me that this approach could be much more limited for SIP than it is for HTTP, both because of the greater inherent diversity in SIP and because of SIPCLF does not have visibility into the media path.  So it could be good to comment on what these systems would and would not detect, either here or in the Security Considerations.   Are you aware of any existing anomaly detection systems that would be able to use SIPCLF data? 

Section 8.1, Source-Address / Destination-Address:
These definitions are a little ambiguous.  I assume you mean the address of the source/destination for a particular UDP/DTLS datagram or TCP/TLS connection, as opposed to an address for a SIP-layer recipient.  For example, for an INVITE in the following topology...
  UAC -> ProxyA -> ProxyB -> UAS
... If ProxyB were logging in SIPCLF, then the inbound invite would have Source-Address=IP(ProxyA) and Destination-Address=IP(ProxyB).

Section 9.1:
It would be helpful to have SIP messages to refer to here, either by including them in this document, or by referring to a document containing them, such as RFC 3665.

Section 10:
It seems important to note here that both operators and users have private information at stake here -- topology mapping vs. identity correlators and calling patterns.  

Section 10: 
With regard to transmitting logs over the Internet, the reference to RFC 3552 is not very useful.  More concrete examples would be better, e.g., HTTPS, SSH.  Might it also be possible/useful to convey SIPCLF messages over Syslog?