In my understanding, the normal workflow is that:
1. The client first fetches the whole config (even though a smaller scope for get is probably much better). By the way, this get will show only what the user is allowed to. Typically, you won't give write access on something that the user has no read access!!
2. The user edit the config
3. The client is clever enough to send a more specific request to update what needs to be (rather than sending back the whole config like in a copy-config).
To control what a user can read or not, you have to use XPath expressions and the "r" attribute (at least or "rw").
To implement the partial access to the data model, you can just apply the "r" XPath expressions to the result of a get-config request before sending it back to the manager. The selected nodes are the allowed nodes. Then you can propagate the allowed nodes to their children and their parents. You get a new set of nodes. The nodes that are not in this set are discarded, because access is denied by default.
This is implemented in the open-source Netconf agent (yencap) that I did 18 months ago (http://ensuite.sourceforge.net/).
Not sure if this answers your questions.
Vincent
-----Original Message-----
From: owner-netconf@ops.ietf.org on behalf of Johan Rydberg
Sent: Thu 12/20/2007 7:57 AM
To: netconf@ops.ietf.org
Cc: cridligv@loria.fr
Subject: draft-cridlig-netconf-rbac-00.txt
[subject] states that for <get/> and <get-config/> all subtrees
without read access should be filtered out of the result.
In other words, the data is in the configuration but the user can
never read it out. This applies to any configuration, not just
''running''.
In respect to <edit-config/> [subject] specifies:
[...] On receipt of an edit-config request, the agent applies
the XPath expressions of the write "w" permissions set on the
request. All children and parents of the selected nodes are
marked as authorized nodes. If a "replace", "create", "delete",
or "merge" operation is set in one of the parents of the
selected nodes, access is denied.
My understanding is that this renders the 'replace' value for
the default-operation parameter useless, since the user will try
to delete all config data for parts of the data model that he or
she don't have access to.
I can imagine that the normal workflow for an operator using a simple
netconf tool is that he first fetches the whole configuration using
<get/>, edits the result, and then updates the candidate with either
<edit-config(default-operation=replace) /> or <copy-config/> and
finally commits it using <commit/>. The problem is that he will not
be able to do that if he don't have access to the whole data model.
He would have to set an xc:operation='replace' on all top elements
and then merge the changes into ''candidate'' with <edit-config/>.
Far from user friendly.
How would you implement partial access to the data model? Esp where
you can control if a user can read data or not.
best regards,
Johan
--
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/>