Subject: Re: notification motivation and requirements

From: "David T. Perkins" <[email-masked]>
Date: Wed, 29 Mar 2006 09:28:11 -0800 (PST)

HI,

Here are a couple to add to the list....

*) notifications to report 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.) 

Regards,
/david t. perkins

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Mar 2006 23:03:18 +0200

> *) notifications to report unexpected consequences of

How does a device distinguish between expected and unexpected
consequences of a configuration change?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Mar 2006 15:18:51 -0800

> *) notifications to report unexpected consequences of

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

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

> /david t. perkins

Andy

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 29 Mar 2006 15:42:15 -0800 (PST)

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.

Thanks for catching my sloppy wording.

Regards,
/david t. perkins

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 29 Mar 2006 16:00:46 -0800 (PST)

HI,

see inline.
> 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.
 
> 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.

> 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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Mar 2006 16:59:04 -0800

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

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 29 Mar 2006 17:29:28 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "David T. Perkins" <[email-masked]>
> Cc: "Juergen Schoenwaelder" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 29, 2006 4:59 PM
> Subject: Re: notification motivation and requirements
>
> David T. Perkins wrote:
> > HI,
> > 
...

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Mar 2006 18:37:40 -0800

> particular netconf connection.

Why do you need the agent to do anything fancy at all?
You lock the configuration.
You make changes with edit-config.  You wait a few seconds.
You look at any notifications that get generated.
If it's related to configuration, it's yours.

If it's not, then neither netconf or anything else can
be sure -- and what good does guessing do?  E.g.,
if I change the bridging configuration, and some notification
related to spanning tree comes up, it could just be a
coincidence, and the problem may be caused by another device.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 30 Mar 2006 13:02:06 +0200

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

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Mar 2006 10:49:01 -0800

Hi Andy -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, March 29, 2006 6:37 PM
...
> Why do you need the agent to do anything fancy at all?

I don't.  I was only explaining how what David Perkins was
describing and what I were describing were very different
things, only peripherally related.

...
...

That's why I characterized it as a heuristic.  I'm not arguing for or
against what David described.  I was just explaining that your
attempt to lump our statements together didn't make sense.

Randy