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

[Ballot discuss]
This is a nicely written, easy to understand document.  Thank you.

I'd like to discuss some minor clarifications that I think would help
the document more accurately describe what it is about and what it
specifies (as it is a Standards Track document).  I'll emphasize that
these are points for discussion rather than issues where I think the
document is unequivocally wrong.

1. (cleared after discussion with Robert Sparks)

2. Are the mandatory fields described in section 8.1 the only fields
that will ever be allowed or is there an expectation that new
mandatory and optional fields might be defined at some point?  I ask
because I read the first sentence of section 8.2 to mean that other
fields (TBD in the future) are disallowed from SIP CLF records:

  Each SIP CLF record MUST consist of all the mandatory data model
  elements outlined in Section 8.1.

It's a small change, but would this replacement be more accurate:

  Each SIP CLF record MUST contain all of the mandatory data model
  elements outlined in Section 8.1.

3. Another small change, but significant (my opinion, of course!)
would be in the last sentence of the abstract, which led me to believe
the document would be specifying more than it actually does:

  We propose a common log file
  format for SIP servers that can be used uniformly by user agents,
  proxies, registrars, redirect servers as well as back-to-back user
  agents.

Does this better describe the contents of the document:

  This document describes a framework, including requirements and
  analysis of existing, and specifies a data model for development of
  a SIP CLF for SIP servers that can be used uniformly by user
  agents, proxies, registrars, redirect servers as well as
  back-to-back user agents.

[Ballot discuss]
This is a nicely written, easy to understand document.  Thank you.

I'd like to discuss some minor clarifications that I think would help
the document more accurately describe what it is about and what it
specifies (as it is a Standards Track document).  I'll emphasize that
these are points for discussion rather than issues where I think the
document is unequivocally wrong.

1. The title correctly states that this document provides a "framework
and data model" for SIP CLF.  I see three different parts of SIP CLF
that are discussed at various points in the document: how and where
SIP CLF records are generated, what information is required for each
SIP CLF record and an on-the-wire/on-disk format for representing that
information.

I understood the purpose of the document to focus on the motivations
for a common SIP CLF data model and record format, and that the three
considerations I listed above would be examined independently.
Section 5 was a little confusing to me, therefore, as it mixed all
three considerations together in examining existing approaches.
Perhaps the motivation for section 5 was to examine alternatives to
building any new specifications at all?  In any event, I was left
wondering why, e.g., the syslog message format couldn't be reused even
if the messages were generated and transported independent of the
existing syslog mechanisms.

2. Are the mandatory fields described in section 8.1 the only fields
that will ever be allowed or is there an expectation that new
mandatory and optional fields might be defined at some point?  I ask
because I read the first sentence of section 8.2 to mean that other
fields (TBD in the future) are disallowed from SIP CLF records:

  Each SIP CLF record MUST consist of all the mandatory data model
  elements outlined in Section 8.1.

It's a small change, but would this replacement be more accurate:

  Each SIP CLF record MUST contain all of the mandatory data model
  elements outlined in Section 8.1.

3. Another small change, but significant (my opinion, of course!)
would be in the last sentence of the abstract, which led me to believe
the document would be specifying more than it actually does:

  We propose a common log file
  format for SIP servers that can be used uniformly by user agents,
  proxies, registrars, redirect servers as well as back-to-back user
  agents.

Does this better describe the contents of the document:

  This document describes a framework, including requirements and
  analysis of existing, and specifies a data model for development of
  a SIP CLF for SIP servers that can be used uniformly by user
  agents, proxies, registrars, redirect servers as well as
  back-to-back user agents.

[Ballot comment]
1. Why is the list of fields defined in section 8.1 repeated in
section 8.2?  Seems like an opportunity for text to get out of sync...

2. In section 9, could you find some terms more precise than
"viewpoint" and "point of view"?

3. Obligatory pedantic, professorial nit: in section 11, "substantive"
does not have the same meaning as "substantial"; the latter is more
correct, I think.

[Ballot discuss]
-
  "In addition, it provides a data model pertaining to the minimum
  set of SIP headers and fields that must be logged.  This document
  does not prescribe a specific representation format for the SIP CLF
  record and instead, allows other documents to define a representation
  format.  [I-D.ietf-sipclf-format] is an example of a representation
  format that provides an UTF-8 based logging scheme."

