Re: Alternate CLF syntax proposal

[Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx>]

Actually, ya know we can combine this with something like Adam's draft.
If you take the pcap entry format, and encode a "log" entry with the following header:


|   0    |   1    |   2    |   3    |   4    |   5    |   6    |   7    |
-------------------------------------------------------------------------
|                           seconds                                     |
-------------------------------------------------------------------------
|                         microseconds                                  |
-------------------------------------------------------------------------
|                           saved_len                                   |
-------------------------------------------------------------------------
|                           orig_len                                    |
-------------------------------------------------------------------------
|                           all 0x00                                    |
-------------------------------------------------------------------------
|             0x00                  |     0x0800      |    0x4500       |
-------------------------------------------------------------------------
| log_entry_len   |    seq_no       |        0x000001         | 0x11    |
-------------------------------------------------------------------------
|                              all 0x00                                 |
-------------------------------------------------------------------------
|      0x00       |    0x0715       |    0x0715       |  entry_len      |
-------------------------------------------------------------------------
|      0x00       |  0x04  | 0x00   |      tot_len    |     0x0000      | 
-------------------------------------------------------------------------
|            all 0x00                                 |   BEGIN         |
-------------------------------------------------------------------------

Then starting with the BEGIN bytes, you can record each Tag-Length-Value triple using the following:
1-Byte Type
1-byte Length (including type and length bytes)
1-255 bytes of chars

And once again there would be plenty of tools/running-code which can already parse that today.  :)

Or we could do a slightly different variant of the "header", if you want TLV's which can be bigger/longer.

-hadriel

> -----Original Message-----
> From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf
> Of Hadriel Kaplan
> Sent: Thursday, March 26, 2009 3:57 PM
> To: Vijay K. Gurbani; Adam Roach
> Cc: sipping WG; draft-gurbani-sipping-clf@xxxxxxxxxxxxxx
> Subject: Re:  Alternate CLF syntax proposal
> 
> 
> If the purpose of it is troubleshooting, or threat analysis type stuff, I
> think the following format satisfies the needs as well:
> http://wiki.wireshark.org/Development/LibpcapFileFormat
> 
> The advantages:
> 1) There's running code
> 2) There's open source, on all operating systems, and also for commercial
> use
> 3) It's used by many people
> 4) There are many tools which accept/process it
> 5) It's fast to write/save
> 6) It supports a sub-second timestamp
> 7) It supports length encoding of packets, so you can skip past them
> 8) It supports truncated saving of packets, so you don't have to save all
> of very big ones
> 9) It records the method name or response code very early in the saved log
> entry for each packet
> 
> Disadvantages:
> 1) Nothing much new to specify, except to document it?
> 2) It's a little tricky for SIP/TLS, where you basically have to create
> fake segments/packets for the low layers, and same may be true for SIP/TCP
> depending on when you record the log
> 3) It doesn't provide a way to report internal system events/actions/info
> (although we could fix that)
> 4) Afaik, there is no specific remote push/streaming mechanism for it
> defined (there was an attempt at it, but not final)
> 
> -hadriel
> 
> > -----Original Message-----
> > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On
> Behalf
> > Of Vijay K. Gurbani
> > Sent: Wednesday, March 25, 2009 10:58 PM
> >
> > Adam Roach wrote:
> > > In the spirit of "send text," I've put together a straw-man proposal
> for
> > > an easy-to-generate and fast-to-process extensible format for saving
> SIP
> > > log messages:
> > >
> > > http://www.ietf.org/internet-drafts/draft-roach-sipping-clf-syntax-
> > 00.txt
> > [...]
> >
> > Adam: Essentially you are advocating for a table-of-content
> > type of approach where you read the ToC and index straight
> > to where you want to go.  I have worked on SIP parsers
> > designed this way.
> >
> > The parsing is optimized, yes, when compared to the ASCII
> > version -- though perl can do wonders, but not to outperform
> > binary parsing.  The disadvantage is that you loose readability
> > and would need specialized tools to, say, grep through such
> > a file.
> >
> > It will be interesting to see what others think...
> >
> > Thanks,
> >
> > - 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/
> > _______________________________________________
> > Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
> > Use sip@xxxxxxxx for new developments of core SIP
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
> Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP