Re: partial locking and access control

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> 
> .....
> >> Also, what if another session issues a <partial-lock> that matches
> >> this new node, but none of the nodes locked in the first partial-lock
> >> RPC (by the other session).  This new node would of matched the
> >> original Xpath expression had it existed at the time.
> > 
> > Sure, but since it didn't, it wasn't locked.
> > 
> 
> This is an important issue, and demonstrates the problems with
> the current approach in the draft.
> 
> Let's say an operator locks "*/ifAdminStatus" to make sure that
> nobody turns off any interfaces during some network test
> or big config change.

Well, this simply doesn't lock all interfaces as you point out.  This
won't work with the plain instance identifier approach either, if the
operator gets a list of all interfaces from the box and locks them all
explicitly.

> There are 2 separate issues here:
> 
>    1) Designing a partial locking mechanism that meets operator expectations

I agree that locking a simple subtree (instance identifier) is simple
and easy to understand.

>    2) Monitoring which nodes are actually locked by a partial-lock operation

Actually, this can still be solved for the general XPath case.  In the
monitoring list of locks, we can simply list all instance identifiers
held by a lock:
   
   leaf-list locked-subtree {
      type instance-identifier;
   }

This is what we'd have to do for the instance-identifier only solution
as well.


This being said, I don't have a strong opinion on this issue.  But I
don't think the arguments I have seen so far says that general XPath
cannot be used.



/martin

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