I agree with Tom that the draft - at least IMHO - does not promote or
strongly encourage reliable logging.
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.
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
situation, however, a reliable syslog protocol has advantages. We can
not accidently loose messages. The application must actively discard
them. Which in turn means the application *knows* that messages have
been discarded. It can convey that information to the other syslog
applications it is talking to. In contrast, by using UDP messages get
dropped and nobody knows.
To prove my point, my open source syslog pet rsyslog has implemented
active message discarding in case it would need to block (at least in
single-thread mode, with multiple threads discarding occurs only after
the queue space is used up). This was implemented because there is a
real-world need for it. But this is application design, not protocol
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?
Rainer
-Original Message-
From: Tom.Petch [mailto:[EMAIL PROTECTED]
Sent: Monday, February 05, 2007 8:06 AM
To: Harald Tveit Alvestrand; ietf
Subject: Re: draft-ietf-syslog-protocol: Reliable deliveryconsidered
harmful.
inline
Tom Petch
- Original Message -
From: Harald Tveit Alvestrand [EMAIL PROTECTED]
To: David W. Hankins [EMAIL PROTECTED]; ietf@ietf.org
Sent: Sunday, February 04, 2007 9:43 PM
Subject: Re: draft-ietf-syslog-protocol: Reliable delivery considered
harmful.
Daring to rush in without having read the documents
it seems to me that somewhere one needs a NOTE, something along the
lines
of:
NOTE: In some situations, for instance when a destination disk is
full or
damaged, a syslog facility may be unable to process all messages,
despite
the message transport being reliable. In such a case, it is
reasonable for
the logger of a message to have the option of either not logging
more
messages or ceasing its own operation. This document does not
specify which
option to take.
Or words to that effect.
Harald
Harald
It might be worth reading the I-D:-)
I am not clear which piece of text in the I-D provoked the original
comment. I
do not see the I-D recommending reliable transport, with all the
problems that
have been identified with that. Rather, under security, the I-D
points out that
with an unreliable transport, losing critical messages may adversely
impact
operation.
It then goes on to say
It may be desirable to use a transport with guaranteed delivery to
mitigate
congestion. It may also be desirable to include rate-limiting
features in
syslog senders. This can reduce potential congestion problems when
message
bursts happen.
I find it hard to square this with the original statement that
'draft-ietf-syslog-protocol-19.txt recommends using a reliable
protocol'
If we were to put in a comment about reliable transports introducing
problems
with blocking, then I think that that should be in an I-D which
specifies a
reliable transport, eg the soon to be completed one on TLS (there are
no plans
for one with TCP).
Tom Petch
--On 2. februar 2007 09:59 -0800 David W. Hankins
[EMAIL PROTECTED]
wrote:
On Fri, Feb 02, 2007 at 08:31:49AM +0100, Stephane Bortzmeyer
wrote:
Wether it is a bug or a feature depends on your requirments. On
some
high-security environments, people prefer to suspend the service
rather than not being able to log it. (Otherwise, an attacker
could
easily attempt many attacks, fill in the hard disk and then
perform
the real attack unlogged).
I'd just like to point out that you're choosing one bug over
another. A DOS in preference to lack of observance of events.
In my opinion, that's a bad selection, but it's your selection to
make.
That kind of preference, that kind of choice, is a good thing to
have, but it would be unwise to apply to the general case a