Basically, you specify an information model in this document, not a data model. See RFC 3444, which says:

            IM                --> conceptual/abstract model
              |                    for designers and operators
  +----------+---------+
  |          |        |
  DM        DM        DM    --> concrete/detailed model
                                  for implementors

A typical change, as an example
OLD:
  However, we stress that the data model
  contained in this document can be used to develop alternative
  representation formats when desired.  Currently,
  [I-D.ietf-sipclf-format] is an example of a representation format
  that provides an UTF-8 based logging scheme that meets all the
  requirements of Section 3.

NEW:
  Currently,
  [I-D.ietf-sipclf-format] is a representation format (data model) that
  provides an UTF-8 based logging scheme that meets all the
  requirements of Section 3.  However, we stress that the information model
  contained in this document can be used to develop alternative
  representation formats when desired.

- Section 5.4
  "However, IPFIX is not a logging format and does not produce a log
  file that can be examined by ad-hoc text processing tools.
  Furthermore, while IPFIX can collect the same information that a SIP
  entity produces in a log file using SIP CLF, it does so at the
  packet-level.  This means that SIP traffic has to be in cleartext so
  that the required SIP headers and their values can be extracted."

The last 2 sentences are wrong/confusing.
IPFIX is about the Exporting Process (RFC5101 definition), so how we encode the information elements.
IPFIX is not about the Metering Process (RFC5101 definition). So there are no requirements that
IPFIX must be looking at packet level information. As long the information is available one way or the other,
this can be encoded.
Please improve or remove the last two sentences.

- Section 8.2
  "An element will not always have an appropriate value to provide for
  one of these fields, even when the field is required to appear in the
  SIP CLF record.  Therefore, the representation document MUST define
  how to indicate a field is "not applicable".
Do you need to make a difference between "no applicable" and "empty"?
Maybe the answer is as simple as "no"
In the examples, what does "-" mean? "no applicable" and "empty"?
For example:
      Status: -
      Server-Txn: -

Along the same lines, http://tools.ietf.org/html/draft-ietf-sipclf-format-09 mentions:
  In the event that a field failed to parse it MUST be encoded as a
  single question mark ("?"). 

Does it mean that we need something such as?
  "Therefore, the representation document MUST define
  how to indicate a field is "not parse-able".

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]

section 10: You say that some fields SHOULD be anonymized or
obfuscated, which is ok for this draft, but the recipient of
such a file has no way to tell which fields have been
obfuscated, nor what kinds of correlation are still supported
and that is likely to impact on interop, as those files
are exchanged. Isn't there a need for another spec for how
to do that? I'd be ok if you said something like:

  "A specification for a format that says which fields are
  obfuscated and with what characteristics (e.g. what
  correlations still work) is needed to allow interoperable
  but privacy-friendly exchange of CLF files between
  domains. That is not done here and is for future study."

I'd be even happier if someone planned to do that, since
I do think it'll be needed in at least some places, and
without that spec you will get odd behaviour from tools.

[Ballot comment]

- expand CDR on 1st use

- section 8, '(""%" HEX HEX" mechanism)' isn't very clear,
maybe better to just say "%-escaped" and add some reference.

- section 8: is it a good idea to have a max field size defined
in the (abstract) data model rather than in the format draft?
Seems odd.

IANA has reviewed draft-ietf-sipclf-problem-statement-11, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Data Model) to Proposed Standard


The IESG has received a request from the SIP Common Log Format WG
(sipclf) to consider the following document:
- 'The Common Log Format (CLF) for the Session Initiation Protocol (SIP):
  Framework and Data Model'
  as Proposed Standard

