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

On Mon, Oct 21, 2019 at 5:45 AM Martin Bjorklund <mbj@tail-f.com> wrote:

> Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
> > Should I clarify my question?
> >
> > Jernej
> >
> > On 10/10/2019 10:36, Jernej Tuljak wrote:
> > > 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?
>
> 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...
>
>
>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

> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>