Quick review: Section 2.3:
It looks like the syslog-ng option is vendor specific. In practice, there are many implementations that interoperate with "plain tcp syslog". At least these I know: Cisco PIX, Kiwi Syslog Daemon, rsyslog, Adiscon MonitorWare, EventReporter & WinSyslog and probably SDSC syslogd (not totally sure about that). Some of them are running on Windows, so the protocol also works cross-platform. Considerations: It should be stated that it sometimes is more desirable to have unreliable delivery. Reliable delivery means that the sender must slow down when the receiver can not process fast enough. There have been reports that such a slow-down might be unacceptable if that means a high-performance application needs to wait for the logging. What is more desirable obviously depends on the actual situation and the operator's choice (and/or legal requirements). Reliable delivery could cause a "domino DoS effect", if the senders block while reconnecting. Popular samples are blocking PIXes whom's syslogd has died. The same can be constructed for *nix systems reporting via reliable syslog to a died central one. In that case, applications (e.g. SMTP MTA) log synchronously to the syslogd, which tries to forward. The local syslogd block. The synchronous logging API blocks shortly after. This results to a standstill of the system as whole. I see this is somewhat covered in 2.16, maybe a pointer would be helpful. Section 2.4 Supported Practices add Tunneling via SSL Current Implementations Using stunnel together with syslog/plain tcp capable applications (e.g. syslog-ng) is common practice. Some samples: http://www.google.com/search?sourceid=navclient-ff&ie=UTF-8&rls=GGGL,GGG L:2006-13,GGGL:en&q=syslog+ssl http://www.stunnel.org/examples/syslog-ng.html http://freshmeat.net/articles/view/1781/ General common on timestamp-related sections: current syslog practice is inadequate. syslog-protocol is trying to fix that. Even after syslog-protocol has become a RFC, inadequate timestamps will stay for a long time IMO. A mitigation is that the receiver records the time of reception. Given a sufficiently fast network, that reception timestamp could be sufficient by itself. It would also be possible to compute a delta between the message and the reception timestamp and try to find a correction factor. I do not know of any effort to try such a thing. Section 2.17.2 I think the first sentence should not read "TCP port numer" but "port number". Syslog usually travels via UDP and only occasionally via TCP (RFC 3195 & non-standard but widespread used plain tcp syslog). Section 3 general comment: current syslog servers "compress" repeat messages ("message repeated n times"). The compression happens at the sender. This is sometimes desirable, but can lead to information loss. I suggest this method is described. Rainer > -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 05, 2006 6:09 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] FW: Initial Logging capabiltiies document > > FYI. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > patrick cain > Sent: Wednesday, July 05, 2006 10:33 AM > To: [EMAIL PROTECTED] > Subject: Initial Logging capabiltiies document > > Hi, > > I promised to get out a version of the logging capabiltiies document. > Since > I missed the initial draft cutoff date, I spent some extra time > flushing it > out. And it is attached. It will go to the IETF repository as soon as > it > re-opens. Please advise me of correction, complaints, and aditions, > and > feel free to spam it others you may know who are into logging. > > I asked for agenda time at the Montreal OPSEC meeting, but I don't > think > this one needs much presenting. > > Pat Cain > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
