[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: no interim meeting -- read the rules
Hi,
For us notifications are needed mostly not as a logging mechanism but as:
- a way to notify about configuration changes
- a way to notify the management system about delayed results of an RPC (e.g. when an RPC
initiated action takes 10 minutes to complete we send an immediate reply <started> and a
late reply <finished>)
- to notify the network management system (NMS) about things that might need operator
action. (While alarm handling is mostly SNMP there is a need for some other events to be
handled by the NMS.)
For these reasons we do need a notification mechanism. We could use
- SNMP: but if we have an XML based hierarchical data model with meaningful names using
SNMP is not my choice.
- Syslog: but the message size limit of less then 480 octets seems a problem. Also I like
subscription. Adding XML to syslog needs some work. We have to care about a second
transport/security mechanism TLS (I don't know if this is a real problem).
- Netconf-notifications: This would mean a somewhat unified structure within Netconf.
Using our XML-based hierarchical data model would be natural.
regards Balazs
Andy Bierman wrote:
As Dan and Dave H. pointed out, we need to agree on what
we are doing and why we are doing it. Several people
have told me (and mentioned on the list) that they
don't understand why we are reinventing syslog instead
of working on network configuration.
So let's write down all the reasons why we need notifications
in NETCONF, and why using or extending existing standards
instead won't work.
>
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/>