Subject: Re: Notifications with config change

From: Cridlig Vincent <[email-masked]>
Date: Wed, 29 Mar 2006 21:54:22 +0200

>
> 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.
>   
This is where Role-Based Access Control comes into action.
Dividing the config into further pieces is exactly the same as defining 
a set of roles for identities (users or appplications), each role being 
granted some permissions.
When a user activates a role, he is allowed to update only a limited 
part of the config, which helps a lot for reducing misconfiguration.

In your example, you would instead define a adminRole and an 
operationalRole. OperationRole, for instance, would be granted the 
permission to modify a specific subtree of the Netconf data model 
related to operational configuration. adminRole would be allowed to 
modify the security policy of the management interface (Netconf itself).
A monitorRole would be granted the permission to receive notifications.
And so on...

Vincent

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

		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com

--
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: "David T. Perkins" <[email-masked]>
Date: Wed, 29 Mar 2006 10:38:51 -0800 (PST)

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.

Regards,
/david t. perkins

---

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

HI,

So, I'm confused by your response because it doesn't seem
to address whether or not there is a benefit that exceeds
the cost from "providing a notification channel that is
created and shares fate with a session that includes a
configuration channel".

As regards to "role based management", it is one,
but not the only approach for implementing authorizations.
That is, I don't see it as a requirement, and instead
see it a one potential solution in managing authorizations.

(see inline comment below)
> A monitorRole would be granted the permission to receive notifications.
So, using role-based access control (which is one possible
approaches to specifying authorization) it doesn't seem to
eliminate the 1st and 3rd config changes, nor does it eliminate
an upgrade in authorization. I'm I messing something?

Regards,
/david t. perkins

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 30 Mar 2006 11:11:23 +0200

If we agree that Netconf based network managers do need notifications I wonder if the 
"increase in complexity" is really true. Yes netconf itself will be more complicated, but 
on the other hand for a manager to do configuration via netconf and receive notifications 
via something else (e.g. syslog) seems complicated as well.
Balazs

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