Subject: Re: [sip-clf] draft-ietf-sipclf-problem-statement-02

From: Peter Musgrave <[email-masked]>
Date: Sat, 12 Jun 2010 10:07:22 -0400

Hi Vijay,

Thanks for the new revision. Overall it seems very complete and reads well.

I have a couple of material comments and some assorted editorial comments:

Material Comments:
================
8.0
The datamodel:
I would suggest protocol and total message size be included in the datamodel.
Protocol could be included in the IP:port portion i.e. 1.2.3.4:5060:udp

8.1
"---in the order specified---"
Should the problem statement constrain the log format in this way? I'm
not sure what is gained by this requirement.
[Likewise in 8.2/8.3]

8.1-8.3
I would prefer one format for all the cases with just the use of a -
in cases where the value does not apply. I'm also not sure if this
should be a log format issue and not constrained in the problem
statement. The strength of apache CLF is in part that in a text view I
can scan down columns and see what's up. If each line is constrained
by the problem statement to be different from an information model
point of view then I cannot have a log format like this.

I would prefer to have to and from in all log lines (even though it's
chattier) since I can look at one log line and see who the parties are
without reference to other lines.

11
I think that the detailed discussion from the mailing list is
unnecessary but I do think providing guidance on the typical and
extreme values of the minimum data model elements would be useful. It
will save a lot of implementers the work of doing this for themselves.

Editorial Comments:
================
Section 4 para 1
"For example…."
I'm not sure the example of having a concise command is necessary in
the problem statement. I think the problem statement is ok without it
and I see no advantage in trying to specify exact forms of commands
for looking at logs. This seem to me out of scope.

5.2
"the Wireshark format is a binary format that does not lend itself
very well to being manipulated by text-based tools"
Now that there is binary format supported by the sipclf group is the
binary format objection to wireshark still appropriate?

8.0
"Besides the mandatory fields listed above, all other SIP headers will
appear as an ordered pairs of header field names and values."
I think this means that when extended the extensions will list a
header names and values - but it's easy to read this as "all other SIP
headers.." will be logged all the time.

9.
The comments at the end about the use of grep should be qualified with
"In a text based log format"

10 (Nit) bullet one: viewing is mis-spelled

Regards,

Peter Musgrave
(as individual)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 15 Jun 2010 15:50:12 -0500

> I have a couple of material comments and some assorted editorial comments:

Peter: Thank you for your review.  Please see inline.

> Material Comments:

Let me divide your comment above in two distinct parts: record length
and transport.

For the record length, you bring up a good point in that it needs to be
in the data model.  The indexed-ASCII approach that is currently being
edited has a record length field, and I suspect that the IPFIX format
will allow for one as well.  I will add a record length to the data
model.

The transport is an interesting field.  If one was to log the topmost
Via header, the transport would be there.  However, in the absence of
logging the topmost Via header, the transport information is lost.
About the only thing that can be said with any certainty on the
transport is that if a sips: URI scheme appears in the R-URI, then
the transport would be TLS (although, one will not know whether it was
TLS-over-TCP or TLS-over-UDP by examining the URI scheme.)

I think it makes sense to add the transport information to the
mandatory fields in the data model (to avoid logging an entire Via
header line.)  Unless others have a different opinion, I will do
so in the next revision.

> not sure what is gained by this requirement.

It will be nice to maintain the ordinal value of the fields.  A quick
advantage is that if I use text tools to browse through the indexed-
ASCII logfile, I can visually line up the fields.  Admittedly, this
may not be a draw for a binary format, but regardless, I don't
think there is a harm to prescribe an ordinal location of the
fields.

> point of view then I cannot have a log format like this.

Unfortunately, using one format for all cases is not a liberty we
can avail of in SIP.  We can do so in HTTP since it is --- in a
transactional sense --- simpler than SIP.  A HTTP server gets a
request, does some transformation to generate a response and the
response gets sent out shortly (mostly within seconds, if not
milliseconds).  So, all the information to log individual fields
is available to an HTTP server.

Furthermore, the canonical HTTP CLF format is simple for origin
servers in HTTP.  If you were to look at the log format for a HTTP
proxy server (like Squid), you will note more complexity.

SIP, by contrast, is not as giving.  There may be a time difference
of minutes between when an INVITE arrived at a server and when a
200 OK is generated (think call queuing).  Holding on to all the
messages until we have a final response will not work for SIP.

> will save a lot of implementers the work of doing this for themselves.

I will attempt to put something in place in the next revision.

> Editorial Comments:

The "Note: ..." indented section is a holdover.  I will remove it in
the next revision.

> binary format objection to wireshark still appropriate?

Probably not from the binary format point of view.  I can take
that part out.

> headers.." will be logged all the time.

Will fix as indicated.

> "In a text based log format"

Sure.

> 10 (Nit) bullet one: viewing is mis-spelled

Will fix.

Thanks a lot for the close read, Peter.

Ciao,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 16 Jun 2010 07:25:54 -0400

Hi Vijay,

A few follows ups inline...

Peter

> header line.)  Unless others have a different opinion, I will do

Actually I was thinking lower tech. than that. I was thinking about
recording how the packet was sent or received by the stack and not
referring to Via's at all.
> think there is a harm to prescribe an ordinal location of the
I agree and I want to maintain the order. I just think that's in the
domain of the log format doc and not the problem statement.

> messages until we have a final response will not work for SIP.
Sorry, my comment was not very clear. I agree with the above.

All I meant was that I would like to see each log line have the same
canonical form. So a request has a - for the response code (but it is
present as a field). Actually I think this probably belongs in the log
format drafts - since it may apply more to the text format than the
ipfix format.