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