Rainer Gerhards wrote:
On 7/7/06, Andy Bierman <ietf@andybierman.com> wrote:I don't think that if the netconf protocol had any particular syslog content filters (for netconf delivery of syslog), the syslog protocol (or WG) would be impacted in any way.Just to clarify: my comment dug even deeper. Here, I am not only concerned with SYSLOG. I think the cleanness of NETCONF notifications would be compromised if the core notifications draft depends on non-NETCONF-native filter capabilities. I think it should be aimed to find a filtering capability that is able to express filters in a very generic way, including nested boolean operations and regular expression filters. I can envison that these are useful for vendor extensions as well as for SYSLOG.
Agreed. The protocol itself needs to be content-independent. I argued that even the <eventClass> field should just be a string instead of the netconf WG defining the allowable values of that string. (I don't know exactly what the WG wants to do here yet.) I like the basic architecture Phil is proposing (except I want to make sure any NV-stored data is handled properly). I like the idea of NV-configuring multiple streams on an agent, based not only on filtering subsets of the data, but also to support different encodings of the same notifications. I like the idea of the netconf manager issuing a <start-notifications> RPC and subscribing to a pre-configured stream, or providing a "my-session-only" stream config that the agent will toss when the session is closed. This provides a transition path to XML-encoded syslog or snmp-notif streams. Legacy apps will subscribe to "syslog/RAW", and gradually, new apps will have some reason to subscribe to "syslog/XML" or "snmp/XML" formatted streams.
Rainer
Andy -- 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/>