Re: [sip-clf] AD review: draft-ietf-sipclf-format-05

["Vijay K. Gurbani" <[e-mail]>]

On 02/09/2012 09:18 AM, Robert Sparks wrote:
> Inline, trimming to points with responses

Robert: Some feedback on your responses inline.

With respect to extending the Transport flag, you wrote that:

> That's a choice the group should make - the document just needs to be
> explicit about what's extensible (for all the fields) and if a field
> is extensible, what the mechanism looks like. For the transport
> field, as an individual contributor, I prefer the IANA registry
> approach.

I agree that IANA is cleaner.  It will be nice if we hear more views
from the WG so we can proceed accordingly.

With respect to replacing tabs with spaces, you wrote that:

> This leaves out optional fields. It's also not clear why you use a SHOULD
> for the requirement over bodies.

I believe that the SIP CLF record will be used as a medium to do a quick
spot check as well as a medium for detailed analysis.

When used as a medium for a quick spot check, I believe that the SIP
CLF record should be amenable to being manipulated by normal Unix text
processing tools.  Thus, those who use the standard Unix command line
text tools to look for something in the SIP CLF log file will be mostly
interested in the mandatory header fields (i.e., grep "2 INVITE" logfile
or grep "S2388-188" logfile to find all records with server transaction
ID "S2388-188").  The result could be piped to tr(1), awk(1), cut(1) or
perl for further processing.  Quick example:

   $ grep "2 INVITE" logfile | cut -f13

will print the server transaction ID (field 13) of all records
where the CSeq field is "2 INVITE".

That is why I think that tabs in the mandatory fields MUST be changed
to spaces.

Exploring the body and optional fields is part of detailed analysis
of the SIP CLF record.  To do this, one would need an actual
SIP CLF reader, which will be presumably more intelligent and does not
need a LWS delimiter to figure out boundaries (it already has the length
of the body or the optional field).

In fact, the more I think of it the more it seems that the SIP CLF
record should really consist of three distinct stanzas, each
separated by a LF:

   Index-pointers 0x0A  Mandatory-fields 0x0A Optional-fields 0x0A

Right now, we separate the SIP CLF record in two stanzas:

   Index-pointers 0x0A Mandatory-Fields-and-Optional-fields 0x0A

The problem with separating the SIP CLF record in two stanzas is
that a "grep S2388-188 logfile" will return the mandatory field
line PLUS any optional fields logged.  These optional fields are
therefore forced to change tab to spaces.  If we have 3 stanzas,
then the optional fields can retain tabs.

Regarding the SIP CLF record being syntactically amenable to a parse
by a normal SIP parser, you wrote that:

> I think it _was_ the intent to be able to reuse parser code. Several
> early implementers were handing individual fields to the part of
> their parser that would handle a framed header field.

The distinction being made here is whether individual *fields* in the
SIP CLF record can be extracted and given to a SIP parser that would
normally parse those sequence of strings versus an existing SIP parser
that will successfully parse a SIP CLF record in its *entirety*.

Clearly, the latter is not possible.  The former is a possibility.  To
be safe, the document should indicate that escaping '-' and '?'
may produce a field that is not syntactically parsed by a SIP parser
that would normally be able to parse that field if it appeared
in a SIP header (as opposed to a log file).

Thanks,

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