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

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Jan 2009 22:26:54 +0100

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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 14 Jan 2009 12:55:08 +0100

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:[email-masked]] 
> Sent: Tuesday, January 13, 2009 11:27 PM
> To: Scott O. Bradner; Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping 
> documents,
> 
> 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
> 
> --

---

From: "David Harrington" <[email-masked]>
Date: Wed, 14 Jan 2009 07:43:40 -0500

There were approximately ten responses from people were are not
editors or ADs that said "yes, accept this". You can see them by
following the link Juergen provided.
 
dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Wednesday, January 14, 2009 6:55 AM
> To: [email-masked]; Scott O. Bradner
> Cc: [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 14 Jan 2009 14:13:15 +0100

Assuming 'accept' also means 'will participate in discussions and
reviews'  I see no problem with the WG adopting this work item. 

WG chairs?

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Wednesday, January 14, 2009 2:44 PM
> To: Romascanu, Dan (Dan); 
> [email-masked]; 'Scott O. Bradner'
> Cc: [email-masked]
> Subject: RE: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping 
> documents,
> 
> There were approximately ten responses from people were are 
> not editors or ADs that said "yes, accept this". You can see 
> them by following the link Juergen provided.
>  
> dbh
> 
> > Are there at least three people who are not editors or ADs 
> committed 
> > to read and review the documents in the WG?
> > 
> > Dan
> > 
> >

---

From: "Juergen Quittek" <[email-masked]>
Date: Wed, 14 Jan 2009 14:23:06 +0100

I will review them.

    Juergen Q.

---

From: "Juergen Quittek" <[email-masked]>
Date: Sun, 25 Jan 2009 02:17:40 +0100

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Jan 2009 00:00:53 +0100

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

Thanks for your detailed and helpful review.
 
>    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.
 
>    MIB module are not elaborated to that detail. I would suggest

OK

>        having more than one parameter

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

>    available for the maximum number of table entries indicated by this

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

> 5. syslogMsgTableMaxSize, DESCRIPTION clause, paragraph 2, line 1:

OK

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

>    draft-ietf-syslog-protocol where the semantics and encoding of these

Added REFERENCE clauses.
 
>    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.

>    an encoding of an unknown timestamp.

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

>    draft-ietf-syslog-protocol

OK
 
>    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.
 
>    "truncated" -> "truncated by the SYSLOG to SNMP converter"?

OK

>    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?

>   "truncted" -> "truncated"

OK

>    Can you give a reference to a description of notification message

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?

>    useful without sending notifications.

I have removed this sentence.

>    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

---

From: Rainer Gerhards <[email-masked]>
Date: Fri, 30 Jan 2009 12:55:22 +0100

Hi Juergen S. and Q.,

I have not yet commented because I was unsure whether or not the draft
will be adopted. Anyhow, at least one point I would like to add.

> good idea to do. So for now, I have made no change.

I concur to Juergen S' point of view. In the real-world *nix use case
(the dominant scenario) almost all messages are not generated by the
syslog subsystem itself. Typically, there is a single startup and
shutdown message emitted by the syslog subsystem and maybe a finite
number of error messages concerning the configuration. In contrast,
the syslog subsystem processes an infinite number of messages it
receives from various sources. Note that "local" delivery, in the
real-world-scenario, means that an application (e.g. mail mta) creates
a log record and submits it via a local communications channel to the
syslogd, which then (locally) receives the message.

Of course, there are some other (less dominating) real-world scenarios
where the application emitting a message is actually the original
creator of its content. However, if that application is capable to
send snmp notifications, why should it model a syslog-type snmp
notification and not native format? The only reason I can think about
is that it expects that the snmp receiver actually is interested in
syslog message and thus uses the notification only to tunnel that
message. That use case, IMHO, is not a valid one. In such a case, I'd
prefer to see the originator to emit a native snmp notification and a
converter on the receiving end converting that to syslog format.

So my conclusion is that there is no need to support direct generation
of syslog-type snmp notifications without receiving a syslog message
first.

Rainer

---

From: "David Harrington" <[email-masked]>
Date: Fri, 30 Jan 2009 10:00:53 -0500

Hi,

> >    draft-ietf-syslog-protocol where the semantics and 

Note that, per syslog WG consensus, syslog-protocol 6.2.1 does not
define normative values for facility and severity, but the TC-MIB
defines normative mappings between labels and values which represent
facility and severity, for use in MIB modules. I suggest the reference
be the document containing the SYSLOG-TC-MIB, rather than the protocol
document, since these objects use the normative mappings from the TCs.

Most syslog documents have been through auth48 and are awaiting
resolution of the 5378 mess. The RFC #s are:
5424	protocol
5425	tls
5426	udp
5427	SYSLOG-TC-MIB

> am not sure which reference to add. Do you have a proposal?

How about:
"Implementations may truncate the
          message part of the syslog message such that it fits into
          the size constraints imposed by the implementation
environment
          and the notification message size constraints imposed by
          maxMessageSize [rfc3412] and SNMP transport mappings."

David Harrington
[email-masked]
[email-masked]
[email-masked]