A previous version of this document was Last Called with an Informational
intended publication status. Issues with the document's scope and technical
concerns with internationalization were identified during IESG evaluation and
the document was returned to the working group.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-12-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Well-known web servers such as Apache and web proxies like Squid
  support event logging using a common log format.  The logs produced
  using these de-facto standard formats are invaluable to system
  administrators for trouble-shooting a server and tool writers to
  craft tools that mine the log files and produce reports and trends.
  Furthermore, these log files can also be used to train anomaly
  detection systems and feed events into a security event management
  system.  The Session Initiation Protocol (SIP) does not have a common
  log format, and as a result, each server supports a distinct log
  format that makes it unnecessarily complex to produce tools to do
  trend analysis and security detection.  We propose a common log file
  format for SIP servers that can be used uniformly by user agents,
  proxies, registrars, redirect servers as well as back-to-back user
  agents.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sipclf-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sipclf-problem-statement/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is a proposed standard. It defines a data model for logging SIP messages.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The Session Initiation Protocol does not have a common log

  format, and as a result, each server supports a distinct log format

  that makes it unnecessarily complex to produce tools to do trend

  analysis and security detection.  This document provides motivation

  for a common format and defines the mandatory fields for such a log as

  well as a need to allow extensions.

Working Group Summary:

There were some issues with respect the choice of indexed-ascii versus binary representation. This stalled the WG progress for a number of meeting. This is described in more detail in (9) below. The final product now has good support in the WG.

This document has had one cycle of IESG review. This review raised issues to do with internationalization, UTF as well as concerns that the write up did not fully reflect some of the WG discussion. These issues have been addressed in the -11 version and this revised write-up.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are some implementations as indicated by Vijay Gurbani:.

At least three implementations are known, although none deployed as far
as I can tell.

One was being implemented by Anders Nygren, as posted on the list [1].
ALU has an early implementation, but it is conditionally compiled into
the code.  Illinois Institute of Technology did an implementation based
on Asterix codebase, but I do not think the students gave it back to
Asterix.

[1] http://www.ietf.org/mail-archive/web/sip-clf/current/msg00435.html


Personnel:

Peter Musgrave is the document shepherd.

Robert Sparks in the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The post-IESG review document was reviewed by Peter Musgrave andRobert Sparks. Prior to IESG review it had several WG last-Calls.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns about the reviews depth/breadth.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No broader review was deemed necessary.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The consensus for the fields which any format solution needs to log have been uncontroversial. The minimal set of fields are basic to any SIP record keeping and an extension mechanism allows customization by those who need more.

The discussion of potential mechanisms and alignment with existing mechanism was more spirited. Syslogand Ipfix logging have had advocates at various times.

The IETF77 minutes record a discussion about a need to look seriously at IPFIX. Syslog was also discussed and a comment made that data was too much for syslog (and was concurred with by chair of syslog).

Some comments made (DaveH) - suggesting syslog needs further scrutiny (http://www.ietf.org/mail-archive/web/sip-clf/current/msg00105.html). Comments were made expressing concern about binary content in SIP messages (Hadriel Kaplan) and extreme sizes of some elements (Cullen Jennings). Syslog expert (Rainer Gerhards) indicated that the size issues should not be a major concern although there are parts of the syslog community that prefer small sizes. The final email in this chain is http://www.ietf.org/mail-archive/web/sip-clf/current/msg00141.html and after that no one "went to bat" for syslog and energy went into discussions of IPFIX versus Indexed ASCII.

The IPFIX vs indexed-ASCII discussion lasted for a number of meeting cycles with neither garnering complete support. Over time the group decided to proceed with indexed ascii. There is agreement that the data model defined by sipclf could be used as a basis for an IPFIX format should some future group wish to define one. 


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There have been no signs of extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.



There is one NIT:

== Outdated reference: A later version (-09) exists of

    draft-ietf-sipclf-format-05


This document is moving to IESG approval in parallel with this document.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

None.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no down refs.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

N/A

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

N/A.

[Ballot discuss]
updated for -11-

I don't think my concerns have been addressed.

1) I agree with the other IESG members who think this exceeds the scope of a problem statement.

2) I agree with the DISCUSS that the shepherd writeup is lacking in useful detail. In my opinion this writeup is woefully inadequate to reflect the nature of the discussions that occurred, some contentious.

3) The document fails to include any summary of WG discussions of using existing IETF protocols.

There was contention about whether the logging should be designed only for logging locally, or for local use and for being transported between systems. The WG discussed the need for secure transport of logged information. Existing standards already address this, e.g. syslog/TLS [RFC5425] and ipfix RFC5101]. This should be documented as part of the problem space.

