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

["Juergen Quittek" <[e-mail]>]

Dear all,

Below please find a review of draft-schoenw-syslog-msg-mib-01.

The draft is clearly written, well elaborated and already in a
mature state.

Most of the comments I have are editorial, nits, or requests for
clarification.

    Juergen Q.


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.

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".

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

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?

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

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.

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?

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.

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

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

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?

12. syslogMsgMsg, DESCRIPTION clause, line 6:
   "truncated" -> "truncated by the SYSLOG to SNMP converter"?

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

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

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

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.

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



On 14.01.09 12:55  "Dan Romascanu" <[e-mail]> wrote:

> Are there at least three people who are not editors or ADs committed to
> read and review the documents in the WG?
> 
> Dan
> 
> 
>> -----Original Message-----
>> From: Juergen Schoenwaelder
>> [mailto:[e-mail]]
>> Sent: Tuesday, January 13, 2009 11:27 PM
>> To: Scott O. Bradner; Romascanu, Dan (Dan)
>> Cc: [e-mail]
>> Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping
>> documents,
>> 
>> On Mon, Dec 15, 2008 at 03:49:43PM -0500, Scott O. Bradner wrote:
>>  
>>> there was some discussion of the WG adopting the SNMP <-> SYSLOG
>>> mapping documents on the list back in november - at the
>> time there was 
>>> some support for the idea
>>> 
>>> see
>>> http://www.ietf.org/mail-archive/web/opsawg/current/msg00326.html
>>> 
>>> I'd like to see if what level of support there is at this point
>> 
>> May I ask where we are with this? This is now waiting for a
>> decision since the Dublin IETF (about half a year ago)...
>> 
>> Thanks,
>> 
>> /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

_______________________________________________
OPSAWG mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsawg