Subject: RE: [Syslog] plain tcp syslog

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Tue, 18 Oct 2005 00:39:55 -0400

Rainer:

Just my 2 cents...

I am not in favor of informational RFC describing some behavior "as seen in the wild". If you want to create a standard - that's a different matter.  But an informational RFC just clouds the water because it makes an appearance of describing a standard, while not really making any standard.   

This has been a point of major confusion around syslog RFC 3164, for example.  I have personally had to explain over and over to a lot of engineers/managers that it is not a standard and "compliant" implementation can send petty much anything yet claim consistency with that RFC. That's what you end up with when you don't have strict requirements in the RFC.  

Thanks,
Anton. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Monday, October 17, 2005 8:49 AM
> To: [email-masked]
> Subject: [Syslog] plain tcp syslog
> 
> Hi WG,
> 
> Chris has put some questions about RFC 3195 usage on the 
> agenda for the next IETF. In preparation for this, I am going 
> to ask a question that I know is very unpopular in the WG.
> 
> We have discussed the issue of a very-simple, non-BEEP based 
> plain tcp syslog several times on this list. The idea always 
> has violently been rejected.
> 
> However, the current status is that RFC 3195 is nicely 
> standardized but seldomly implemented and even less often 
> deployed. Plain tcp syslog, on the other hand, is not 
> standardized but widely deployed. It is implemented at least in:
> 
> - syslog-ng
> - rsyslog
> - Kiwi syslog daemon
> - WinSyslog/MonitorWare Agent/EventReporter
> - Cisco PIX
> 
> As of my experience, many syslog-ng installations use plain 
> tcp syslog.
> All of the implementations listed are interoperable. The list 
> is most probably not complete, these were just the products 
> that came immediately to my mind. The end user-base is also 
> continously asking about such a simple transport - this is 
> probably why it is implemented so often.
> 
> Given the obvious importance of this protocol, wouldn't it 
> make sense to at least document its observed behaviour, much 
> as RFC 3164 documents UDP based syslog observed behaviour? 
> Such a document could also be useful to document the security 
> and (un)reliability issues coming along with the "plain tcp" 
> syslog. Eventually, this could even increase demand for more 
> reliable solutions like RFC 3195.
> 
> Feedback is appreciated.
> Rainer Gerhards
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

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

---

From: Darren Reed <[email-masked]>
Date: Wed, 19 Oct 2005 00:12:52 +1000 (EST)

[ Charset ISO-8859-1 unsupported, converting... ]
> Rainer:
> 
> Just my 2 cents...
> 
> I am not in favor of informational RFC describing some behavior "as
> seen in the wild". If you want to create a standard - that's a different
> matter.  But an informational RFC just clouds the water because it makes
> an appearance of describing a standard, while not really making any
> standard.   

Good, so you don't have any technical problems with doing it.

> This has been a point of major confusion around syslog RFC 3164, for
> example.  I have personally had to explain over and over to a lot of
> engineers/managers that it is not a standard and "compliant"
> implementation can send petty much anything yet claim consistency with
> that RFC. That's what you end up with when you don't have strict
> requirements in the RFC.  

Have you also mentioned to your engineers/managers that all of the
Cisco devices, for years and years, were RFC 3164 compliant ?

Or that this RFC documents an otherwise undocumented protocol that
they have been implementing for years ?

What you're describing are organisation problems and not the domain
of this working group to solve.

Darren