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

[Jernej Tuljak]

On 30/10/2019 15:39, Robert Varga wrote:

On 10/10/2019 10:36, Jernej Tuljak wrote:

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

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".


We ended up adopting this interpretation.

Jernej



Regards,
Robert



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

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

[Andy Bierman]

On Mon, Oct 21, 2019 at 5:45 AM Martin Bjorklund  wrote:

> Jernej Tuljak  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 ,
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 ].

   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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

Jernej Tuljak  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

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

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

[Jernej Tuljak]

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?


Jernej

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

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


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

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

[Jernej Tuljak]

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

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