RE: NETCONF Instance Identifiers

["Sharon Chisholm" <schishol@nortel.com>]

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: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Balazs Lengyel
Sent: Monday, November 06, 2006 4:38 PM
To: Andy Bierman
Cc: Martin Bjorklund; j.schoenwaelder@iu-bremen.de; netconf@ops.ietf.org
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:
> 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/>

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