Subject: NETCONF Instance Identifiers

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Oct 2006 07:34:37 -0700

Hi,

Several people have requested that we solve this problem.
I don't think it needs to be tied to the Notification work,
but it is useful for notification content to have a common way to describe
a particular instance of an XML element within a NETCONF data model.

It seems to me this problem is fairly simple.
It seems to me we could agree on naming without agreeing
on any particular data modeling language constructs,
because an instance identifier is just an absolute Xpath expression.

Here is something to throw darts at, and see how much consensus
exists on this issue:

==================================================================================

NETCONF Instance Identifiers

An instance of an element is defined by its absolute path from the root.

1) There is a 'fixed' root, starting at <rpc>, for methods
    and data.  There is also a conceptual 'relative' root for data.
    This is unnamed, and will be called <config> or <data> or <filter>
    in a NETCONF PDU.  There is no default namespace associated with
    the root.

2) An absolute Xpath expression containing all relevant conceptual
    INDEX (key) components represents an instance.  Order within
    an INDEX is significant. The leftmost INDEX component is the
    major index.  Each minor index in succession is listed left to right.

    E.g.: <bar> is a table indexed by x and y:

    /foo/bar[x="3",y="4"]

    E.g.: <baz> is a table indexed by a name string:

    /foo/bar[x="3",y="4"]/baz[name="fred"]

3) Unnamed instances (e.g. maxOccurs="unbounded") are identified
    by their position (relative to other instances of the same element),
    using a special INDEX component called 'position'.  Unnamed
    instances are numbered starting at zero.  Conceptually, all
    unnamed, single-instance elements can be identified as position="0".

    E.g.: <goo> is a simple type that can occur 0 or more times

    /foo/bar[x="3",y="4"]/baz[name="fred"]/zoo/goo[position="3"]

4) RPC methods are identified by their path from the absolute root,
    and instance identifiers used within <error-path> elements may identify
    the entire path to the <rpc> element.

    /rpc/edit-config/error-option

    /rpc/edit-config/config/interfaces/interface[name="eth0"]

5) If namespaces are used then components within the Xpath expression
    must consist of properly formatted Qualified Names.

   /nc:rpc/edit-config/config/acme:interfaces/interface[name="eth0"]

===========================================================================

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

---

From: Phil Shafer <[email-masked]>
Date: Mon, 16 Oct 2006 11:02:49 -0400

>    in a NETCONF PDU.  There is no default namespace associated with

<rpc> or <config>?

>    /foo/bar[x="3",y="4"]

Stick w/ xpath syntax and use "and":

   /foo/bar[x=3 and y=4]

>    /foo/bar[x="3",y="4"]/baz[name="fred"]/zoo/goo[position="3"]

This makes "position" a magic token.  In XPath, position() is a
function that does approximately the same thing (origin 1).

    goo[position() = 3]

>    /rpc/edit-config/config/interfaces/interface[name="eth0"]

I don't follow you here.  Why would an xpath originated at
/rpc/ be valuable?

>   /nc:rpc/edit-config/config/acme:interfaces/interface[name="eth0"]

Yup, and don't forget the joys of namespaces and attributes.

But I feel like I'm missing something.  Aren't we really needing
something in the schema that defines what elemenents are identifiers,
rather than XPath syntax for it?  My developer/app needs to know
that the "interface" element is identified by the "name" element
and the most convenient place to "know" this is the schema that
defines the "interface" element.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Oct 2006 08:32:33 -0700

>>    in a NETCONF PDU.  There is no default namespace associated with

/rpc for RPC methods and <error-path>

relative root <config> == <data> == <filter>, etc.) for data

> Stick w/ xpath syntax and use "and":

OK

> function that does approximately the same thing (origin 1).

OK

> I don't follow you here.  Why would an xpath originated at

It is needed to identify the bad parameter, which could
be <error-option> just as well as something in the data
underneath <config>

> defines the "interface" element.

Yes we do need that to tell the tools about the data structure.
We do not need that to identify data instances within <error-path>
elements.  Using a common format for a conceptual instance identifier
is useful beyond this 1 element of course, but currently out of scope.
But if we decide to create a standard 'config-change' notification,
then it will be useful to identify what changed without returning
all the changed XML.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Oct 2006 09:05:35 -0700

Hi Phil,

....
>>    /foo/bar[x="3",y="4"]/baz[name="fred"]/zoo/goo[position="3"]

Xpath position() is 1 .. N based, and does not seem to be needed:

   /foo/goo[position()=3]  ==  /foo/goo[3]

So this example should be:

   /foo/bar[x=3 and y=4]/baz[name='fred']/zoo/goo[3]

I like concise 'C' style syntax better of course:

   foo.bar[3,4].baz[fred].zoo.goo[2]

but it isn't XMLish enough, so never mind.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Oct 2006 18:39:45 +0200

