Subject: [netmod] Consensus call (YANG types) - Name of xpath datatype

From: David Partain <[email-masked]>
Date: Fri, 17 Apr 2009 08:31:53 +0200

Hi all,

Should the 'xpath' datatype be renamed to 'xpath1', 'xpath1-0' or
'xpath1.0' to accommodate definitions of other XPath versions in
the future?

At the recent IETF, rough consensus was reached to rename the
type xpath1.0.

If you disagree with this consensus, speak now or forever hold
your peace.

D^2

---

From: Phil Shafer <[email-masked]>
Date: Fri, 17 Apr 2009 09:40:31 -0400

>At the recent IETF, rough consensus was reached to rename the

I am not hung up on this, but it sure seems odd that this is
the only place we call out the "1.0"-ness of our xpaths.  We
use xpath-1.0 for all sorts of YANG constructs.  Would we
be better served by calling this "xpath" and adding "2.0"
suffix when and if we ever move to 2.0?  We'll need "must2.0"
and "when2.0", etc, at the time also.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Apr 2009 08:17:58 -0700

> and "when2.0", etc, at the time also.

I agree.
I also prefer not to encourage use of the '.' char in identifiers.

>  Phil

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Apr 2009 17:27:10 +0200

> and "when2.0", etc, at the time also.

One thing to keep in mind is that YANG data models will be written for
non-NETCONF things and the need for an xpath 2.0 type might arise even
if NETCONF never ever uses xpath 2.0 itself.

I am not opposing to call the typedef just xpath (like Andy I dislike
the dots in identifiers) - I just have a problem with the argument you
are bringing up. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 Apr 2009 17:52:30 +0200

> if NETCONF never ever uses xpath 2.0 itself.

An option would be to use "xpath" for the type name and specify version
in "version" substatement, for example

leaf foo {
    type xpath {
        version 2.0;
    }
}

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Apr 2009 08:56:45 -0700

> the dots in identifiers) - I just have a problem with the argument you

The main issue is the one Phil raised.
We aren't versioning all the little pieces of YANG 1.0.

If YANG needs to be written for non-NETCONF things then
we should read about it in the NETMOD arch draft.

If we ever add an :xpath2 capability to NETCONF, then
an xpath2 data type can be added at the same time.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Apr 2009 18:27:04 +0200

> in "version" substatement, for example

Are you serious? Adding another complexity dimension to our already
versioned includes??

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Apr 2009 18:33:46 +0200

> We aren't versioning all the little pieces of YANG 1.0.

If we do IPv8, we do not need to change NETCONF nor YANG but we do
need an IPv8 data type. My point is that the versioning of data type
definitions is independent of the versioning of NETCONF or YANG. With
xpath, we already know for sure that there are two versions out there
and that is why I asked to consider this when I wrote the xpath
typedef.
 
> we should read about it in the NETMOD arch draft.

I was talking about YANG data models to configure protocols (e.g. a
potential future version of EPP) that use xpath 2.0. I believe such a
data model is in scope of YANG and does not require text in the NETMOD
arch draft.

Anyway, I am fine with xpath as well. I just think Phil's argument was
not quite convincing.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 Apr 2009 23:31:00 +0200

> Are you serious? Adding another complexity dimension to our already

Yes, if you are serious about leaving space for XPath 2.0. Why is it
less complex to introduce two separate datatypes? In 99 % cases, users
will just use "type xpath;".

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Apr 2009 23:45:48 +0200

On Fri, Apr 17, 2009 at 11:31:00PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v P?? 17. 04. 2009 v 18:27 +0200:
> less complex to introduce two separate datatypes?

Its less complex because I can do this with YANG today and I do not
need yet another language feature. We are not here to build the most
beautiful and most complex language. At least I am not.

> In 99 % cases, users will just use "type xpath;".

And this is actually the big argument in favour of the name xpath-1.0
- the type name tells you what you get and makes people think whether
they actually want what they get.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Apr 2009 14:47:26 -0700

> will just use "type xpath;".

I agree with Juergen.
This is way too much flexibility and complexity.
In standards, it is good to remove these things whenever
possible, not add them.

Since this 'xpath' data type is nothing but
a derived string and nothing special at all in YANG,
there is nothing preventing any WG or vendor from
making their own 'xpath2', 'myxpath', or whatever.

Sorry for over-reacting, but I really dislike it when IETF WGs
back into architectural or protocol decisions via some second
or third order problem.

If XPath 2.0 needs to be supported, and needs to be available
as a data type for all protocols that use YANG, then that decision
should be made first.  Then decide how to do it.

Since standard NETCONF cannot support this data type at all,
and no other protocols are planning to use YANG,
there seems little reason to add it now.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Apr 2009 14:53:14 -0700

