Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents,

[Juergen Schoenwaelder <[e-mail]>]

On Sun, Jan 25, 2009 at 02:17:40AM +0100, Juergen Quittek wrote:
 
> Below please find a review of draft-schoenw-syslog-msg-mib-01.

Thanks for your detailed and helpful review.
 
> 1. Section 4, line 1:
>    Why do you consider only the conversion of received SYSLOG messages
>    to entries in the SyslogMsg tables? If you report log messages
>    concerning the host of the syslog MIB module, couldn't it also make
>    sense to directly generate table entries for local log messages
>    without sending messages using the SYSLOG protocol to a local
>    SYSLOG receiver and converter?
>    If it does not make sense, it may be worth clarifying why.

My understanding is that the SYSLOG protocol itself does not discuss
any forms of "local" or "direct" SYSLOG message delivery. On most Unix
systems, even locally generated SYSLOG content is usually send via
some local communication path to a SYSLOG daemon. So there is not
really a distinction between messages originating form the local
system and messages originating from remote systems. While it might be
possible to add a sentence that implementations may bypass the
generation of messages, I am not sure this is needed (you can always
implement things in whatever way you like as long as it shows the
right behaviour) and I am also not convinced this is necessarily a
good idea to do. So for now, I have made no change.
 
> 2. Section 5, paragraph 2, line 8:
>    I am not sure it is really "needed", because requirements for this
>    MIB module are not elaborated to that detail. I would suggest
>    "needed" -> "provided".

OK

> 3. Section 6:
>    It would be nice to have a text section before the MIB definitions that
>      - gives an overview of included groups and tables
>      - describes the mapping of SYSLOG messages to tables
>      - gives and example of representing structured data (SD) in the
>        syslogMsgSDTable, particularly including a case of an SD element
>        having more than one parameter

I have added text and examples; please check the upcoming revised ID.

> 4. syslogMsgTableMaxSize, DESCRIPTION clause, lines 2-3:
>    "A particular setting does not guarantee that much data can be held."
>    is a foggy phrasing. What does it mean? Do you want to say that
>    it cannot be guaranteed that there may not be sufficient memory
>    available for the maximum number of table entries indicated by this
>    object?

Yes. I will change the wording to make this clearer.

> 5. syslogMsgTableMaxSize, DESCRIPTION clause, paragraph 2, line 1:
>    "changes" -> "reduces"

OK

> 6. syslogMsgTableMaxSize, DESCRIPTION clause, paragraph 2, line 2:
>    What is the "oldest" syslog message? The one that is in the
>    syslogMsgTable for the longest time. The one that was received
>    by the SYSLOG receiver the longest time ago? The one with the
>    oldest timestamp? In the last case: What if there is not timestamp?
>    The SYSLOG protocol specification says that the timestamp is optional.

New text:

        If an application reduces the limit while there are syslog 
        messages in the syslogMsgTable, the syslog messages that are 
        in the syslogMsgTable for the longest time MUST be discarded 
        to bring the table down to the new limit.

> 7. syslogMsgFacility, syslogMsgSeverity:
>    Wouldn't it be useful to add a reference to section 6.2.1 of
>    draft-ietf-syslog-protocol where the semantics and encoding of these
>    objects is described?

Added REFERENCE clauses.
 
> 8. syslogMsgVersion, DESCRIPTION clause:
>    Why do you need a value indicating that the version is unknown?
>    Your assumption in section 4 is that all entries come from a SYSLOG
>    to SNMP converter. In the SYSLOG protocol the version number is
>    mandatory. Thus it would always be known.

This covers the case where an implementation also traditional SYSLOG
messages where a version number might not be known.

> 9. syslogMsgTimestamp:
>    The timestamp is optional in the SYSLOG protocol. You should specify
>    an encoding of an unknown timestamp.

Good catch. I clarified that implementations use '0000000000000000'H
for unknown timestamps.

> 10. syslogMsgHostName, syslogMsgAppName, syslogMsgProcID, syslogMsgMsgID:
>    Also for these objects it would be helpful to add a reference to
>    Sections 6.2.4, 6.2.5, 6.2.6, or 6.2.7, respectively of
>    draft-ietf-syslog-protocol

OK
 
> 11. syslogMsgMsg, syslogMsgFlags:
>    Can you always know if a SYSLOG message has been truncated?
>    What if it has been truncated already by a SYSLOG relay?

The syslogMsgFlags description says that the truncated bit is set
"if the converter had to truncate the message". I will clarify the
description of syslogMsgMsg to make this perhaps a bit clearer.
 
> 12. syslogMsgMsg, DESCRIPTION clause, line 6:
>    "truncated" -> "truncated by the SYSLOG to SNMP converter"?

OK

> 13. syslogMsgMsg:
>    Would't it be helpful to have a (read-only) object in the
>    control group called syslogMsgMaxMsgSize?

This is a good question. I personally believe such an object is
useful. At the same time, I am not convinced this MIB module is the
right place to define it. Well, it depends on what the semantics
are. If it reports a limit imposed by the converter, I am fine. If the
idea is to report the limit imposed by a SYSLOG transport or SYSLOG
application, I believe this belongs into some other MIB. Perhaps you
can make a more concrete proposal?

> 14. syslogMsgFlags, DESCRIPTION clause, one but last line:
>   "truncted" -> "truncated"

OK

> 15. syslogMsgNotification, DESCRIPTION clause, last line:
>    Can you give a reference to a description of notification message
>    constraints? 

Unfortunately, the SNMP message size constraints and how they are
dealt with in SNMPv3 is spread over several SNMP specifications. So I
am not sure which reference to add. Do you have a proposal?

> 16. syslogMsgReadOnlyCompliance, OBJECT syslogMsgEnableNotifications,
>    DESCRIPTION clause, second sentence:
>    What do you mean with "to be useful"? The MIB module can even be
>    useful without sending notifications.

I have removed this sentence.

> 17. syslogMsgSDGroup, DESCRIPTION clause:
>    the group contains just a single object. Do you really want to call
>    this a "collection of objects"?

I am planning for extensions. More seriously, I do consider the INDEX
objects listed in comments as part of the group. It is an strange
artefact of the SMIv2 that they cannot be formally included.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
OPSAWG mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsawg