Re: notification motivation and requirements

[Andy Bierman <ietf@andybierman.com>]

David T. Perkins wrote:
> HI,
>
> Here are a couple to add to the list....
>
> *) notifications to report unexpected consequences of
>    a configuration change

How is the agent supposed to know what the NMS really
wanted to do?  Why do we need this?

> *) notifications so that state changes can be followed
>    due to configuration changes. (Background: some 
>    configuration changes can result in destalization
>    followed by transition through several states to
>    the desired stable state. It is important to know
>    the cause of a "service affecting event", and to
>    know if the config change has resulted in a new
>    stable and desired configuration. If not, then
>    the config change, most likely, should be rolled
>    back to the previous settings.) 

You should write a draft with the data model
that you are implying here.  IMO, the notification
capability should not drag in a bunch of data models.

There should be absolutely no content requirements
for notifications -- just like there are none
for configuration data models.
I want <cli> and <huge-bgp-model> to be on equal footing
in our content-independent protocol.  Same thing
applies to notification content.


> Regards,
> /david t. perkins

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


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