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

---

From: WashamFan <[email-masked]>
Date: Sat, 24 Jan 2009 11:54:29 +0800

Hi,
  I remember I saw the similar topics diccussed in NETMOD thread.
  A rough consensus seems to be achieved there that positional expression should not be used or may be use with keeping in mind that there would be a risk.

washam
> Hi,

---

From: WashamFan <[email-masked]>
Date: Sat, 24 Jan 2009 11:54:29 +0800

Hi,

washam

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 25 Jan 2009 12:43:38 +0100 (CET)

> and following-sibling axis are implementation-dependent.

This is either NETCONF-specific, and if so, it should be documented in
4741bis; or it is data modeling language-specific, and if so it should
be documented in the DML spec.  Unless it's NETCONF-specific, I'm not
sure it can be documented here?

> is locked.

The operator gets a leaf-list of 'locked-node' elements in the reply.

> XPath select expression?  Is this documented?  Is it an

It is documented that the select expression is evaluated for a data
store.  So if the expression refers to something that is not part of
the data store, that reference will return an empty node set.
config=false nodes are YANG-specific, but they are not part of any
data store, so the effect is the same as referencing an unknown node.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 25 Jan 2009 12:43:38 +0100 (CET)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 25 Jan 2009 11:52:41 -0800

> sure it can be documented here?

Perhaps this should be in the YANG Usage Guidelines spec,
which is intended to be BCP and not standards-track.
I already put some text in the I-D about XPath.

My bias comes from many years working on the embedded
side of the fence.  IMO, a NETCONF database is not
an XML instance document.  It is part of a particular
implementation of the NETCONF protocol.

In order to implement XPath to the letter, an agent
implementation would have to maintain an XML representation
of the entire configuration and all the state data,
in addition to its native data structures.

This would be a big problem for implementations which
stream the PDU responses, based on the internal data structures
(and perhaps sub-agents far away, etc.).  There is no XML document
inside, in this case.

There's only so far I am willing to pretend that a
NETCONF database inside an agent implementation
is a proper nail for XPath to hammer on.

> The operator gets a leaf-list of 'locked-node' elements in the reply.

OK -- seems verbose, but this is XML, so not a problem then.

> data store, so the effect is the same as referencing an unknown node.

IMO, a 'select' parameter with invalid XPath
MUST cause an 'invalid-value' error.
Everything else is just an empty nodeset.
A 'select' parameter does not need to represent a node-set.
So stupid XPath like select '7' is just an empty nodeset
<ok> response and not an error.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 25 Jan 2009 11:52:41 -0800

Andy