Re: notification motivation and requirements

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

see inline.
On Wed, 29 Mar 2006, Andy Bierman wrote:
> 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?
This is sloppily worded. How about the following....
 *) notifications for areas outside the area being changed
    that report changes in device state to error states,
    or transient error events so that the mmgmt app can
    determine any unexpected consequences of a configuration
    change.
 
> > *) 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.
I really need to write a book!

Anticipating your followup....
The difference between the first and second is that
the second is about notifications that are "expected".
For example, if I change some bridge spanning tree
configuration values, this might result in a change
of the spanning tree topology, and a notification will
be generated of topology change. The first set of
notifications are unexpected, such as when I change
the bridge spanning tree config, I get a notification
that a system process (the spanning tree process)
crashed and rebooted.

> 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.
I don't really understand what you are saying, and
don't understand how it relates to why getting
notifications during a config change session
adds value to config management.

Regards,
/david t. perkins


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