RE: example notification seems redundant

["Sharon Chisholm" <schishol@nortel.com>]

hi

There are really then three different use cases at work here

1) I am the originator of the request and I would like some concise
indication that things worked out OK in the end for some reason or other

2) I am creating an audit log and need to know exactly what was done and
by whom and how

3) I am a user of the configuration information and need to know what
information has been changed. This covers the cases of configuration
mirroring, configuration applications and people just interested in the
device inventory for whatever reason. 

The example content in the appendixes cover the second and the third
cases. I believe the message content is different for the three use
cases.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] 
Sent: Friday, April 07, 2006 9:51 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: example notification seems redundant


Sharon Chisholm wrote:
> 
> 
> <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.
> 

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




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