Re: notification motivation and requirements

[Balazs Lengyel <balazs.lengyel@ericsson.com>]

Why are we speaking ONLY about unintended consequences ?

As I see it:

1) I configure something <rpc  edit-config>
2) I get back a reply <rpc-reply OK>
later
3) Due to the previous operation something happened.
Something can be a confirmation about a long running action's success (e.g. backup) or 
something unintended or anything else.

For me the question is: if the device knows that this something is connected to the 
original <rpc> it would be good if it would reference the <rpc>.

If we put the notification on the same channel as the <rpc> we can just use the 
message-id. If the <rpc> and the <notification> are on different channels than we need to 
somehow refer to the <rpc> channel (how ?) or include some device specific reference in 
the device's data model.

regards Balazs

Randy Presuhn wrote:
> 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/>

--
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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