Subject: [netmod] charter revision - please comment on charter-ietf-netmod-06-05

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 2 Feb 2014 14:56:10 +0100

Hi,

we (the WG chairs and Benoit) have been working on a new charter for
the NETMOD working group. The current version can always be found
here.

  https://datatracker.ietf.org/doc/charter-ietf-netmod/

The current version is called charter-ietf-netmod-06-05

  https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt

Please review and feel invited to comment and ask questions.

/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: Andy Bierman <[email-masked]>
Date: Sun, 2 Feb 2014 07:27:38 -0800

Hi,

Since the WG already agreed that adding new XPath functions
cannot be done without changing the YANG language version,
I think the charter needs to be clear that a new YANG language
version is being developed, that is not backward compatible with
the existing version.

IMO, the cost of introducing a new YANG version is too high
just so a few XPath functions can be introduced. As soon as the
line "yang-version 1.1;" is added to the module, every existing
YANG tool is going to reject the module.  The operational
impact of a new language version is unavoidable, whether we add
1 new feature or 100.

There are many small improvements or nice-to-have features
we could add, but nothing really important (short of YANG++).
IMO the NETMOD WG should be working on things that add to
the usefulness of YANG 1.0, such as YANG Conformance +
ACL + and topology modules.

Andy

On Sun, Feb 2, 2014 at 5:56 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 2 Feb 2014 08:35:04 -0800

Hi,

I changed my mind -- if the charter item was called
YANG 1.1 Maintenance Version, that would be OK.
All bug-fixes (when-stmt, etc.) and very minor enhancements
should be on the table, subject to WG consensus.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Feb 2014 22:21:29 +0100 (CET)

> Please review and feel invited to comment and ask questions.

I think that in order to solve Y1 and Y3, we need an update to YANG.
Since the proposed charter allows us to this, I guess the charter is
ok.

Regarding Y3 (YANG conformance), I don't think it is clear what
problem we want to solve.  In my experience, I have not seen the
interoperability problems Andy's draft mentions.  The draft raises
some valid issues (e.g., hello message size explosion and if-feature
with AND as only operator is too limiting), but I am not convinced
that the current conformance mechanisms of YANG are not good enough.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 3 Feb 2014 13:40:00 -0800

> that the current conformance mechanisms of YANG are not good enough.
I do not agree that Y3 would require an update to YANG
that would impact the yang "module" and "submodule"
constructions.  None of the items in the charter proposal
are must-have features.  IMO, service-oriented conformance
is better than the implied-mandatory + if-feature conformance
model we have now.

I have never actually seen the "identityref conflict" problem that
the xpath functions need to address. Sure it is possible that
a server will have 2 modules, each with the same named
identity, each with the same base type, but I have never seen it actually
done.

There are several known issues with YANG that actually impact usage,
and more XPath functions are fairly low on the list.  We are not helping
anyone by introducing a new YANG version with 1 of 10 known bugs fixed.
Might as well fix all 10 if we bother with a YANG 1.1 release at all.

IMO there are better things to work on, but a new YANG version just
to introduce a few XPath functions would be net harmful to interoperability

/martin
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Feb 2014 22:52:06 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> constructions.

RFC 6020 says that a server MUST advertise the module namespace URI to
indicate support for a module.  I think your draft says that instead
of doing that, the server can advertise a package.  This changes RFC
6020 (yes, it does not change YANG syntax, but it sure impacts
existing clients).

[...]

> We are not helping

Agreed.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 3 Feb 2014 14:20:06 -0800