> they actually want what they get.

good point.
is this 'xpath' really XPath 1.0 or is it the 'special' YANG XPath 1.0
plus the current() function from XPath 2.0?

Because I implemented YANG XPath 1.0, so I want to know if I need
a special data type for that, or if this one covers it.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 18 Apr 2009 10:29:31 +0200

> a special data type for that, or if this one covers it.

Very good point. Right now, the definition says:

   typedef xpath {
     type string;
     description
      "This type represents an XPATH 1.0 expression.";
     reference
      "W3C REC-xpath-19991116: XML Path Language (XPath) Version 1.0";
   }

So this is right now pretty much XPATH 1.0 (but I would have to read
the XPATH specs to figure out whether custom functions like current()
can be dealt with in XPATH 1.0). It seems we likely already have three
xpath versions to deal with. The question is to what extend we have to
distinguish them by having different typedefs.

Another possible alternative could be that we write down in the
description clause of the xpath typedef that this type represents any
xpath expression and that objects using the type must specify which
xpath version is meant or people create a derived type for that:

module netconf {

   import yang-types { prefix yang; }

   typedef xpath-netconf { 
       type yang:xpath;
       description
          "This is xpath 1.0 with the netconf extensions...";
   }

   // ...

}

This way we have a common xpath type and we can add commonly used
subtypes (xpath-1.0, xpath-2.0, xpath-yang, ...) once we know we need
them.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 18 Apr 2009 05:04:39 -0700

> subtypes (xpath-1.0, xpath-2.0, xpath-yang, ...) once we know we need

It's the ... part that worries me.
Can't we start out in YANG 1.0 with 1 xpath data type?
Don't we want everybody to implement YANG XPath?
If they do more than the YANG standard requires,
then NETCONF capabilities could be used to tell them apart.
(Unless we want implementations to support xpath1 for /foo,
xpath2 for /bar, xpath-fred for /foobar, xpath-barney for /fubar...)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 19 Apr 2009 23:54:40 +0200

> xpath2 for /bar, xpath-fred for /foobar, xpath-barney for /fubar...)

You seem to confuse NETCONF, YANG, and the data models defined in YANG
and manipulated using NETCONF. We will likely see variants of XPath in
_data models_ of other protocols that are to be managed using NETCONF
and YANG. (XCON for example uses a restricted suset of XPath 1.0).

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 19 Apr 2009 16:01:42 -0700

> and YANG. (XCON for example uses a restricted suset of XPath 1.0).

Not really.
I don't see why I would have a leaf in the 'fred-XPath'
expression language if I didn't have some support for that
XPath dialect somewhere in the tool.

I don't care if there are 3 types (xpath1, xpath2, xpath-yang)
all derived from the common 'xpath' typedef.  I don't think
many NETCONF agents support XPath 1.0 properly, so it's a really
minor issue to think about XPath 2.0 at all here.

But perhaps it is being used outside of NETCONF -- I don't know.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Apr 2009 08:09:24 +0200

> beautiful and most complex language. At least I am not.

I think ANY use of XPath expressions in configuration data is a big
complication in the first place, even instance-identifier. I would
certainly prefer the way how cross-references are normally dealt with in
XML, i.e., via xml:id labels.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 Apr 2009 08:29:20 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> complication in the first place, even instance-identifier.

This type is already used in some YANG modules defining rpc
operations.

Also, there are at least two proprietary access control modules for
NETCONF that I know of that use a restricted form of XPath (or
instance-identifier).  These are configuration data models.

So I think we need to keep this data type, and we need to solve the
naming issue.

I (still) think the name should be xpath-1.0, and the lexical space
should be all syntactically valid XPath 1.0 expressions.  This
includes any "extra" functions, and it includes variables.  Just like
with XPath in general, when this type is used, the description clause
will have to specify which functions and variables are valid.

If/when an XPath 2.0 type is needed, we can add it.  Note that not all
XPath 1.0 expressions are syntactically valid XPath 2.0.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Apr 2009 08:34:18 +0200

> XML, i.e., via xml:id labels.

I am trying to come up with common typedefs that are broadly
applicable - I thought this was the goal of the common data types
document. I prefer to leave the decision to the designers of protocols
we are going to manage with NETCONF/YANG whether they want to use
XPath or not, which version/subset/superset of XPath, and for which
purpose.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Apr 2009 09:25:38 +0200

> This type is already used in some YANG modules defining rpc

Yes, XPath is needed in RPC operations, but IMO not in configuration
data. So how about having "xpath" as a (properly defined) built-in type
instead of less general "instance-identifier", but restrict it only for
use in RPC definitions? The same "xpath" type then could be used
with :xpath capability in NETCONF.

