On Thu, Feb 08, 2007 at 02:32:00PM +0100, Rainer Gerhards wrote: > I also agree with the observation that reliable - and blocking - > logging can cause harm to a system. However, I do not think that this > is anything that the protocol can do something against. It is not the > protocol that causes harm. If we say "if we support a reliable syslog > protocol, we can block the system and thus the protocol is harmful", > we can also say "if we deliver mail messages via a reliable protocol > (SMTP), we can use up all system ressources (e.g. fill the disk), so > SMTP is harmful". RFC2821 (SMTP) defines a queueing behaviour and that servers should retry transmission for "some reasonable number of times at intervals as specified in section 4.5.4." should there be problems at the reliable transmission layer. It seems your example does what the syslog draft does not, so I'm not sure what your point really is. > My point is that we must differentiate between the protocol and its > implementations. A reliable syslog protocol offers the foundation on > which a reliable syslog implementation can be build. It is the task of > the application designer to take care of the operating environment > specifics while implementing the protocol. A good design for Unix will > probably take into consideration that a blocking syslogd does not do > any good and leave options to the operator to discard messages when > needed (and probably have turned them on by default). Even in such a You must differentiate between the protocol and implementation, but not to the extent of denying the implementor guidance on how to proceed in a way that will promote the health of the protocol. The wholesale promotion of reliable transport without the disclaimer that the protocol-level process probably wants to enter into discarding behaviour in effect promotes the unhealthy condition. My hope is that a simple acknowledgement of this evidently common "implementation mistake" would substantially increase the quality of syslog implementations that are updated for it. > design. Think about it: how can an IETF document specify what a > syslogd should do if its sending queue is filled up? How could we word > this so that it becomes part of an on-the-wire protocol? If you were going to update syslog so that it might be transported over a reliable channel, then I think the only right answer is to define how the protocol-level process, independent of which reliable transport is selected, deals with congestion or failure. Barring that, there are many duct tape approaches. Updating the security section to weigh the cons of denial of service against the pros of reliable delivery. Adding a glossary entry for "reasonably reliable", and using such terms instead of the absolute "reliable" as is currently in place. Numerous others. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Attachment:
pgpJsgHbTZ0Xv.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf