Re: sylsog in NETCONF notifications

["Rainer Gerhards" <rgerhards@gmail.com>]

<inline>

On 7/6/06, Andy Bierman <ietf@andybierman.com> wrote:
> 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.

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.

> > 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.
>
> Does this mean you think it is a good idea for the NETCONF WG
> 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.

> Or does it mean you think the SYSLOG WG should do this work
> 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

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