Nicolas Williams wrote:
On Fri, Jun 09, 2006 at 05:53:17PM -0400, James Carlson wrote:
Oh! Well then... But those deal in structured data also...
It's a bit different in that you have to specify enterpriseId in order
to get to a parsed message content, as opposed to just meta
information. The rest seems (at least to me) to be just syslog in
slightly newer clothes.
If someone actually _does_ define a structure using enterpriseId on
Solaris, then I have the same objections. Doesn't stop others on
other platforms from pursuing that rabbit, though.
I'm afraid we do need a secure transport/relay for structured,
optionally signed data. And a queryiable DB store would be nice too.
Perhaps we'll end up with multiple protocols. That may be the answer.
But a single protocol is likely to be seen as better by integrators,
etc... Less stuff to analyze, plug-in with, etc...
I would prefer a single protocol.
The first new protocol the syslog WG came up with is in RFC3195,
I believe and uses BEEP. This provided reliability, etc. It's a
very complicated protocol that hasn't found a lot of traction.
The group is now looking at defining other, simpler, protocols
to provide reliable/secure transport and also ones that use
structured data.
So yes, we will end up with multiple syslog protocols. It is
important to note that the protocol definitions are now being
developed independently from how they are transported.
But it is importrant to realise that the work so far has been
around the syslog protocol(s), *not* what gets stored in the
log files by syslogd. syslogd is free to ignore structured
data or to interprit it in some way and create unstructured
log file entries.
In the past syslog has just dumped an almost raw version of
the message received into its log file. This project does
not propose to change this behaviour.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
