Subject: sylsog in NETCONF notifications

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 6 Jul 2006 17:43:42 +0200

WG,

I suggest that the mapping of syslog to netconf notifications as well
as the "syslogTunnel" event type be left out of the netconf
notifications I-D. The reason is that I think the syslog community
should provide a data model for syslog notifications as well as a
mapping. The same should probably be done for SMTP traps.

Having syslog mappings in a basic netconf document forces the netconf
document to be changed/obsoleted whenever there is change on the
syslog side. I think this dependency should be avoided.

There is some growing interest in the syslog community to define event
data models. This effort could play nicely together with netconf.

Rainer

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 Jul 2006 08:58:41 -0700

> mapping. The same should probably be done for SMTP traps.

I disagree.
I think it is fine for the NETCONF WG to reference a specific
version of syslog as the content format.  If the SYSLOG WG
invented a new version, then the NETCONF PDU would just reference it.
I don't see a problem if the NETCONF WG creates configuration
mechanisms for NETCONF (such as notification filtering) and
uses well-known fields in a specific version of syslog.

> data models. This effort could play nicely together with netconf.

Does this mean you think it is a good idea for the NETCONF WG
to create a brand-new netconf-only notification system?

Or does it mean you think the SYSLOG WG should do this work
instead of the NETCONF WG?

> Rainer

Andy

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 6 Jul 2006 18:30:21 +0200

<inline>

> uses well-known fields in a specific version of syslog.

I do not see any problem if the NETCONF WG creates a configuration
mechanism for NETCONF. But appendix B looks like the NETCONF WG
creates a configuration mechanism (or better: notification mechanism)
for syslog. If that is just one way of doing things, why not also
specifying how SNMP traps and informs should be carried inside a
NETCONF notification?

If you talk about filtering and also talk about syslog data, NETCONF
IMHO actually tries to define a configuration mechanism for SYSLOG.
The draft is not taking SYSLOG as *the* content format and just
extending it with some syslog fields. The draft is defining a NETCONF
notification format (which is perfectly fine and good to see) and then
is mapping how SYSLOG should be mapped into it. The later IMHO should
be done as a separate effort via a SYSLOG data model.

> to create a brand-new netconf-only notification system?

I think it is eventually a good idea for the NETCONF WG to create a
brand-new, EXTENSIBLE notification system that could also transport
events traditionally being transported via SYSLOG, SNMP or
vendor-specific event notification protocols. If I understood NETCONF
correctly, it is a common base that it should be extensible.
Extensions can be vendor-specific or via standard capabilities. Lots
of discussion on this list are focussed about data models for
configuration. If I follow that spirit, NETCONF notifications should
provide a framework for notification delivery, but not necessarily
(and exclusively) all data models that could be transported via it.

> instead of the NETCONF WG?

I think the syslog community should standardize a SYSLOG data model.
As much as it probably could standardize a basic SYSLOG configuration
data model (including syslog-specific filters and event actions). I do
not think that the current SYSLOG WG (chartered in the SEC area) is
the right one to do this. I think a new SYSLOG WG should be chartered
in the OPS area to standardize syslog payload and thus also provide a
data model. Ideally, it would lean on the good work NETCONF has done.
Such a data model could be advertised as a capability.

Rainer