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

[Martin Bjorklund <[e-mail]>]

Jernej Tuljak <[e-mail]> 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...


/martin