[sip-clf] WGLC: SIPCLF Problem Statement (draft-gurbani-sipclf-problem-statement-01)

[Cullen Jennings <[e-mail]>]

Some random comments - all sent in my individual contributor role.

I like this draft, think it is fine work, but it needs a few more things before it is done. These are all things that I think can help us speed up the actual clf work if we can agree on them.


Section 8 should be renamed to "Information Model"

remotehost does not seem like enough info when talking about multi interface machines like SBC with insides and outsides. I would prefer to replace this a source and destination address that contains the IP and port of both the source and destination of whatever was in the layer 3 transport protocol. 

I'd update the method and status to make it clear  that there must be exactly one of a request method name, or a response code 

I would separate the to and to-tag to two separate elements. You want to be able to match the to search the to without including the to-tag in a rapid way. I don' feel strongly about this and can live with them mixed together in one field if that what folks want. 

I'd remove the contact list. It's just a generic header like others. This is debatable so worth discussion but I'm in the "less not more" camp

server and client transaction both need to be optional. For example, a stateless proxy will not have this.

Explicitly state that there all other headers go in an order list of pairs of header field names and header field values

A field to hold one optional body

I don't think this information model need to be extensible. In fact the one thing I am going to continue to strongly argue is that it should not be extensible. Note this does not mean we can not have new sip headers or new body types, we can, they just go in the list of sip headers or body type. 


So to summarize, I think the following need to be the elements of the Information Model,

Layer 3 source IP/port
Layer 3 dest IP/port
Timestamp
server transaction
client transaction
From header field value
To header field value minus the to-tag
to-tag
callID header field value
ordered list of header field name value pairs
status or request line 
message body 

I could be convinced there was value in:

method
sip status code
contact header field value for certain types of messages 
syslog style severity level 

I'm against the needless complexity or arbitrary extensibility and would want to see a good argument made for adding things.  


I would add a data model consideration section where we talk about desirable properties of the data model. We don't pick the data model in this draft, that is the job of  actual spec draft, but we can put requirements or other points about the data model here. 

Specifically in this part I want to make sure we are compatible with the important parts of syslog such that if someone is writing a program to read one of these SIPCLF log files and transmit it over syslog, it is easy and there are no semantic level mapping problems. To do that that I would add to this section "Compatible with the syslog definitions of severity." 

I was considering also saying compatibility with syslog definition of timestamp but my recollection of that (which may be very wrong - been awhile since I looked at it) left me more than a bit confused about syslog tmestamps. It seems that every syslog packet I have ever seen in the wild uses the BSD Syslog timestamp format in RFC 3164 but clearly that is more or less borked for any real correlation across time zones so it seems like 5424 version of timestamp would be better. The 5424 allowed the local offsets which resulted in no real canonical format for time which mean some people implemented the full things and some ignored the local offsets results in interoperability problems. Then there is the "-00:00" offset being something much different than "+00:00". And then there is the leap seconds stuff which is nearly untested as far as I can tell in most products. I really don't understand how one write a 5424 compliant syslog message that occurs during the leap second but I'm probably just confused. What exactly does one do if one wants to write something to a log file when an extra leap second is being added? SIP is using the email style time formats and mandating GMT. That seems pretty trivially translatable into whatever one believes is the right way to do it in syslog so I'd be tempted to just allow SIP implementation use the timestamps they are using for SIP and define that as the data representation for the timestamps. I went to look at stealing the time format from IPFIX but gave up at the point where the 5102 said leap seconds where excluded from the dateTimeMicroseconds but in RFC 5101 it looked like dateTimeMicroseconds included the leap seconds. I like how 5101 uses the NTP stuff - that is very clear to everyone but does not map well to these human readable formats people want to use in the log files. All in all, the email style fixed to GMT in a single canonical format is looking pretty appealing.