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.