The WG debated whether pre-filtering was a desirable feature, to control log growth rates, and bandwidth needed for transporting logs, and whether existing standards could be utilized for this purpose (ipfix offers a template approach that controls what data gets logged, and what data gets transported; syslog supports facility and severity values, and a config file can specify which records should be forwarded to a receiver). This need should be documented as part of the problem space.

4) The document describes wireshark as inappropriate because the wireshark libraries would need to have sipclf functionality implemented across multiple OSes and configurations. But the proposed solution seems to be to develop a whole new format, so any tools for parsing this new format would need to be developed from scratch, across multiple OSes and configurations. That strikes me as an odd problem statement to justify a new sipclf approach.

5) I support the Discusses about whether the sipclf mandatory fields in section 8 is normative. If this is not normative, then RFC2119 language is probably inappropriate. If it is normative, then it belongs in a standards track document.

6) Security considerations discusses the threats associated with stored logs. Existing standards for logging include capabilities for signing logs and detecting deletions and modifications [RFC5848], whether at rest or in transit. The potential need to secure logs at rest and in transit is part of the problem with logging SIP, and should be documented as part of the problem space.

7) New text to address my discuss has some inaccurate information that should be corrected.
"A new problem
  arises due to the general nature of syslog: the disk file will
  contain log messages from many originators, not just SIP entities.
  This imposes an additional burden of discarding all extraneous
  records when analyzing the disk file for SIP CLF records of interest."
and under drawbacks,
"because of the frequency and size of SIP log messages, it is not
  desirable to send every SIP CLF log message to the collector."

syslog is designed to allow specfication of facility and severity for filtering purposes, and the entries for specific facility/severity combinations can be directed to a local file or remote file. SIP messages can be directed to a SIP log file; specific event types can be selected for logging. So an operator can configure syslog to avoid the problem of having all syslog messages dumped into a single file that then becomes difficult to search. It seems to me that syslog actually handles this better then a sipclf that dumps all sip messages into a file.
I note that there is nothing in the problem statement section of this document that specifies that a sipclf must be able to filter which information gets logged or does not. There is no mention of such filtering in the probem statement, except to disqualify existing standards.

The text disqualifies syslog because it cannot be easily parsed, but syslog messages are in text format (typically the ascii subset of utf-8), and the first byte is encoded as a product of the facility (application) and message severity, explicitly to allow fast discarding of records that are not of interest when parsing logs of mixed application entries and/or logs of different event types.

The text implies syslog is not easily searchable by command line tools. Under the syslog section, the text says "SIP CLF records are best stored in a log file that is easily searchable by command line tools." Syslog messages are deliberately written in a utf-8 text format, with clear delimiters defined in the ABNF, and most implementations store the messages in a text file that is easily accessible to command line tools.

Syslog might not be best choice for this sipclf purposes, but this document seems full of misinformation to justify a solution that was decided on before any analysis of existing standards was done. I think it is a disservice to the community to publish a document with such misinformation. It is also a disservice to the community to waste resources reinventing wheels, such as a TLS transport for securely transporting sipclf files between hosts, when existing logging standards already offer these features. This document doesn't identify that need as part of the problem statement for sipclf, but apparently feels it is important enough to mention it in the security considerations. If logs need to be transferred between hosts, why is this not mentioned as an aspect of the problem to be solved?

As with many problem statements documents coming thruogh the IESG, I think this probem statement does a poor job of clearly describing the problems to be solved to justify a new standard protocol.

[Ballot discuss]
updated for -10-

I don't think my concerns have been addressed.

1) I agree with the other IESG members who think this exceeds the scope of a problem statement.

2) I agree with the DISCUSS that the shepherd writeup is lacking in useful detail. In my opinion this writeup is woefully inadequate to reflect the nature of the discussions that occurred, some contentious.

3) The document fails to include any summary of WG discussions of using existing IETF protocols.

There was significant contention in the WG about whether existing IETF standard data modeling languages, such as syslog structured data elements [RFC 5424] or ipfix Information Elements [RFC5655] could have been used for SIP logging. If this document is going to discuss why Apache CLF and Wireshark do not meet sipclf needs, which I believe it should, then the document should also explain the WG considerations for using syslog, ipfix, and psamp data models for SIP logging. This gap between existing standards and the problems prompting a new sipclf approach should be documented as part of the problem space.

