Anton: I agree that an actual standard would be much better. However, I've seen very violent objection on this list against it. So it might be a compromise to create an informational document that at least describes what currently *is* done. It's being implemented and deployed anyway, so documenting it does not hurt. Not documenting it will not stop it from being implemented and deployed, there is simply too much demand in the market and it is working far to well to dump it "just" because it is no-standard (in fact, I think it is already "industry-standard" with the large number of supporters it has).
But let's try again: I suggest that we create a standard-track document on a very simple and not fully reliable tcp based transport in the spirit of what syslog-ng and many others do today. Most probably, it would make sense to create it in the form of a transport mapping, just like Anton's UDP transport mapping. Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 18, 2005 6:40 AM > To: Rainer Gerhards; [EMAIL PROTECTED] > Subject: RE: [Syslog] plain tcp syslog > > 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
