[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-shafer-netconf-syslog-00.txt
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: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] 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 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/>
>
--
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/>