Andy, I am a bit confused. You say:
My intent is to have a content-independent framework for delivering notifications, but not have the NETCONF WG develop any standard notification content unless it is directly related to configuration.
I fully agree with you on that. But you also say:
IMO, syslog is important enough that it is worthwhile to have filtering mechanisms that actually work for syslog. Generalized filters sound great, but if they are impossible to use for the most common application (syslog/RAW), then they are mostly irrelevant. Telling all the vendors "Hey, I have a really cool XML tool, so if you could re-design and re-code 15,000 or so syslog messages to output an XML subtree instead of text, well, that would be great." I suggest coming up with a transition plan, because it will be about a decade before you get to use your fancy XML tools on notification content.
I agree with you on the need and the timing. I am not sure if I am with you who should do that. Are you saying the NETCONF WG should do that? If so, I think it is beyond the NETCONF charter. I would appreciate if you could clarify if you think NETCONF should a) develop a notification mechanism and a data model for NETCONF and/or b) develop a data model and transformation rules for SYSLOG Thanks, 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/>