Notifications with config change

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

At the WG NETCONF meeting at the Dallas IETF conference,
I tried to make a point about event reporting (notifications)
during a config change. I didn't seem to be understood,
so let me try again...

First, I believe that delivery of event reports is needed
during config change. (The reasons are currently being
collected.)
I also believe that each config change needs to be
recorded and reported. (This is for auditing, to determine
if a config change resulted in a problem, to check that
each config change was authorized, to correlate changes
in config to changes in behavior in the system (such
as changes in performance, changes in service instance
capacity, etc).)

So, if configuration of notification delivery is not
a part of config change, then an application that
does config change and wants to receive notifications
must do the following:
1) config the system to send the app appropriate notifications.
2) perform the config change (and receive any appropriate
   notifications associated with the config change)
3) config the system to no longer send the app notifications

At a macro level this looks like three config changes,
even though the 3rd config change undoes the 1st change.
If a config app gets delivery of notifications as part
of the creation of the "session" for config change, then
there would be no config change #1 and #3.

A second related issue is that the authorization to modify
the notification delivery part of the configuration is
an upgrade in capabilities of a configuration application
which could be abused. In very small systems, the 
capability to view and/or modify config is all or
nothing. The next step up in granularity is separating
the config into the "admin part" and the "operational
part", and then having separate apps (and authorized
identities) for managing the admin and operational
parts of the config. (The admin part determines the
list of authorized identities and what each is
authorized to do, including receive notifications.
To receive notifications the following must be
configured: the target address, credentials to use in
creating the session to deliver the notifications,
the filters for the session, and access to a log
in case the notifications can not be delivered.)
The next step up is dividing the config into
further pieces so that applications can be
restricted to modifying only the needed parts.

So, in summary, I believe that providing a notification
channel that is created and shares fate with a session
that includes a configuration channel is a desired
feature because:
1) it eliminates what appear like two config changes
2) it results in better system security

Note that I realize that the above benefits come
with costs, and they include:
1) an increase in complexity of the NETCONF protocol
2) a change in mindset of existing developers and
   users of existing approachs

I believe that the benefits far exceed the costs.

Regards,
/david t. perkins   







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