> because an instance identifier is just an absolute Xpath expression.

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. Personally, I believe this is fine since I disliked the
introduction of subtree filtering in the first place...

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Oct 2006 18:54:11 +0200 (CEST)

> because an instance identifier is just an absolute Xpath expression.

With the XPath fixes already suggested, I think this is excellent.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Oct 2006 19:49:31 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> 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.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Oct 2006 20:49:25 +0200

> 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).

I strongly dislike an approach where certain xpath features (like
position()) may only be used under some conditions. Given the SMIv2
experience with special cases and the implied consistency language
rules, I strongly prefer to avoid special case constructions.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Oct 2006 12:06:38 -0700

> rules, I strongly prefer to avoid special case constructions.

IMO we want the simplest approach possible.
This does not impact <filter type="xpath"> in PDUs.
It is a simple canonical format for identifying ONE instance of an element.
It is not intended to be some sort of filtering tool.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Oct 2006 21:05:29 +0200 (CEST)

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

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.

> 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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Oct 2006 12:24:57 -0700

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

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Oct 2006 12:40:42 -0700

Juergen Schoenwaelder wrote:
> On Mon, Oct 16, 2006 at 12:06:38PM -0700, Andy Bierman wrote:
>  
> Without specifying how you measure simplicity, your statement is
> rather pointless.
> 
> A framework which allows to identify instances in some language X (and
> uses this language for say error reporting and access control) and has
> a required to implement a filter language which supports a filtering
> language Y where the expressive power of Y is a true subset of X seems
> a bit, lets say, surprising. Once again, I like X and I do believe Y
> will be overcome anyway if netconf is going to be successful. (So I
> better stop here since I believe the issue is pretty clear.)

We don't have 2 languages X and Y.
We have a constrained algorithm for using Xpath to represent
an Instance Identifier.

I didn't think we needed to discuss all the functional requirements
for an Instance Identifier, but let's try:

   - non-ambiguous, deterministic, canonical format
   - identifies a single instance in a static manner
     (Note that all filter expressions can yield different results
      based on when they are applied to the underlying datastore.
      We want an Instance ID to have 0 or 1 matches
      - An instance ID could be thought of as just an Xpath filter
        that selects a single instance, based solely on the data model
        naming components and element position.)
   - persistence:
     We would like an Instance ID 'match' at time T0 and later time T1
     to represent the same conceptual instance.  (Insert long debate
     about discontinuity markers here.)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Oct 2006 21:36:05 +0200

> interfaces might come and go.

Oh, this is a classic. I concluded several years ago that there is
simply no way to get this naming right (and I am ignoring the fact
that on some systems you can arbitrarily rename interfaces - did you
ever see what xen 3.0 does to your interfaces when it boots?). How you
best refer to an interface is really something you can only answer
when you understand the purpose of the reference. There are valid
reasons to sometimes refer to an interface with a given name, sometime
you like to refer to an interface with a given address, sometimes you
really like to refer to an interface whose alias matches a certain
regex, sometimes you might have a valid reason to refer to the 2nd
interface. The nice thing about netconf is that it does allow some
freedom which is a clear step ahead of what SNMP gave us.
 
> use it anywhere in the Instance Identifier?

The later. The set of valid xpath constructs needs to be defined and
what belongs to this set should be valid everywhere. Back at the time
when we discussed filtering, I suggested an xpath subset to be used.
Some other IETF WG has adopted a similar approach and they even
defined the subset - I would have to dig to find the reference - it is
somewhere in the netconf archive. The XML directorate might also
know...

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Oct 2006 21:26:21 +0200

/js

---

From: Cridlig Vincent <[email-masked]>
Date: Tue, 17 Oct 2006 07:50:42 +0200

Hi,

The following document might be of interest for this thread. It 
discusses location in XML context.
http://www.xml.com/pub/a/2004/11/24/py-xml.html

------
Switching to developer mode, it would take two lines for me to build 
this absolute XPath exp !  ;-)
from amara import domtools
domtools.abs_path(node)
------

Regards,
Vincent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Oct 2006 09:49:44 +0200

> We have a constrained algorithm for using Xpath to represent

Andy,

a system which says "here is a name for an instance" and which does
not subsequently allow me to retrieve this instance under that name is
kind of odd, do you not think so?

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Oct 2006 02:17:17 -0700

> kind of odd, do you not think so?

Yes, but that's not what we have.

<rpc>
   <get>
     <filter type="xpath" select="instance-ID-expr"/>
   </get>
</rpc>

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Oct 2006 02:22:08 -0700

>...

IMO, having 1 way to declare a construct is simpler
than 3 or ways to define a construct, plus defining
mappings between all the variants, plus defining algorithms
for picking a canonical variant.

(But this is XML, and when you only have one big clumsy hammer,
you better just smash away, and expect everything you hit to
be a nail...)

Andy