RE: [logs] Syslog payload format

rgerhardsat_private

Frank,

> However I've been thinking about this a bit more, and as a 
> previous poster commented the payload format is just syntax. 
> The syntax is obviously needed and does matter, but it's not 
> really the first thing to consider, the content is.

Agree - there are two issues - the semantic and the syntax. I think I
have badly labled those in my original posting. 

However, I think we can start with either one first - having the
semantic togehter without the syntax does help not more than having the
syntax without the semantic...

> 
> What is needed in the first place is pretty simple, it's an 
> API that includes at least this:
> 
>    log(event);
> 
> Where 'event' is an event object, or something like a 
> 'struct' if you're a 'C' programmer.

I don't fully agree here. If struct means a fixed set of properties, I
oppose it. I think the set should be extensible as there is need for an
extension in new devices we don't even imagine now. But of course, there
are many things can be kept in common. Even a few things would help and
I think the things that WELF has already in it are definitely needed.

> So the first question is what does an event consist of? 
> Things like generation time, event id, priority, source, 
> human readable message, forwarding trail, maybe some 
> application-specific payload, what else? It's easy to come up 
> with a long shopping list, but what are the basics that 
> people could agree on, and which are optional and which are mandatory?

I fear if we do it too right ;) we will be down the IDS WG and SNMP
(oops, forgot to mention that in my original post...) way. I am looking
for a pragmatical solution to be seen quickly. This is why I was
specifically asking if there are other implementors around that would
actually support it...

> 
> Once you know the content of the object/struct, you can then 
> worry about getting it from A to B, and safely tucked into 
> some log or other.
> 
> In fact the format that goes on the wire is going to be a 
> fairly mechanical serialization of the event object. The 
> serialization format could be any of a number of well-known 
> options, and the details don't really matter much as long it 
> meets basic criteria such as (a) flexible/fixable, (b) 
> easy/quick for clients to emit, (c) somewhat human-readable, 
> (d) easily/quickly parsed,
> (e) reasonably efficient in space terms, or at least compressible.
> 
> [As an aside, anything you come up with will likely have an 
> obvious XML equivalent, but that doesn't mean XML needs to be 
> the on-the-wire format (although that or an XML subset is an 
> obvious choice to consider).]
> 
> The protocol itself is basically a remoting of the log() 
> call. Again, various options for that, including RFC3195.

Agree on that - my point is just that I would like to get it
dumbs-simple and easy to implement. Not the perfect solution, but good
enough to bring us some value for the next few years - *now*...

> 
> Indeed if you had something like Java RMI, CORBA or SOAP at 
> your disposal (not that I am suggesting any of these as the 
> way to do it), there'd be nothing at all to do but define the 
> API & crank the handle to make it remotely accessible.

Well... A little bit of discussion on the struct to reach consensus will
eventually be involved ;)

Rainer
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis