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

[Rainer Gerhards <[e-mail]>]

Sorry, typo in mail address. ..

Sent from phone, thus brief.
---------- Weitergeleitete Nachricht ----------
Von: "Rainer Gerhards" <[e-mail]>
Datum: 31.07.2014 18:44
Betreff: draft-wildes-netmod-syslog-model-02 - some initial comments
An: <[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