> 6020 (yes, it does not change YANG syntax, but it sure impacts

No -- I was wrong about that.
I think that text was in a slide at the IETF but not in the draft.
There is no text that says the server does not send module URIs.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Feb 2014 23:26:10 +0100 (CET)

> There is no text that says the server does not send module URIs.

Ok.  Then I agree an update to YANG is not necessary.  But then it
also doesn't solve the hello message size problem... :(

But... if all 6020-compliant module capabilities are advertised, what
information in the package can the client use that is not in the
normal module advertisment (and doesn't break 6020 rules)?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 3 Feb 2014 14:39:01 -0800

> also doesn't solve the hello message size problem... :(
Unless the client <hello> message has some indication
that the client knows YANG 1.1 then the server cannot send
the abbreviated <hello> (in the NETCONF-EX draft).

> normal module advertisment (and doesn't break 6020 rules)?

Some basic stuff like import-only vs. conformance.
Some fancy stuff like multi-module service profiles.
IMO we will already these features if you count all
the vendor modules.

We could do the work in phases:

phase 1) address the real deficiencies with the current conformance
phase 2) develop reusable service level conformance abstraction mechanisms

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 04 Feb 2014 10:19:21 +0100 (CET)

> the abbreviated <hello> (in the NETCONF-EX draft).

That's what I was saying - if we want to change what's advertised, we
need to update 6020.

If a prerequisite is that we don't update 6020, I don't think we can
much about the problems listed in your draft.

> Some basic stuff like import-only vs. conformance.

I think it must be clear from the YANG spec what it means to advertise
a module.  If this is not clear we need to fix that in the spec.

> phase 2) develop reusable service level conformance abstraction mechanisms

I think this makes sense.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 04 Feb 2014 10:33:11 +0100

Hi,

I like the charter and I have two questions/comments:

1. One of the aims of YANG 1.1 should be to relax the limitation of YANG to NETCONF, as a reaction to the recent developments (RESTCONF, I2RS and a few projects outside IETF).

2. Is it intentional that no specific new data models are mentioned, except the stateless packet filter example? A few items are already on the table.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Feb 2014 10:42:58 +0100

> 2. Is it intentional that no specific new data models are mentioned, except the stateless packet filter example? A few items are already on the table.

The idea was to let the charter be flexible such that the WG can take
on data models without having to recharter. From what has been
proposed, the stateless packet filter work seems to be a relatively
clear cut case.  The topology work interacts with the information
model work submitted by the same authors to I2RS so it seems we need
to figure out where this work will be entertained. The other proposals
do not really seem to be mature enough to work on them at this point
in time.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 4 Feb 2014 11:02:19 +0100

> on data models without having to recharter. From what has been

OK, it this is possible, then it’s fine.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 04 Feb 2014 11:19:02 +0100

> to introduce a few XPath functions would be net harmful to interoperability

I don't agree. There are other things in the 1.1 todo list but even the XPath functions are a good-enough reason. The main problem IMO are identities because currently they are essentially usable only if they are flat, i.e. a base identity and identities derived directly form it, and nothing else.

For example, in a real Ethernet module that is modelled after Appendix A in the interfaces I-D, the condition

when "if:type = 'ianaift:ethernetCsmacd'";

won't work for Ethernet interfaces whose type is *derived* from ethernetCsmacd.

Combined with the limited extensibility of enumerations, this is a serious problem.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Feb 2014 03:43:09 -0800

On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka <[email-masked]> wrote:

> I don't agree. There are other things in the 1.1 todo list but even the
> XPath functions are a good-enough reason. The main problem IMO are
> identities because currently they are essentially usable only if they are
> flat, i.e. a base identity and identities derived directly form it, and
> nothing else.
>
If it were a serious problem then we would see it showing up
in real implementations.  In fact, this problem has never occurred
even once -- not in standard modules or vendor modules.
The local names have to be for the same base.  If not, the tool
knows (because the leaf includes the base identity type).
In theory this XPath cannot possibly work.  In reality it works OK.

Lada

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Feb 2014 03:48:52 -0800

On Tue, Feb 4, 2014 at 1:19 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund <[email-masked]
> >
> > > wrote:
> > > > > >
> > > > > > > > we (the WG chairs and Benoit) have been working on a new
> charter
> > > for
> > > > > > > Since the proposed charter allows us to this, I guess the
> charter
> > > is
> > > > > > > ok.
> > > > > > >
Even if we update RFC 6020, the server has to be sure the client
supports the update before sending a new <hello>.  The problem
of the server delaying its <hello> to wait for the client does not
go away no matter what happens wit YANG 1.1.

> a module.  If this is not clear we need to fix that in the spec.

It is clear now -- clearly broken.
If a module has a container and a typedef then if the server uses
the typedef it also is telling the client it implements the container.
The YANG export model needs to be more flexible than that.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 04 Feb 2014 12:57:37 +0100 (CET)

