RE: sylsog in NETCONF notifications

["Hector Trevino \(htrevino\)" <htrevino@cisco.com>]

in-line
Hector


> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Rainer Gerhards
> Sent: Thursday, July 06, 2006 10:30 AM
> To: Andy Bierman
> Cc: netconf@ops.ietf.org
> Subject: Re: sylsog in NETCONF notifications
> 
> <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?

HT: Because nobody (that I know of) is interested/needs to carry
    SNMP notifications inside NETCONF. Whether or not the Appendix B
proposal stays
    in is up for discussion next week. 

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

HT: The title of the section is "Leveraging Syslog Field Definitions"
and as the title I think suggests the purpose is to re-use existing
syslog definitions where it makes sense. 

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

HT: That's the idea. Right now the doc only covers syslog & as I said in
a previous e-mail
    SNMP is not something that has come up. 

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

HT: I think this is good. Not sure what SYSLOG data model entails but
I'll assume it could include event types/contents. If so, could this be
done (i.e. event types, contents) defined in a protocol independent
manner. 

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

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