Re: Notifications with config change

[Cridlig Vincent <vincent.cridlig@loria.fr>]

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


	

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