Rainer,
If that is consensus, we can add the statement "the handling of
non-compliant messages will be implementation dependent" which very
precisely describes the list consensus.
I will not have problems with that. The document needs to have
some statement like the above for completeness.
As for the MIB I will reword the two statistics like
syslogEntityOperationsMsgsMalFormed
DESCRIPTION:
"The number of messages received by the syslog
receiver which had malformed headers."
syslogEntityOperationsMsgsDiscarded
DESCRIPTION:
"The number of messages that were discarded by the
syslog receiver. This will include messages that
were discarded because the message size was greater
than the system's maximum message size."
That still leaves one question unanswered:
Sec. 6.3 A receiver MAY ignore malformed STRUCTURED-DATA
elements.
Doubt: But in sec. 6.4 Example 4 of a malformed
STRUCTURED-DATA element the document says ...
"the receiver MAY discard this message".
Is the malformed STRUCTURED-DATA element ignored or the
message as a whole is ignored?
Finally, a comment:
The
reason was always that MUSTs here are not actually needed
to ensure interoperability.
if the MUST specifications are not a must for interoperability
then don't the MUSTs sound like an overkill ? Would "SHOULD"
be more appropriate? I understand that it is too late to ask
this question, but the quote above puts the MUSTs in a new
perspective. If this has been discussed and agreed upon, then
I have missed the discussion and I will withdraw the comment.
Glenn
Rainer Gerhards wrote:
Hi Glen,
thanks for the message. Let me start on an overview level: if you look
at the evolution of the draft, you will see that earlier versions were
quite specific on what to do if the message was malformed. However,
based on dicussion, one after another of these rules were deleted. The
reason was always that MUSTs here are not actually needed to ensure
interoperability.
You can get a glimpse of this discussion by looking at
http://www.syslog.cc/ietf/why-indepth.html
This is a very old page. For more recent samples, you should consult the
mailing list archives. There are (too) plenty samples of this being
discussed to point to anything specific.
The bottom line behind the current draft is that we do not necessarily
specify what happens if the message is malformed. This is not vital for
interoperability. Also, implementors will provide different solutions
(most probably operator-configurable) to address real-world needs. For
example, we could specify that a message with leap seconds in it MUST be
discarded - but if the operator insists that he needs such a message, an
implementor will always create a way to process it.
We are specific on invalid UTF-8 sequences. This must not be
interpreted, because this is a big security issue. However, even than it
might be OK for an implementation to store the invalid UTF-8 sequence.
If that is consensus, we can add the statement "the handling of
non-compliant messages will be implementation dependent" which very
precisely describes the list consensus.
Rainer
-----Original Message-----
From: Glenn M. Keeni [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 12:32 PM
To: [EMAIL PROTECTED]
Subject: [Syslog] Syslog Protocol doubts
Hi,
I have been trying to figure out the error conditions
that a syslog receiver will need to anticipate and the
corresponding actions that it is expected to take. I do
not see this clearly spelt out in the protocol document.
There are several MUST clauses, I understand that a
compliant syslog sender WILL always send messages that
meet the MUST clauses. But the document does not spell
out clearly what a compliant syslog receiver will do
when it gets a non-compliant message. Possible actions
could be:
a. discard whole message
b. discard non-compliant part ( assuming the non-
compliant part can be isolated)
c. rectify the non-compliance e.g.
- truncate message: [this is mentioned in 6.1]
- truncate the long-fields (software,
swVersion etc.)
d. implementation dependent
Is this a problem ? I have listed the MUST conditions
in the attached document. My take is that we may have to
address each one of these. Or we can include a sweeping
statement like " non-compliant messages will be discarded"
or "the handling of non-compliant messages will be
implementation dependent".
Glenn
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
