Re: Methods, data hiding, and friends

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

On Sat, Nov 04, 2006 at 01:04:40AM -0500, David Harrington wrote:
 
> In netconf, a capability's method such as "create-vlan" may need to
> manipulate the data elements of other capabilities, such as the
> interface capability. Will methods of one capability be permitted to
> directly modify the data of another capability, or will they be
> constrained to utilize public and friend interface methods of the
> other capabilities?

Netconf has evolved to take two different views of the world:

(1) A document-centric view where you use primitives like the powerful
    edit-config operation to make changes on a document describing a
    configuration.

(2) A function-centric view (or {method/operation/procecure/command}
    -centric view if you like these terms better) where you use
    special RPCs to invoke a certain function.

As a consequence, I believe we need to have an access control scheme
which supports a document-centric view and a function-centric
view.

The question was raised whether the access control for the
function-centric view is also subject to the access control for the
document-centric view (or view versa although people did not mention
this yet) and my personal answer to this question is "no". A function
"create-vlan" performs a certain well defined operation and I either
grant access for someone to perform this operation or I don't. The
value of a function such as "create-vlan" is that it hides the
implementation details and objects affected and I fear we loose the
benefits of hiding the details once we end up specifying which
"objects" are involved in the execution of such a function for access
control purposes.

Sure, this approach opens a window for "interesting" access control
configurations where "side effects" may be used to achieve something
using the function-centric view which you are not allowed to do via
the document-centric and vice versa. (For example, you disallow the
usage of the "create-vlan" function for some principal but the same
principal may still be able to create a vlan by playing with
"edit-config".) I assume that the price on the agent side for
preventing such situations is going to be high and thus I prefer to
push the handling of such situations to external tools that can
analyze and reason about access control rules. (Note that this is not
really something new. Even in the SNMP world, if I prevent access to
the interface table, someone might still create a VLAN interface using
her write access to the Q-BRIDGE-MIB::dot1qVlanStaticTable.)

BTW, I would like to have the flexibility to give one principal only
access to the document-centric view and another principal only access
to the function-centric view of a box. I believe that applications
(and most humans) will prefer one of the two views for a given task.
To create vlans, you likely prefer a "create-vlan" function; for
saving/restoring configs or for pushing a tested config change to many
boxes, you likely prefer edit-config. For testing config changes, you
might again prefer a function-centric view.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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