There was contention about whether the logging should be designed only for logging locally, or for local use and for being transported between systems. The WG discussed the need for secure transport of logged information. Existing standards already address this, e.g. syslog/TLS [RFC5425] and ipfix RFC5101]. This should be documented as part of the problem space.

The WG debated whether pre-filtering was a desirable feature, to control log growth rates, and bandwidth needed for transporting logs, and whether existing standards could be utilized for this purpose (ipfix offers a template approach that controls what data gets logged, and what data gets transported). This should be documented as part of the problem space.

4) The document describes wireshark as inappropriate because the wireshark libraries would need to have sipclf functionality implemented across multiple OSes and configurations. But the proposed solution seems to be to develop a whole new format, so any tools for parsing this new format would need to be developed from scratch, across multiple OSes and configurations. That strikes me as an odd problem statement to justify a new sipclf approach.

5) I support the Discusses about whether the sipclf mandatory fields in section 8 is normative. If this is not normative, then RFC2119 language is probably inappropriate. If it is normative, then it belongs in a standards track document.

6) Security considerations discusses the threats associated with stored logs. Existing standards for logging include capabilities for signing logs and detecting deletions and modifications [RFC5848], whether at rest or in transit. The potential need to secure logs at rest and in transit is part of the problem with logging SIP, and should be documented as part of the problem space.

[Ballot comment]
I think we need a log file format. And it needs to work on application level, because, as noted, layer 3 or 4 security makes it impractical to read off the contents of SIP messages.

I'm less convinced about the specific proposal here. The text on wireshark for instance seems to indicate some lack of information on various logging mechanisms in the Internet. (Wireshark is just a tool that operates on the more general pcap http://en.wikipedia.org/wiki/Pcap interface.)

I would guess that there are multiple needs in this space. One is for detailed SIP message logging for debugging and statistics purposes. For that purpose, a pcap-like recording of exact messages at the application layer might be more appropriate. Another need is for more high-level, CDR/billing/high-level statistics collection type of needs. There some summary of SIP events would be more appropriate. This would not necessarily record every message, and could even record some non-message events such as when the SIP entity gives up on trying to contact someone. The current design seems to be some mixture of these two kinds of approaches.

[Ballot comment]
The document states that the Wireshark format cannot be used because "if the SIP messages are exchanged over a TLS-oriented transport, Wireshark will be unable to decrypt them and render them as individual SIP headers." Is there a reason why SIP servers cannot use the Wireshark *format* as a CLF even if they cannot use the Wireshark *application* on the data sent over an encrypted channel?

A true nit: there is no such thing as "12:00 PM".

Another nit: I have never seen "pend" as a verb. I suggest "can be in a pending state" or somesuch.

When talking about URIs in Section 8, an informational reference to RFC 3986 would be appropriate.

The allowable values for the Message type field are 'R' (for Request) and 'r' (for response). Is it really a good idea to use values that differ only by case? (Also, the Directionality field has a value of 'r' -- another source of possible confusion; you might consider "o" and "i" for outbound and inbound instead of "s" and "r" for sent and received.)

[Ballot discuss]
I'd like to chat about internationalization. Section 8 mentions draft-ietf-sipclf-format as an example of a representation format that provides an ASCII-based encoding scheme. Are there any examples of encoding schemes that allow code points outside the ASCII range? More generally, what are the internationalization requirements for SIP logging? The requirements might be "none" if SIP messages cannot contain, say, UTF-8 encoded Unicode characters, but if so then it would be best for the specification to make that explicit.

[Ballot comment]
Seems like others have the DISCUSS points well in hand.

It seems a bit goofy in section 8.1 to call out fields as "mandatory" and even say that they are "minimal information that MUST appear in any SIP CLF record", and then go on in section 9 to point out for some items: "When a given mandatory field is not applicable to a SIP entity, we use the horizontal dash ("-") to represent it." That would make the field pretty clearly non-mandatory.

[Ballot comment]
1) section 6 strikes me as marketing claims for the wonderful things that a sipclf can provide. But these tools are not part of the scope of sipclf development. I question whether these claims of tools that could be developed really is part of a problem statement.

