Subject: [Netconf] Full XPath and partial locking

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2009 12:18:13 -0800

If the full XPath is supported, then arbitrary XPath
expressions are allowed.  However, there are known
interoperability issues wrt/ some XPath constructs
as applied to NETCONF databases.  These are not
addressed in the draft.

The preceding, preceding-sibling, following,
and following-sibling axis are implementation-dependent.
All positional expressions are implementation-dependent.
Given 2 identical XML representations of a NETCONF
database (e.g., via <get-config>), no 2 NETCONF implementations
are required to produce the same results for positional
XPath expressions (e.g., '//name[42]').

NETCONF is not the same sort of application
as XSLT, and it uses XPath differently.
For example, for XPath filtering selecting a node
also selects all the ancestors of that node,
but for partial locking it does not.  Therefore
the ancestor, ancestor-or-self, and parent axis
may work differently for different NETCONF operations.

It is not clear how the operator finds out exactly what
is locked.  Given that positional expressions are legal,
it seems important.  E.g., locking '//name[42]' is evaluated
one time, so even if 3 'name' elements are deleted, and
the 42nd instance is now the 39th instance, the lock
does not change.  But the node-set associated with '//name[42]'
keeps changing.

It seems that implementation of the netconf monitoring data
model is going to be required in order to find out what
is really locked.  I do not see any discussion of this issue
in the draft.

What happens if config=false nodes are identified by the
XPath select expression?  Is this documented?  Is it an
error or NO-OP?

Andy

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf