Phil, as promised, I have gone through the netconf-syslog draft from the syslog guy's perspective. I think netconf-syslog is a very useful addition to the syslog community, too. I am cross-posting my message to the syslog WG.
The most important thing that strikes me is terminology. Even though syslog terminology might not be familiar (or sound even strange) to the NETCONF WG, I think the draft should stick with it. The reason is that otherwise you will create confusion. One sample already under discussion: In <text-pattern> you specify "the message". As a syslog-guy, I would apply the regex to the message as whole and not just the MSG part. Thus, I would find a match e.g. in STRUCTURED-DATA. This is a very natural approach for someone who implements syslog. Using the same terms also eases the work for the implementor. From my understanding, the server to support netconf-syslog must support both netconf as well as syslog. It is quite confusing in code if the thing the syslog code side e.g. calls "severity" becomes "level" as soon as another part of the same code is called. In syslog-protocol, we tried hard to use the most common terms for new header fields. Unfortunately, syslog has a lot a variance, but I think we actually managed to find quite good terms. So I suggest the following term changes: netconf-syslog syslog priority PRI level severity process PROCID event MSGID text MSG (because it works on the MSG field) I also suggest to add APP-NAME as a filter in netconf-syslog. Adding TAG (from RFC 3164 & 3195) will also be useful. Some things of more substance: <format> In syslog-protocol, we have introduced the VERSION field. It denotes the version of syslog-rptocol message format of the message. It deliberately starts at 1 and increases monotonically (if considerable changed new versions of syslog should be specified). I suggest that in netconf-syslog <format> is replaced by <VERSION>, where zero denotes RFC 3164/3195 format and non-zero denotes a version according to syslog-protocol. This also facilitates parsing the actual syslog message on the receiving netconf syslog parser. <parameter> I suggest to rename it to STRUCTURED-DATA. I understand that the format is quite different from the actual syslog STRUCTURED-DATA format. But it filters on the STURUCTURED-DATA field. This is the same principle I applied above for text/MSG. I think it would be consistent to call the filter properties like the fields they operate on. Names for severity and facility 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. 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. To fully support remote syslog clients, a HOSTNAME filter is needed. That would be a (regex?) filter on the hostname. Similar filters are widely deployed on syslogds in practice today. 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. The syslog WG expects this to be a frequent scenario once syslog-protocol is finished. syslog-protocol already contains an identification for this (via the VERSION fields) as well as some specifics on transforming RFC 3164 syslog in a syslog-protocol receiver (A.1 in syslog-protocol-17). I suggest that netconf-syslog supports the same. Finally one small correction. On page 4 of netconf-syslog (at the top) it states: "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). I hope these comments are useful. Best regards, Rainer Gerhards > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Phil Shafer > Sent: Saturday, June 17, 2006 6:08 AM > To: netconf > Subject: draft-shafer-netconf-syslog-00.txt > > I've finally got an initial version of the draft for a netconf > capability that makes syslog data available over long-lived RPCs. > I just sent it off to the RFC Editor, so it should show up on > ietf.org sometime this weekend, but an advance copy is available. > > http://professional.juniper.net/phil/ietf/draft-shafer-netconf > -syslog-00.txt > > Thanks, > Phil > > -- > to unsubscribe send a message to [EMAIL PROTECTED] with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/netconf/> > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
