Subject: [Syslog] syslog-protocol - is it going to be used?

From: Chris Lonvick <[email-masked]>
Date: Mon, 24 Oct 2005 06:05:15 -0700 (PDT)

Hi Folks,

>From the notes I've been getting and the recent discussion on the mailing 
list, I'd like to ask for a sanity check.

1)  Will you (or your organization) be transmitting or receiving syslog 
messages using syslog-protocol as described in the most recent ID?

I got few positive responses the last time I asked this so I'm going to 
ask some questions that I hope will be more directed towards the people 
who are either not going to implement, or who are sitting on the fence.

2)  If you are not going to implement, would you consider doing something 
that would have less of an impact on current transmitters and receivers?
(Such as keeping the start of the syslog message as "<PRI>..." rather than 
"1 888 4 00 ..." .)

3)  Do you like the TIMESTAMP as defined in the current syslog-protocol 
ID?

4)  Do you like the idea of using "structured data" as is currently 
described in syslog-protocol?

Thanks,
Chris

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Tue, 25 Oct 2005 18:11:26 -0400

> 1)  Will you (or your organization) be transmitting or 
> receiving syslog messages using syslog-protocol as described 
> in the most recent ID?

I can't speak to any product road maps or any specifics, but let's just say I have a suspicion that a certain large networking device manufacturer will support syslog-protocol (sending) in majority of its devices by 2006. :)

You may not be hearing lots of feedback on who is implementing this because not all companies like to issue press releases for things that are in development and may get de-committed if project priorities change.

Yes.

Yes. A bit bulky names, but this concept is what's going to make this protocol shine down the road IMO. Now, people would be able to write *standard* log filters/viewers that can do meaningful things. Once people pick up on using this to produce useful structured data in their messages, I think it may change the whole logging landscape for the better. Imagine being able to zero-in on specific flow, device, transaction, component, message name, combination of them, etc.  

Overall, I think this protocol is a great step forward.  From no standard at all to a great standard. Rainer has done a great job on this! I am optimistic about this RFC. 

Thanks,
Anton.