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 _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
