Hi Andy,
On 16/02/2017 22:36, Andy Bierman wrote:
On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm
<[email protected] <mailto:[email protected]>> wrote:
There are actually a number of interesting implications with
regards to NACM. NACM could indeed be a key to the solution if it
provides sufficient flexibility with regards to articulating and
enforcing authorization rules. Regarding this, I have a number of
questions/comments:
-If a subtree contains objects that a client does not have write
privileges for, will the client be prevented from locking the
subtree? How about the case when the client does not even have
read privileges?
locking and NACM are 2 different things.
NETCONF has datastore (global) locks and subtree (partial) locks.
There is no mechanism in NACM or elsewhere that constrains the values
that a particular client can use. (NACM controls access to the rpc,
with no
control over specific input paramters).
The current NACM-bis draft states in section 3.7.2 that this is
not the case – i.e. a client is able to lock an entire subtree,
even in cases when there is not a single object in that subtree
that the client actually has access privileges to.
To me, this does not seem right. It just invites abuse.
Now, there is still the possibility to restrict access to the
operation overall. But again, this means that you have to give a
users an all-or-nothing choice. Too inflexible. By the same
token that partial locks were supported to avoid requiring anyone
who needs the ability to conduct a transaction to lock down the
entire server, there should be the ability to restrict access to
the lock and partial-lock operation by targeted subtree. However,
this capability is currently missing.
NACM was designed to be simple to implement.
Some complex features that were in VACM were intentionally left out of
NACM.
NETCONF locking is also intentionally simple.
I would rather have NETCONF 2.0 use a mandatory implicit, optimistic
concurrent
locking model, rather than more band-aids on the optional explicit,
pessimistic
serialized locking model we have now.
This is interesting. If you have time, then at some point, please can
you expand on this idea, perhaps on the NETCONF alias?
Thanks,
Rob
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
