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
pgpff530mauYR.pgp
Description: PGP signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf