Re: [netmod] Fwd: draft-wilde-netmod-syslog-model-02 - some initial comments

["Clyde Wildes (cwildes)" <[e-mail]>]

Rainer,

Thanks for your review.

I agree that we should limit the scope of this effort to syslog originators, and treat syslog servers as a separate effort.

We will review the rsyslog implementation to learn about the additional actions, and the extended message filtering implementation.

Thanks,

Clyde

From: Rainer Gerhards <[e-mail]<mailto:[e-mail]>>
Date: Friday, August 1, 2014 at 11:01 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [netmod] Fwd: draft-wilde-netmod-syslog-model-02 - some initial comments


Sorry, typo in mail address. ..

Sent from phone, thus brief.

---------- Weitergeleitete Nachricht ----------
Von: "Rainer Gerhards" <[e-mail]<mailto:[e-mail]>>
Datum: 31.07.2014 18:44
Betreff: draft-wildes-netmod-syslog-model-02 - some initial comments
An: <[e-mail]<mailto:[e-mail]>>
Cc:

Hi list,

Juergen and Tom asked my to have a look at this effort. It's very useful for syslog, so I am happy to see it.

Due to my upcoming vacation I could only have a quick initial read at the doc, but I thought I provide some feedback.

As the document says, it has a least common denominator approach, which probably is good (I have not yet checked the extensibility options). However, to me it looks like it primarily addresses syslog clients, and much less the servers.

As you may know, I am the author of rsyslog and also involved in WinSyslog. I know syslog-ng good enough to see some similarity in both configuration methods (I have also notified the syslog-ng guys, so they may chime in -- or they actually already have).

Today's syslogd's have become quite complex, and I know of almost NO enterprise deployment that can go along with simple PRI (facility&severity) based filters. There are also many more destinations (or "actions" as called in rsyslog) as well as log targets. A quick overview of rsyslog's config data model is in [1], it may be interesting to see some of the more verbose config methods. Out of them, especially the scripting-like features are important and very frequently used in enterprise deployments.

>From what I understand from netmod-syslog-model so far, it could be used to configure low-end rsyslog instances, especially in SOHO environments. But enterprise operators will probably not be able to actually use it. I would assume the same is true for syslog-ng and many other syslog servers.

Thus I think the scope must be well defined. If the target is primarily message originators, that's definitely something that matches commonly used config options AND is extremely useful in enterprise deployments.

IMHO, the doc should be limited to that scope, and maybe another one for syslog servers. It could be based on the "originator model", but needs heavy extensions. I would strongly suggest not to aim for both in a single document.

Besides fine details which I could not yet check, the document looks very well and usable to me for the originator case.

I hope these comments are of some value for the WG. I am now subscribed and will follow any responses. Just note that I am on vacation and so I may respond a bit sluggish.

Rainer