Re: notification motivation and requirements

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Andy Bierman" <ietf@andybierman.com>
> To: "David T. Perkins" <dperkins@dsperkins.com>
> Cc: "Juergen Schoenwaelder" <j.schoenwaelder@iu-bremen.de>; <netconf@ops.ietf.org>
> Sent: Wednesday, March 29, 2006 4:59 PM
> Subject: Re: notification motivation and requirements
>
> David T. Perkins wrote:
> > HI,
> > 
> > The wording is bad in my description below since it implies that
> > present day devices can determine when resulting conditions or
> > events are unexpected consequences of a config change.
> > 
> > So, please change it to the following:
> >  *) notifications that report changes in device state, or
> >     transient events so that the mmgmt app can determine
> >     any unexpected consequences of a configuration change.
> 
> Isn't this just a special-case of the general
> requirement to provide enough info in each <notification>
> so that it can be analyzed by an application independently
> of the notification transport mechanism?  (Maybe that is a
> new requirement.)
> 
> Maybe this is what Randy means by not binding to notification
> delivery parameters to the session.
...

No, David is talking about something else.  He described a
scenario in which some way of associating a notification with
a particular configuration request would be valuable - if we employ
heuristics that might reasonably detected "unintended consequences"
of configuration requests.

Where this does fit together with what I was saying is whether we
consider it necessary for such a notification to be delivered on the
same connection as the configuration request that caused the potential
problems.  If we do, it's effectively an "oh, by the way, I noticed side-effects
X, Y, and Z" after the response to a configuration request.  If we separate
the subscription from the connection, it become "operation foo on
netconf connection bar seems to have precipitated side-effects X, Y, and Z".

Of course, this presumes that we have a way in protocol to talk about a
particular netconf connection.

Randy


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