[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NETCONF Instance Identifiers



Hello,
If we use xpath to identify instances, does this need the the xpath capability?
If a server/client does not support xpath capability how do we identify instances?
Balazs

Andy Bierman wrote:
Martin Bjorklund wrote:
Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> wrote:
On Mon, Oct 16, 2006 at 07:49:31PM +0200, Martin Bjorklund wrote:
Using xpath (or a subset of it) is fine with me. I note, however, that
once we go down this path, we have a situation where we use instance
identifiers where subtree filtering is unable to select such
instances.
You mean b/c of the use of position()?  I assume that position() would
be used only when the data model indicates that there is a set of
instances, but they don't have a key.  So I guess the real issue is
that if the data model allows instances without keys, then subtree
filtering can't be used to select such instances.
This argument sounds backwards to me. We either allow things like
position() or we don't.

If we allow such things (which I do like and support), then we simply
have an instance identification mechanism which has more expressive
power than subtree filtering has (and it is IMHO irrelevant whether
you have other keys that can identify the same instance or not).

Ok.  So you mean that these two identifiers would be ok?

   /interface[name="eth0"]  and  /interface[2]

No -- IMO producing the correct instance ID requires the SW to know the
data model.

For named data, the canonical instance ID must use the naming components.
The position identifier is only the canonical ID for unnamed data.

Again -- let's be clear to distinguish an Xpath expression
used in NETCONF PDU constructs as a selector (e.g., <filter>)
and PDU constructs used as an Instance Identifier (e.g., <error-path>).

For the latter, we want a simple, constrained, canonical format.
We have no constraints on the former.





One problem with the second alternative is that it's difficult to know
whether the string will identify the same object over time, since
interfaces might come and go.

I strongly dislike an approach where certain xpath features (like
position()) may only be used under some conditions.

Are you suggesting that any XPath construct should be valid in an
Instance Identifier?  Or do you mean that if position() can be used in
some places in an Instance Identifier, then it should be possible to
use it anywhere in the Instance Identifier?


/martin

Andy

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

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