Subject: RE: example notification seems redundant

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 7 Apr 2006 07:54:03 -0400

<Andy>

The examples in the notification draft aren't
very clear.  It seems like they must be intended
for a session other than the one that made the change,
because all of the info is redundant -- it would be implied
by an <ok>in the rpc-reply, or explicitly identified in the <rpc-error>
elements returned in the rpc-reply.

So why would config changes (ok or error) need to come right back on the
same session, duplicated in the form of a notification?

Wouldn't side effects (e.g., notification that says BGP4 started)
normally be monitored anyway by some notification receiver app?
<Andy>

I can interpret your question in two ways. Here is each of them

1. What redundant information? On a successful subscription, the request
returns the subscription ID, which is how you learn what it is. That
isn't redundant.

For the notifications themselves, they contain the subscription id, both
because you can have multiple subscriptions on a single connection and
because it is a nice indication that you are still receiving information
on the same subscription.

The only possible piece of redundant information, as Simon pointed out
in our offline meeting in Dallas is the messageId in the wrapper around
the notification.

2. There is no assumption that configuration changes will always be
applied on the same connection. Their are advantages to allowing a
mixing of notifications and certain commands (replay, modifying
subscriptions, reviewing information around notifications) and some
resource conscious deployments may choose to do everything on one
connection. Other deployments will break out some of the operations on
different connections. Plus, even if one did assume that everything was
done on a single connection, considering we are talking audit logs, you
would certainly want any configuration operations performed by people on
*different* connections to come through and not be just sent to the
possibly evil or incompetent person on the other connection.

Sharon

--
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: Andy Bierman <[email-masked]>
Date: Fri, 07 Apr 2006 06:50:45 -0700

> possibly evil or incompetent person on the other connection.

Look at the <config> data in your example.
There is no explanation of what the notification
in sec 5.1 is supposed to be.  I assume it is a config-change.
Or a config-error.  My point is that for the manager that does
an <edit-config> which supposedly caused this notification,
there is no value in the notification at all.  All of the info
is contained in the <rpc-reply> already.

So the notion the receiving notifications on the same session
as operations will somehow makes the operations easier -- is wrong.
The only benefit is that it saves the memory overhead of 1 session,
in exchange for the complexity and lose-lose operational
characteristics of a shared session.

IMO, the examples in the draft are more suitable for traditional
notification generator applications.

> Sharon

Andy