> go away no matter what happens wit YANG 1.1.

There might be other solutions to the compressed hello message than
the one presented in the netconf ex draft.  For example, the server
could advertise a package, and then the package contains all
modules.  But this requires a change to 6020, which was my original
point.

> The YANG export model needs to be more flexible than that.

So you agree that the conformance draft does not help here - we need
to fix 6020?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 04 Feb 2014 13:08:20 +0100 (CET)

> even once -- not in standard modules or vendor modules.

This is weird logic.  Of course there are no modules that tries to do
a "derived-from" when expression, since there is no such thing as a
"derived-from" when expression.

The fact is that we now have a module for interfaces where the
interface type is an identity.  The next step is to define
interface-type-specific modules, probably vendor-defined first.  In
this design proccess, we have run into the problem of not having a
"derived from" function, as Lada has explained.

Noone has claimed this problem to be something else than this.  Call
it a theoretical problem if you like.  The question is if the WG
thinks it is important enough to work on a solution.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Feb 2014 04:16:50 -0800

On Tue, Feb 4, 2014 at 3:57 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > > > On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund <[email-masked]
> >
> > > wrote:
> > > > > >
> > > > > > > > > Juergen Schoenwaelder <
> > > > > > > > > > the NETMOD working group. The current version can always
> be
> > > found
> > > > > > > > > > here.
> > > > > > > > > >
> > > > > > > > > I think that in order to solve Y1 and Y3, we need an
> update to
> > > > > YANG.
> > > > > > > > > problem we want to solve.  In my experience, I have not
> seen
> > > the
> > > > > > > > > that the current conformance mechanisms of YANG are not
> good
> > > > > enough.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > of doing that, the server can advertise a package.  This
> changes
> > > RFC
No -- we could add data to the ietf-netconf-monitoring module to help
clients clarify the module usage within the server.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Feb 2014 04:22:15 -0800

On Tue, Feb 4, 2014 at 4:08 AM, Martin Bjorklund <[email-masked]> wrote:

> > > For example, in a real Ethernet module that is modelled after Appendix
> A
> > > in the interfaces I-D, the condition
> > >
> > > Combined with the limited extensibility of enumerations, this is a
> serious
> > > problem.
> > >
> > >
The need to specify the qualified name instead of just the local name
is the issue.  In theory, yes this has to be fixed. In reality, duplicate
identities
from different modules for the same base type do not exist.

/martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 04 Feb 2014 13:30:42 +0100 (CET)

> from different modules for the same base type do not exist.

That's not the issue.  Please read Lada's explanation.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 4 Feb 2014 13:30:57 +0100

> even once -- not in standard modules or vendor modules.

I have just run into it. I am developing a module for the NetIDE project - it is supposed to capture network topology and behaviour. In the topology part, I need to distinguish between networks and end-hosts at the base level, but at other levels end-hosts are further divided into hosts, routers, switches etc.
So the desired hierarchy of identities is

node
  network
  end-system
    host
    router
    switch

And it is impossible to use “when” for distinguishing between “network” and “end-system” because end hosts are configured with the leaf identities.  

> In theory this XPath cannot possibly work.  In reality it works OK.

Hey, you already have these XPath extensions in Yuma, right? I don’t want to get into a situation like “This module was optimized for software XY”.

Lada

---

From: Jonathan Hansford <[email-masked]>
Date: Tue, 04 Feb 2014 12:53:38 +0000

On 2014-02-04 11:43, Andy Bierman wrote: 