> instance-identifier).  These are configuration data models.

This is not surprising given the SNMP/MIB/SMI heritage. My question is
whether the use of XPath is really necessary there or whether the same
effect could be possibly achieved via ID and IDREF.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Apr 2009 09:38:39 +0200

> with :xpath capability in NETCONF.

Xpath as a built-in type that can only be used in RPC definitions (a
true CLR) because there will never ever be an xpath expression in any
of data models to be written in the next 10-20 years???

I think we are not discussing built-in types at the moment.
 
> effect could be possibly achieved via ID and IDREF.

It does not matter whether you like or dislike usage of XPath in data
models - there is already some evidence that people will use XPath in
data models and inventing CLRs to prevent people from doing that is
not going to be very successful.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Apr 2009 10:06:24 +0200

> of data models to be written in the next 10-20 years???

XSD datatype library doesn't define any XPath-like type either.

> not going to be very successful.

The problems of XPath have been already extensively discussed here -
apart from the version and subset issue it is also the variability of
the root node. XPath as a general datatype is just a kind of rope that
already has a loop at its end.

Nothing prevents module designers from defining their "xpath" type as an
alias to string, if then want to, but then it's their business to define
what it really means.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Apr 2009 10:47:39 +0200

On Mon, Apr 20, 2009 at 10:06:24AM +0200, Ladislav Lhotka wrote:

> Nothing prevents module designers from defining their "xpath" type
> as an alias to string, if then want to, but then it's their business
> to define what it really means.

This is exactly what happened and instead of having to deal with N
different "xpath" types, the WG wanted to have a common definition in
yang-types.yang and this is what we are discussing.

The room's consensus at the last IETF meeting was to name the xpath
typedef (which happens to stand for XPath 1.0) to xpath-1.0. The
purpose of this thread was supposed to verify this consensus position.

- Martin still seems to support to the call the typedef xpath-1.0 and
  I am fine with this as well (especially is the type allows for
  custom functions like current()).

- Phil suggested to just use xpath (which implicitely stands for xpath
  1.0) and to add version numbers once we add more xpath definitions.
  It did not sound he objects against xpath-1.0 though (please correct
  me if I got this wrong).

- Lada posted several proposals ranging from adding version statements
  to typedefs over an xpath built-in type to don't use xpath at all.

- Andy wrote several messages and I am not sure where exactly he
  stands in this discussion.

It will help if others can comment as well and to have Andy and Lada
clarify their positions so that we can put this to bed and move on.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Apr 2009 11:28:32 +0200

> yang-types.yang and this is what we are discussing.

So if this "xpath" type is used within rpc output specification, is its
root node the top-level element inside the rpc reply or in the
configuration database? My point is that "xpath" (with version or
without) is a weasel data type that can lead to interoperability
problems.

>   to typedefs over an xpath built-in type to don't use xpath at all.

My position is:

1. Do not to define any "xpath" type in yang-types.

2. However, if there is evidence that such a type is needed (perhaps in
RPCs), I'd prefer to define it properly and carefully as a built-in
type.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Apr 2009 02:39:56 -0700

> clarify their positions so that we can put this to bed and move on.

I don't think there is agreement on the original
charter motivation for this data type.  This is just
a user-defined derived type for a string.
It is not a built-in type.  Anybody can
define as many xpath variants as they want.

I will still use my ncx:xpath extension no matter what
the WG does.  All I need is a tag indicating that
XML prefixes are in the content.  All the rest is
just noise.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Apr 2009 11:46:47 +0200

> define as many xpath variants as they want.

This is what the charter says:

6. A standard type library for use by YANG (proposed standard)

Are you saying we should not have a common data type library??
 
> XML prefixes are in the content.  All the rest is

So your position is "I do not care of what will be in
yang-types.yang"?

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Apr 2009 03:11:35 -0700

> So your position is "I do not care of what will be in

I do not think this RFC needs more than one xpath data type.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 20 Apr 2009 14:15:19 -0700

Hi -

> From: "Ladislav Lhotka" <[email-masked]>
> To: "Martin Bjorklund" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, April 20, 2009 12:25 AM
> Subject: Re: [netmod] Consensus call (YANG types) - Name of xpath datatype
...
> with :xpath capability in NETCONF.
...

What are the chances that access control policies will have XPath
expressions as part of their configuration data?

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Apr 2009 16:46:45 +0200

> expressions as part of their configuration data?

Is there any proposal about how such policies can be implemented?
Presumably it's not going to be part of YANG modules(?), so XPath might
be useful.

Lada
  
> 
> Randy
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C