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 PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Monday, October 17, 2005 8:49 AM > To: [EMAIL PROTECTED] > 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 > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
