RE: draft-shafer-netconf-syslog-00.txt

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

Phil,

> >RFC 3164 and syslog-protocol both list names (e.g. 
> "authorization" and
> >"emergency") as well as integer numbers for PRI contents. 
> However, only
> >the integers are normative (see ABNF in syslog-protocol, PRI 
> description
> >in RFC 3164). It has also been observed in practice that the 
> names are
> >not without ambiguity. So I strongly suggest to use the 
> integer values
> >only in netconf-syslog filters. If there is no consensus on this, I
> >propose to support both the names as well as the numbers.
> 
> I strongly dislike using numbers, but if there's consensus
> to use them, I'll survive.

I understand your position. At a minimum, I strongly suggest that you
allow either numbers or names. I think most of the filter data is
operator-entered, so it is left to the operators decisions what to use.
This is especially important when different syslog message sources use
different names (though this could be handled by the gateway
exclusively).

> 
> >Remotly Received Events 
> >From my understanding of netconf-syslog, a netconf-syslog server
> >supports forwarding via netconf both locally generated 
> syslog messages
> >as well remotely received ones. I think the ability to 
> process remotely
> >received messages is a vital asset. It enables a 
> netconf-syslog server
> >to act as a hub/gateway to a number of netconf-unaware 
> syslog clients.
> 
> The target audience for NETCONF (network service providers) don't
> configure their boxes to forward syslog messages.  These devices
> are the source of events and operators dislike having open ports
> on their boxes that aren't strictly required.
> 
> But I can see the utility of this for other environments and
> the cost is minimal, so I'd consider rolling it in, except....
> 
> >When multiple host message may be present in a single netconf-syslog
> >stream, it might also be that different VERSIONS of the 
> syslog protocol
> >be present in a single stream.
> 
> ... this sounds like it will be an issue.  Can we avoid mixing
> VERSIONs in a single stream?

Let me ask where you see an issue with multiple versions. For me it
seems fairly easy to support them. I've also thought a little more about
the local environment. I think there is no way you can guarantee that
even a single machine will provide consistently one message format
version or the other.

Reasoning: The diagram in 2.1 of netconf-syslog precisely describes how
the syslog subsystem works in many environments, namely Unix and Linux
based systems. The syslog daemon is not the actual message generator. In
fact, it is more like a relay. From the on-the-wire point of view, it is
the initial sender. But if you think about local API, it is just a
receiver forwarding (and potentially transforming) messages. The actual
message generators are system components (called c1, c2, .... cn in your
diagram). These components generate messages via API calls. The API
covers only very limited syslog header fields. Most of the header is
generated by the *system component*. So you are actually not dealing
with a single syslogd and its format but with a potential myriad of
different components on the box. This has been identified as a major
issue moving legacy (rfc 3164) syslog to a standard (syslog-protocol).
This is also one reason why there are so many different formats.

In order to guarantee a consistent data model, you would need to change
the (POSIX) logging API. As this change can not be done evolutionary (it
would break existing apps), the old API would still needed to be
supported. It is thought in the syslog WG that that API change should
happen some time. But we are definitely some years away from that. Not
to mention how long the old API will be utilized...

So my firm believe is that it will be the absolutely common case for
syslog implementations to have to deal with different message formats.

Much of the evil in that can be avoided, if a syslog data model is
defined. This, together with transformation rules, would make it very
easy to handle different versions. As I have written in another mail
this morning, syslog-protocol has such a data model "on its mind" but
can not spell it out because the syslog WG is not chartered to do that.
But it is fairly easy. I have also a working proof-of-concept
implementation of the most important transformations in actual software
(www.rsyslog.com). Its fairly easy to extend that to a full data model
transformation.

> 
> >"The SYSLOG protocol lacks security and reliability."
> >This is not true. There is RFC 3195 (syslog over BEEP) which supports
> >security and reliability. 3195 is currently only weakly accepted, but
> >there as some implementations of it. I suggest a reference is made to
> >3195 to clarify on that issue (and so that a casual reader 
> will become
> >aware that there is more to look at then 3164 and syslog-protocol).
> 
> The target of this comment was 3164, since 3195 doesn't seem to
> have been picked up by the operator community, but I'll add a
> reference to 3195 and clarify my comment.

I agree that 3195 is not overly successful ;) However, you never know
what the future has in stock. As there is no additional effort to
supporting 3195 in netconf-syslog, I think it would be useful to mention
it and to also mention that it can be used together with netconf-syslog
(it is VERSION 0 format, just like 3164).

Rainer

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>