2) RFC 3444 describes the difference between Information models and Data models. If section 8 is not a normative data model, then it should probably be called an Information model, rather than a data model.

[Ballot discuss]
1) I agree with the other IESG members who think this exceeds the scope of a problem statement.

2) I agree with the DISCUSS that the shepherd writeup is lacking in useful detail. In my opinion this writeup is woefully inadequate to reflect the nature of the discussions that occurred, some contentious.

3) The document fails to include any summary of WG discussions of using existing IETF protocols.

There was significant contention in the WG about whether existing IETF standard data modeling languages, such as syslog structured data elements [RFC 5424] or ipfix Information Elements [RFC5655] could have been used for SIP logging. If this document is going to discuss why Apache CLF and Wireshark do not meet sipclf needs, which I believe it should, then the document should also explain the WG considerations for using syslog, ipfix, and psamp data models for SIP logging. This gap between existing standards and the problems prompting a new sipclf approach should be documented as part of the problem space.

There was contention about whether the logging should be designed only for logging locally, or for local use and for being transported between systems. The WG discussed the need for secure transport of logged information. Existing standards already address this, e.g. syslog/TLS [RFC5425] and ipfix RFC5101]. This should be documented as part of the problem space.

The WG debated whether pre-filtering was a desirable feature, to control log growth rates, and bandwidth needed for transporting logs, and whether existing standards could be utilized for this purpose (ipfix offers a template approach that controls what data gets logged, and what data gets transported). This should be documented as part of the problem space.

4) The document describes wireshark as inappropriate because the wireshark libraries would need to have sipclf functionality implemented across multiple OSes and configurations. But the proposed solution seems to be to develop a whole new format, so any tools for parsing this new format would need to be developed from scratch, across multiple OSes and configurations. That strikes me as an odd problem statement to justify a new sipclf approach.

5) I support the Discusses about whether the sipclf mandatory fields in section 8 is normative. If this is not normative, then RFC2119 language is probably inappropriate. If it is normative, then it belongs in a standards track document.

6) Security considerations discusses the threats associated with stored logs. Existing standards for logging include capabilities for signing logs and detecting deletions and modifications [RFC5848], whether at rest or in transit. The potential need to secure logs at rest and in transit is part of the problem with logging SIP, and should be documented as part of the problem space.

[Ballot comment]
In the 'Operational guidance' section:

> SIP CLF log files will take up substantive amount of disk space
  depending on traffic volume at a processing entity and the amount of
  information being logged.  As such, any enterprise using SIP CLF
  should establish operational procedures for file rollovers as
  appropriate to the needs of the organization.


I suggest to replace the word 'enterprise' with 'organization'. The issue is certainly present in all type of networks, not only in enterprise deployment as it may be mis-understood here.

[Ballot comment]
Editorial observation: "CLF format" is redundant.

Process comment - the IESG Writeup Working Group Summary consists of
one sentence: "The problem statement was not contentious."  I can't
tell if this sentence refers to just the problem statement in section
3 or the entire document.  I note that the document name includes
"problem-statement" while the title includes "Framework and Data
Model."  Perhaps the goals and purposes of the document changed during
its development?  It would be helpful if the Working Group Summary gave
more detail about the background, development and purpose of the
document.

Niggling irritation - the first couple of motivations listed in
section 6 are relevant to the development of a CLF.  The remainder
don't actually depend on a CLF; a CLF might ease the development of
solutions to those problems.

Which representation format is used in the example in section 9.1, or
is the example an abstract representation independent of any specific
format like the one defined in draft-ietf-sipclf-format-03?

[Ballot discuss]
The exact purpose and intended use of this document is not clear to
me.  The document name include "problem-statement," the title includes
"Framework and Data Model," and the abstract concludes with the
sentence:

  We propose a common log file format
  for SIP servers that can be used uniformly by user agents, proxies,
  registrars, redirect servers as well as back-to-back user agents.

I don't know if the text in section 4 is referring to the standards
track CLF as defined in this document or an hypothetical CLF to be
defined based on the problem statement in section 3 and the data model
in section 8.  In fact, it seems that section 8 defines something more
than just a data model, as it defines mandatory elements in CLF
records, etc.

The document needs a clear statement about whether or not it is
defining the operational abstraction for the standards CLF.  If it is
defining that standards CLF, it needs to be a standards track document.

