Subject: Re: NETCONF Instance Identifiers

From: Balazs Lengyel <[email-masked]>
Date: Mon, 06 Nov 2006 22:37:55 +0100

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 <[email-masked]> 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 6 Nov 2006 16:57:52 -0500

Hi

Just out of curiosity, are there a lot of implementations that don't
support XPATH?

Keyrefs and other standard constructs seem to all be based off XPATH, so
having to work for subtree might force us into less standard methods.
Unless keyrefs are also able to support subtree filtering. I have not
looked myself.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Balazs Lengyel
Sent: Monday, November 06, 2006 4:38 PM
To: Andy Bierman
Cc: Martin Bjorklund; [email-masked]; [email-masked]
Subject: 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:
>>>>> 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.
>>> 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).
> No -- IMO producing the correct instance ID requires the SW to know 
> the data model.
> 
> 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>).
> 
>> 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.
>>
>> 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 [email-masked] with the

> word 'unsubscribe' in a single line as the message text body.

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Nov 2006 14:29:33 -0800

> If a server/client does not support xpath capability how do we 
You are asking: Must the NMS understand any Xpath at all?

When the agent is generating an instance ID, it can only show up in
the <error-path> element.  This optional element is already defined as
an Xpath expression, so the agent does not actually have to use it.
But the NMS must understand it.  Obviously the NMS
must understand Xpath to issue <get-config> or <get> requests which
use an Xpath filter, and the agent must advertise the xpath capability
or it will generate an operation-not-supported (or is it invalid-value?) 
error.

The real issue ($64 bonus question) is:  instances of WHAT?
Literal instances of XML subtrees? Or conceptual instances of
complex data structures within a NETCONF-aware data modeling language? 

Andy