Dynamic lock scope or simple lock scope ?

[Balazs Lengyel <balazs.lengyel@ericsson.com>]

Hello Sharon,
You touch one of the most interesting issues here.
If we allow to lock "groups of nodes" e.g. all interfaces not just one or more individual nodes
then we have a problem. However you define the group it is possible that new members will be
created.
Now you might pick up these members dynamically or not. If not then your XPATH expression will
be slightly misleading when new nodes are created. If yes you have a lock in which the nodes
are dynamically changing. This could be most confusing. Imagine that you use the position()
function to select a node, and someone adds or deletes a node before your node. If we have
dynamic nodes you suddenly lock something you never intended, while your intended node is not
locked. The same situation might arise with the use of the following or preceding axis.

I see two ways to avoid this unacceptable situation:
1) Use an extremely simple XPATH like what Andy is proposing, so that you can avoid dynamic
changes. This forbids stuff like lock all interfaces. It only gives us a basic functionality. 
Some people might say we need a more flexible solution.

2) Evaluate XPATH only once and accept that the XPATH might become outdated. The real lock 
should be maintained as a set of nodes that were originally selected by the XPATH. In the 
netconf monitoring data model we should probably have a list of nodes instead/beside the 
original XPATH expression for partial locks.

Balazs

> Sharon Chisholm wrote:
> >
> > 2. Section 2.4.1, second paragraph, I assume the discussion of the
> > partial lock not picking up new stuff to lock is done for simplicity? I
> > am not sure it is what the user would want. I'd also be interested in an
> > example of how new stuff get created if there is a lock.
>

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