[Ballot discuss]
I would like to discuss with the authors whether the data model is an example or is definitive? If it is definitive why is it in an informational draft, and indeed why is it not in an IANA registry?

If it is not definitive, then please can this be made clearer in the document.

[Ballot comment]
Although this document does not define a CLF for SIP, I am not clear why
the data model here is not normative as a Standards Track document.

---

I wonder if you could consider adding to Section 7 a discussion of the
migration / backward-compatiblity issues. Maybe these are no worse than
today, but it will certainly be the case that a log file will need to
contain some indication that it is in the CLF.

[Ballot comment]
- What does "trace a call from one entity to another mean"?  I do
hope we're not proposing that lawful intercept is the primary
reason for this work.

- You say a few things the CLF is not at the end of section 4,
would it be reasonable to add "The SIP CLF is not a tool for
supporting lawful intercept."

- Public access to the log is worse than network sniffing in at
least two respects - log access trumps TLS and also network
sniffing is more restricted in time and place (topology).

[Ballot discuss]
This seems like a lot more than a problem statement.  I'm not clear
whether the security and privacy considerations here will be relied
upon in the format spec or not.  At present, -05 of the format
draft says that this document says all that needs to be said, which
is not something with which I agree. So, for now, I'm treating the
security considerations here as those that will be provided as the
final output of the sipclf WG. (Were this only a problem statement
then that'd not be the case.)

#1 While this document might not be able to say how files are to be
protected, both locally and in transit, it could easily, and IMO,
should, state requirements for that using 2119 MUSTs and also
include some examples of how to meet those, e.g.  REQUIRE mutual
authentication, confidentiality and integrity for transfers with
the example that use of mutual auth TLS between nodes accomplishes
this. (Note: I'd be fine if this were instead handled in the format
document since that's I guess what most coders will read.)

#2 IP src&dest and SIP to&from are mandatory - that's not very
privacy friendly. Did the WG consider this? Did the WG consider
defining an additional (less sensitive, more easily shared) format
where those are obfuscated (but so as to still allow correlation?)
If so, why wasn't that adopted? If not, doesn't that warrant
consideration? (As-is sharing CLF files is likely to be tricky from
at least an EU data protection p-o-v if there are some cross-border
nodes involved.)

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Data Model) to Informational RFC


The IESG has received a request from the SIP Common Log Format WG
(sipclf) to consider the following document:
- 'The Common Log Format (CLF) for the Session Initiation Protocol (SIP):
  Framework and Data Model'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-12-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Well-known web servers such as Apache and web proxies like Squid
  support event logging using a common log format.  The logs produced
  using these de-facto standard formats are invaluable to system
  administrators for trouble-shooting a server and tool writers to
  craft tools that mine the log files and produce reports and trends.
  Furthermore, these log files can also be used to train anomaly
  detection systems and feed events into a security event management
  system.  The Session Initiation Protocol does not have a common log
  format, and as a result, each server supports a distinct log format
  that makes it unnecessarily complex to produce tools to do trend
  analysis and security detection.  We propose a common log file format
  for SIP servers that can be used uniformly by user agents, proxies,
  registrars, redirect servers as well as back-to-back user agents.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sipclf-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sipclf-problem-statement/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Peter Musgrave is the document shephard and has read version -07. This version is ready for publication subject to the correction of two nits after AD review.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes. Over the past 18 months the document has seen significant input from a number of people with strong background in SIP.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The consensus for the fields which any format solution needs to log have been uncontroversial. The minimal set of fields are basic to any SIP record keeping and an extension mechanism allows customization by those who need more.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

There are two minor nits (There are 2 instances of lines with non-RFC5735-compliant IPv4 addresses). These will be addressed after AD review.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

This section exists. There are no IANA considerations

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no such sections.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

The Session Initiation Protocol does not have a common log
format, and as a result, each server supports a distinct log format
that makes it unnecessarily complex to produce tools to do trend
analysis and security detection. This document provides motivation
for a common format and defines the mandatory fields for such a log as
well as a need to allow extensions.

Working Group Summary

The problem statement was not contentious.

Document Quality

During the review process two implementations were developed by two different implementors.
These helped clarify some of the details in this document.