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

[Phil Shafer <phil@juniper.net>]

"Rainer Gerhards" writes:
>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.

Truly appreciate your comments, especially the terminology ones.  I'll
update the draft with these next week.

>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.

>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?

>"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.

Thanks,
 Phil

--
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/>