> On Tue, Feb 4, 2014 at
2:19 AM, Ladislav Lhotka <[email-masked] [6]> wrote:
>> Andy Bierman
<[email-masked] [1]> writes:
>> 
>> > On Mon, Feb 3, 2014 at 1:21
PM, Martin Bjorklund <[email-masked] [2]> wrote:
>> >> Juergen
Schoenwaelder <[email-masked] [3]> wrote:
Hi,
>> >> > the NETMOD working group. The current version
can always be found
https://datatracker.ietf.org/doc/charter-ietf-netmod/ [4]
[5]
>> >> Regarding Y3 (YANG
conformance), I don't think it is clear what
>> >> problem we want to
solve. In my experience, I have not seen the
>> >> interoperability
problems Andy's draft mentions. The draft raises
>> >> some valid issues
(e.g., hello message size explosion and if-feature
>> >> with AND as
only operator is too limiting), but I am not convinced
>> >> that the
current conformance mechanisms of YANG are not good enough.
>> > are
must-have features. IMO, service-oriented conformance
>> > is better
than the implied-mandatory + if-feature conformance
>> > model we have
now.
>> > and more XPath functions are
fairly low on the list. We are not helping
>> > anyone by introducing a
new YANG version with 1 of 10 known bugs fixed.
>> > Might as well fix
all 10 if we bother with a YANG 1.1 release at all.
>> > IMO there
are better things to work on, but a new YANG version just
>> > to
introduce a few XPath functions would be net harmful to
interoperability
>> 
>> I don't agree. There are other things in the 1.1
todo list but even the XPath functions are a good-enough reason. The
main problem IMO are identities because currently they are essentially
usable only if they are flat, i.e. a base identity and identities
derived directly form it, and nothing else.
>> For example, in a
real Ethernet module that is modelled after Appendix A in the interfaces
I-D, the condition

> In theory this XPath cannot possibly work. In reality
it works OK.

For someone who is still trying to get his company to
migrate to YANG and has therefore still not had the opportunity to use
it in anger, that last sentence doesn't inspire confidence. For any who
are new to implementing YANG, being advised that something that "cannot
possibly work ... in reality works OK" just engenders a sense of
uncertainty, not just about this but whether there are other areas of
YANG where uncertainty lurks. 

> Andy

