2002-12-20T15:45:47 Christopher Lonvick: > - there are many tcp-based implementations to transport syslog but none > of them interoperate
I'm not as sure about that. It's possibly the case that not all of them interoperate, but I'd expect most of them to; about the only "interesting" question I can see affecting interop is whether the records within the TCP stream are delimited by cr, crlf, lf, or some prefix-count mechanism. I'd expect most implementors to terminate with lf or crlf when writing; a tolerant listener could terminate on lf and strip any trailing cr found. > - a simple tcp-based implementation would need all of the aspects of > BEEP to optionally call the security features that are desired > (reliable transport, confidentiality, device authentication) Some of us feel that a simple tcp-based implementation can be provided with such features on an as-needed basis with external TLS implementations. There's much dispute about that. > - BEEP channels can be a good thing Another disputed topic. > I'm still not seeing what features/functions are missing from 3195, or > what features/functions a simple tcp-based syslog would fill. I believe this discussion thread arose when a syslog implementor asked if anybody knew of a library implementing BEEP that would address problems he was having; I don't recall hearing an answer. There are heavyweight library implementations with various problems he described, that's he's trying to work with. It's been asserted here that a very lightweight subset-of-BEEP could be easily implemented, and would suffice for an RFC 3195-compliant implementation. > I'll keep this discussion open to see if we can get a clear reason > for a simple reliable tcp protocol. I think the concept offered was that BEEP may or may not be the only Proper Way to implement any protocol in the future, but if so it appears to be remaining in the future; for the present, an intermediate step specifying TCP transport for syslog without adding multiplexed MIME streams may be helpful. I think the next step we need is to survey existing sylog-over-tcp implementations and see who is terminating their records how, and what sort of interop (if any) is available. -Bennett
