Subject: [netmod] YANG 1.0 module uses a grouping from a 1.1 module and the grouping contains 1.1 XPath functions?

From: Jernej Tuljak <[email-masked]>
Date: Thu, 10 Oct 2019 10:36:15 +0200

Hi,

there is at least one YANG 1.0 standard module that imports and uses 
groupings from a YANG 1.1 standard module and at least one such grouping 
contains must/when statements referencing XPath functions that are not 
available in 1.0 XPath context.

The modules I'm referring to are part of RFC8533 [1] and RFC8532 [2]. 
ietf-connectionless-oam-methods (a 1.0 module) uses cl-oam:tp-address 
from ietf-connectionless-oam (a 1.1 module), which calls 
"derived-from-or-self" in a when expression of a used node. These RFCs 
were published in April.

Our tools complain about "derived-from-or-self" not being defined in 
ietf-connectionless-oam-methods's XPath context:

[Error]; 
ietf-connectionless-oam-methods@2019-04-16:/cloam-methods:continuity-check/cloam-methods:input/cloam-methods:destination-tp/cloam-methods:mac-address/cloam-methods:when; 
XPath function "derived-from-or-self" is not defined in the XPath context

Is this correct? Or are XPath functions expected to be resolved 
statically, like types?

Jernej

[1] - https://tools.ietf.org/html/rfc8533
[2] -https://tools.ietf.org/html/rfc8532

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 21 Oct 2019 14:32:30 +0200

Should I clarify my question?

Jernej

On 10/10/2019 10:36, Jernej Tuljak wrote:
> groupings from a YANG 1.1 standard module and at least one such 
> grouping contains must/when statements referencing XPath functions 
> that are not available in 1.0 XPath context.
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Oct 2019 14:45:20 +0200 (CEST)

Jernej Tuljak <[email-masked]> wrote:
> > The modules I'm referring to are part of RFC8533 [1] and RFC8532
> > [2]. ietf-connectionless-oam-methods (a 1.0 module) uses
> > cl-oam:tp-address from ietf-connectionless-oam (a 1.1 module), which
> > calls "derived-from-or-self" in a when expression of a used
> > node. These RFCs were published in April.
> >

I don't think it is correct to reject this construct.  The definition
is done in a 1.1 module and can only be implemented in a server that
supports 1.1.

It seems a bit odd that "ietf-connectionless-oam-methods" is defined
in YANG 1.0 though, but that's a different issue...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Oct 2019 09:12:09 -0700

On Mon, Oct 21, 2019 at 5:45 AM Martin Bjorklund <[email-masked]> wrote:

> > > ietf-connectionless-oam-methods@2019-04-16
> :/cloam-methods:continuity-check/cloam-methods:input/cloam-methods:destination-tp/cloam-methods:mac-address/cloam-methods:when;
>From 7950, sec 12:

      If a YANG version 1 module A imports module B without revision and

   module B is updated to YANG version 1.1, a server MAY implement both
   of these modules (A and B) at the same time.  In such cases, a
   NETCONF server MUST advertise both modules using the rules defined in
   Section 5.6.4 <https://tools.ietf.org/html/rfc7950#section-5.6.4>,
and SHOULD advertise module A and the latest revision
   of module B that is specified with YANG version 1 according to the
   rules defined in [RFC6020 <https://tools.ietf.org/html/rfc6020>].

   This rule exists in order to allow implementations of existing YANG
   version 1 modules together with YANG version 1.1 modules.  Without
   this rule, updating a single module to YANG version 1.1 would have a
   cascading effect on modules that import it, requiring all of them to
   also be updated to YANG version 1.1, and so on.

This is probably not implemented, or implementable, by many servers.

1) what if module 'B' has no latest YANG 1.0 revision?
    This can happen if A is updated to import B, but yang-version is not
changed in A

2) What if NBC changes have been made in module B?
    How does the cited text work with SEMVER and new versioning rules?

3) What if the server implements some new definitions in B that are not  in
the latest YANG 1.0 version of B?
    New YANG library does not allow more than 1 revision of an implemented
module to be represented in a module-set.

4) What if a leafref in A points to a leaf using a typedef in B, yet the
type is not allowed in YANG 1.0?
   (e.g., empty type in a union)?  How much YANG 1.1 is allowed to leak
into a YANG 1.0 module?)

5) Isn't module A parsed under YANG 1.0 rules, because its
yang-version-stmt is set to "1"?

> /martin
Andy

---

From: Robert Varga <[email-masked]>
Date: Wed, 30 Oct 2019 15:39:42 +0100

> Is this correct? Or are XPath functions expected to be resolved

My understanding of https://tools.ietf.org/html/rfc7950#section-6.4.1 is
that functions are bound the same way namespace prefixes are bound, i.e.
"in the module where the XPath expression is specified".

Regards,
Robert

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 30 Oct 2019 16:38:28 +0100

> "in the module where the XPath expression is specified".

We ended up adopting this interpretation.

Jernej