Links:
------
[1]
mailto:[email-masked]
[2] mailto:[email-masked]
[3]
mailto:[email-masked]
[4]
https://datatracker.ietf.org/doc/charter-ietf-netmod/
[5]
https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt
[6]
mailto:[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Feb 2014 05:28:50 -0800

On Tue, Feb 4, 2014 at 4:30 AM, Ladislav Lhotka <[email-masked]> wrote:

> serious problem.
> I have just run into it. I am developing a module for the NetIDE project -
> it is supposed to capture network topology and behaviour. In the topology
> part, I need to distinguish between networks and end-hosts at the base
> level, but at other levels end-hosts are further divided into hosts,
> routers, switches etc.
> And it is impossible to use "when" for distinguishing between "network"
> and "end-system" because end hosts are configured with the leaf identities.
>
>

The issue comes down to custom XPath work

   when "ident-leaf = 'network'";

The Yuma* code knows this string (network) is really a QName and not a
string.
So if the when-stmt had a prefix, it would be handled correctly:

  when "ident-leaf = 'acme:network'";

We agree standard XPath tools do not know this string is really a QName.
In practice, there are not multiple related identities with the same local
name (e.g., example:network and acme:network are both valid
identities for this leaf).

Since no off-the-shelf XPath tools support this new "derived-from" function,
this is still an academic solution. New code is needed in any case.

I am not against fixing this issue, but it is not important enough by itself
to justify a new YANG version.

> Hey, you already have these XPath extensions in Yuma, right? I don't want
> to get into a situation like "This module was optimized for software XY".
>
>
Once we start adding "yang-version 1.1;" to YANG modules, designers will be
making the choice
to not support old tools at all. Will we have 1.0 modules attempting to
import 1.1 modules? Vice versa?
How do both language versions co-exist in the same client or server?  The
operational impact
of a new language version roll-out is going to be severe.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 4 Feb 2014 14:48:48 +0100

On 04 Feb 2014, at 14:28, Andy Bierman <[email-masked]> wrote:

> The Yuma* code knows this string (network) is really a QName and not a string.
>   when "ident-leaf = 'acme:network’";

But it is not about strings versus QNames! The problem is that the parent augment is supposed to be applied to nodes whose type is *derived* from network, for example “acme:router”. This is where the derived-from() function is needed.

> Once we start adding "yang-version 1.1;" to YANG modules, designers will be making the choice
> to not support old tools at all. Will we have 1.0 modules attempting to import 1.1 modules? Vice versa?
> How do both language versions co-exist in the same client or server?  The operational impact

It seems you are not against fixing things under the hood, you just don’t want to admit it officially by bumping the version number - presumably because then even managers can get the message that YANG may not be as stable as it is claimed.

My concern is that this tactic will lead to various ugly hacks and hidden incompatibilities.

As much as I like YANG, developing a new language does have some costs. We could hardly expect to get everything right at the first attempt.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Feb 2014 06:09:29 -0800

On Tue, Feb 4, 2014 at 5:48 AM, Ladislav Lhotka <[email-masked]> wrote:

> But it is not about strings versus QNames! The problem is that the parent
> augment is supposed to be applied to nodes whose type is *derived* from
> network, for example "acme:router". This is where the derived-from()
> function is needed.
>
>
OK -- this seems like a very minor feature.
Originally the identyref is just for comparing the same base
identity types.  The ability to compare against sub-trees in the
identity hierarchy is a new feature.

> > Hey, you already have these XPath extensions in Yuma, right? I don't
> want to get into a situation like "This module was optimized for software
> XY".
> >
> >
> It seems you are not against fixing things under the hood, you just don't
> want to admit it officially by bumping the version number - presumably
> because then even managers can get the message that YANG may not be as
> stable as it is claimed.
>
> As much as I like YANG, developing a new language does have some costs. We
> could hardly expect to get everything right at the first attempt.
>
>

The hacks will come when developers comment out the "yang-version 1.1;"
because they cannot ignore the module and they cannot upgrade
all their tools at once either. The hacks will come when developers
make ad-hoc choices converting 1.1 modules back to 1.0 so they
can be usable by their old tools.

I accept that we have to bump the version number to make
changes that break YANG 1.0 assumptions.  I also realize
just how expensive that change will be to deployment.  We went through
this already in SNMP-land.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 04 Feb 2014 15:18:19 +0100 (CET)

> identity hierarchy is a new feature.

No, not a new feature.  identityref accepts any identity derived from
the base.  We got that part right.  It's the corresponding XPath test
we missed.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Feb 2014 06:37:34 -0800

On Tue, Feb 4, 2014 at 4:53 AM, Jonathan Hansford <[email-masked]>wrote:

>   For someone who is still trying to get his company to migrate to YANG
> and has therefore still not had the opportunity to use it in anger, that
> last sentence doesn't inspire confidence. For any who are new to
> implementing YANG, being advised that something that "cannot possibly work
> ... in reality works OK" just engenders a sense of uncertainty, not just
> about this but whether there are other areas of YANG where uncertainty
> lurks.
>

This is the conflict:

module A {
  identity foo-base;
  identity foo1 {
    base foo-base;
  }
}

module B {
   import A { prefix a; ]
   identify foo1 { base a:foo-base; }
}

module C {
  import A { prefix a; }
  leaf ident-leaf {
     type identityref { base a:foo-base; }
  }
  leaf X {
     when "../ident-leaf = 'foo1'";
     type string;
}

My previous point is the the duplication (e.g. foo1 in 2 modules) is
extremely
rare.

When the ident-leaf is referenced in XPath, it is a string, not a QName.
If the server advertises A, B, and C, then there is ambiguity for
the identity "foo1".  In fact the example for X is illegal because
no prefix for an identityref means the local module, and module C
does not define any "foo1" identity.

   when "../ident-leaf = 'a:foo1' or ../ident-leaf = 'b:foo1'";

This is not OK because it requires the XPath parser to know
these strings are really identity values.

    Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 4 Feb 2014 15:39:39 +0100

> the base.  We got that part right.  It's the corresponding XPath test

Yes. If I remember correctly, identities were introduced at the Herndon interim meeting back in 2008, and haven’t changed in any way since then.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 4 Feb 2014 15:53:02 +0100

On 04 Feb 2014, at 15:37, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Tue, Feb 4, 2014 at 4:53 AM, Jonathan Hansford <[email-masked]> wrote:
>  
> For someone who is still trying to get his company to migrate to YANG and has therefore still not had the opportunity to use it in anger, that last sentence doesn't inspire confidence. For any who are new to implementing YANG, being advised that something that "cannot possibly work ... in reality works OK" just engenders a sense of uncertainty, not just about this but whether there are other areas of YANG where uncertainty lurks.
> 
> 
> This is the conflict:
> 
> module A {
>   identity foo-base;
>   identity foo1 {
>     base foo-base;
>   }
> }
> 
> module B {
>    import A { prefix a; ]
> My previous point is the the duplication (e.g. foo1 in 2 modules) is extremely
> rare.
> 

A standard XPath processor cannot know it by definition. And this is still only a part of the story - I think the use of identityrefs in “when” expressions is only possible if both identities-as-qnames and the derivation relation are properly supported. 

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Feb 2014 07:27:57 -0800

On Tue, Feb 4, 2014 at 6:53 AM, Ladislav Lhotka <[email-masked]> wrote:

> A in the interfaces I-D, the condition
> >>
> A standard XPath processor cannot know it by definition. And this is still
> only a part of the story - I think the use of identityrefs in "when"
> expressions is only possible if both identities-as-qnames and the
> derivation relation are properly supported.
>
>
We are drifting into the implementation details.
I already agreed we should do a real maintenance update
so many YANG corner-cases will finally get solved.

We already have our own XPath within YANG modules.
We have plenty of text declaring how YANG types are treated
in XPath.  As Martin said, we did not decree how identityref
values SHALL be handled in YANG must/when statements.
This was an oversight. (Along with many others).

We could decree that identityref is a special string that no
XPath parser knows about or we could create a brand new
XPath function no XPath parser knows about.  Either way we
are making rules only for YANG statements, not all XPath.

This is a confusing problem because we are highjacking QNames
here. There are not real nodes in any XML document for identities
They are just registration OIDs.  (We had the same problem in
SNMP trying to mix the 2).

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 4 Feb 2014 17:07:32 +0100

> in XPath.  As Martin said, we did not decree how identityref

Plenty? I am aware of three things:

1. The default namespace a la XPath 2.0 (sec. 6.4.1),

2. XPath comparisons are done on the canonical form (sec. 7.5.3),

3. The current() function.

Other than that, it should be standard XPath 1.0.

> XPath function no XPath parser knows about.  Either way we

XPath 1 spec permits the latter but not the former. And XPath/XSLT processors can often be extended to support additional functions. 

> here. There are not real nodes in any XML document for identities

This is nothing unusual:

http://www.w3.org/2001/tag/doc/qnameids

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Feb 2014 08:46:15 -0800

On Tue, Feb 4, 2014 at 8:07 AM, Ladislav Lhotka <[email-masked]> wrote:

> > >> I don't agree. There are other things in the 1.1 todo list but even
> the XPath functions are a good-enough reason. The main problem IMO are
> > >> For example, in a real Ethernet module that is modelled after
> Appendix A in the interfaces I-D, the condition
> > >>
> > A standard XPath processor cannot know it by definition. And this is
> still only a part of the story - I think the use of identityrefs in "when"
What about the prefix mappings to imports and missing prefix mapping
to the current module?  That requires special code to handle.

> XPath 1 spec permits the latter but not the former. And XPath/XSLT
> processors can often be extended to support additional functions.
>

This does not seem to use QNames on the right hand side of the expressions.
I agree XPath functions are the correct way to add custom features to
an XPath parser.

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 4 Feb 2014 19:18:18 +0000

I also agree that the WG should be flexible to take on new data models without having to recharter.  The current wording does not seem to express this clearly; I had the same question as Lada and think some clarification would be good.
--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Tuesday, February 04, 2014 2:02 AM
To: Jürgen Schönwälder
Cc: [email-masked]
Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05

> on data models without having to recharter. From what has been

OK, it this is possible, then it's fine.

Lada

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 4 Feb 2014 19:29:46 +0000

We have internally run into the issue where the fact that we could not articulate a condition that validated if an identityref referred an identity with a certain base identity was a limitation.  If you make use of identity hierarchies several levels deep, this is a valid issue that can occur.
--- Alex

...

---

From: Benoit Claise <[email-masked]>
Date: Mon, 17 Feb 2014 15:26:29 +0000

Hi Alex,
> I also agree that the WG should be flexible to take on new data models without having to recharter.  The current wording does not seem to express this clearly; I had the same question as Lada and t…
I believe that this is covered by:

    ... and developing data
    models that are considered core building blocks and that do not
    fall into charters of other active IETF working groups (for example
    a data model for stateless packet filters).

Regards, Benoit

> .