Re: [netmod] [yang-doctors] YANG 'when' with absolute path

[tom petch]

From: netmod  on behalf of Andy Bierman 

Sent: 02 February 2022 21:46


Agreeing with Andy, Lada and so on but adding a contextual note.

This augment/when construct is widely used in TEAS and CCAMP modules, of which 
there are a very large number, and in any one module, the augment/when can 
appear over 100 - yes one hundred - times because of the way that the base 
module that is being augmented has been structured so the potential gain in 
simplicity, readability is considerable.

Tom Petch



On Wed, Feb 2, 2022 at 2:41 AM Ladislav Lhotka 
mailto:ladislav.lho...@nic.cz>> wrote:
On 02. 02. 22 11:15, Jan Lindblad wrote:
> Lada,
>
>>> While I agree that tools are easier to update than WG documents, and
>>> that a broken yanglint isn't a strong reason to avoid the proposed
>>> axis construct, I do think it will have a cost. In current YANG
>>> practice, XML axis constructs are esoteric, and many implementations
>>> will either not support it, or have not been tested properly in this
>>> area before. Many engineers will never have seen this before, and
>>> might stumble.
>>>
>>> Bottom line, this is valid YANG, and it is supposed to work. For many
>>> people it will definitely be less readable than a relative path. I
>>> expect choosing the axis solution will slow the uptake of this module.
>>
>> I disagree. Tools should faithfully implement the standard, and
>> especially those that are used as "authoritative" in RFC validation
>> process. I don't see how axes could be considered esoteric - in fact,
>> they are very fundamental in XPath and things like '..' or '//' are
>> just syntactic sugar for axes contructs.
>
> I'm not going to argue with you when it comes to XPath in general. Axes
> are (a fundamental) part of it.
>
> I'm just speaking of current YANG practice. Out of the 45k YANG modules
> in the IETF YANG repo on Github (which includes standard, experimental
> and many vendor modules), I did not find any using axes today. I think
> that observation makes it reasonable to call them esoteric in YANG context.

This is a slippery slope. It's quite likely that none of existing
modules has ever used other XPath features, such as some built-in
functions. Does it mean that implementations may ignore them and fail
upon encountering such features. Who is going to decide what is esoteric
and what not?

RFC 8470 lists some XPath features that should not be used for good
reasons (including some axes), but the rest should IMO be OK to use.



I think you mean RFC 8407.
I checked and it does not say to avoid using the ancestor axis.
I checked our tools which support full XPath and no problems.

Looking at the actual usage (below), the 'ancestor' approach is more
readable and easier for the writer to generate correctly.
Given that the "network" node must be present in the augment-stmt,
it is not a concern that it is used directly in the when-stmt.


 augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/tet:connectivity-matrices/"
+ "tet:label-restrictions/tet:label-restriction" {

when "ancestor::nw:network/nw:network-types/"
   + "tet:te-topology/flexgt:flexi-grid-topology";

/*
when "../../../../../../nw:network-types/tet:te-topology/"
   + "flexgt:flexi-grid-topology" {
  description
"Augmentation parameters apply only for networks with
 flexi-grid topology type.";
}
*/
description
  "Augment TE label range information for the TE node
   connectivity matrices.";
uses l0-types:flexi-grid-label-range-info;
  }



Andy


>
> I have seen axes used in the real world YANG modules a handful of times.
> Each time it led to real world problems. They could be worked around and
> resolved, but it required YANG expert involvement and additional coding
> and testing efforts. My conclusion is that usage of axes is typically
> causing trouble and decreasing readability+understanding in the real world

In my experience, the complexity is not so much in XPath itself but
rather in brittle semantics of 'when'.

Lada

>
> Best Regards,
> /jan
>

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
yang-doctors mailing list
yang-doct...@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors

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

Re: [netmod] [yang-doctors] YANG 'when' with absolute path

[Andy Bierman]

On Wed, Feb 2, 2022 at 2:41 AM Ladislav Lhotka 
wrote:

> On 02. 02. 22 11:15, Jan Lindblad wrote:
> > Lada,
> >
> >>> While I agree that tools are easier to update than WG documents, and
> >>> that a broken yanglint isn't a strong reason to avoid the proposed
> >>> axis construct, I do think it will have a cost. In current YANG
> >>> practice, XML axis constructs are esoteric, and many implementations
> >>> will either not support it, or have not been tested properly in this
> >>> area before. Many engineers will never have seen this before, and
> >>> might stumble.
> >>>
> >>> Bottom line, this is valid YANG, and it is supposed to work. For many
> >>> people it will definitely be less readable than a relative path. I
> >>> expect choosing the axis solution will slow the uptake of this module.
> >>
> >> I disagree. Tools should faithfully implement the standard, and
> >> especially those that are used as "authoritative" in RFC validation
> >> process. I don't see how axes could be considered esoteric - in fact,
> >> they are very fundamental in XPath and things like '..' or '//' are
> >> just syntactic sugar for axes contructs.
> >
> > I'm not going to argue with you when it comes to XPath in general. Axes
> > are (a fundamental) part of it.
> >
> > I'm just speaking of current YANG practice. Out of the 45k YANG modules
> > in the IETF YANG repo on Github (which includes standard, experimental
> > and many vendor modules), I did not find any using axes today. I think
> > that observation makes it reasonable to call them esoteric in YANG
> context.
>
> This is a slippery slope. It's quite likely that none of existing
> modules has ever used other XPath features, such as some built-in
> functions. Does it mean that implementations may ignore them and fail
> upon encountering such features. Who is going to decide what is esoteric
> and what not?
>
> RFC 8470 lists some XPath features that should not be used for good
> reasons (including some axes), but the rest should IMO be OK to use.
>
>

I think you mean RFC 8407.
I checked and it does not say to avoid using the ancestor axis.
I checked our tools which support full XPath and no problems.

Looking at the actual usage (below), the 'ancestor' approach is more
readable and easier for the writer to generate correctly.
Given that the "network" node must be present in the augment-stmt,
it is not a concern that it is used directly in the when-stmt.


 augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/tet:connectivity-matrices/"
+ "tet:label-restrictions/tet:label-restriction" {

when "ancestor::nw:network/nw:network-types/"
   + "tet:te-topology/flexgt:flexi-grid-topology";

/*
when "../../../../../../nw:network-types/tet:te-topology/"
   + "flexgt:flexi-grid-topology" {
  description
"Augmentation parameters apply only for networks with
 flexi-grid topology type.";
}
*/
description
  "Augment TE label range information for the TE node
   connectivity matrices.";
uses l0-types:flexi-grid-label-range-info;
  }



Andy


>
> > I have seen axes used in the real world YANG modules a handful of times.
> > Each time it led to real world problems. They could be worked around and
> > resolved, but it required YANG expert involvement and additional coding
> > and testing efforts. My conclusion is that usage of axes is typically
> > causing trouble and decreasing readability+understanding in the real
> world
>
> In my experience, the complexity is not so much in XPath itself but
> rather in brittle semantics of 'when'.
>
> Lada
>
> >
> > Best Regards,
> > /jan
> >
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> ___
> yang-doctors mailing list
> yang-doct...@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [yang-doctors] YANG 'when' with absolute path

[Ladislav Lhotka]

On 02. 02. 22 11:15, Jan Lindblad wrote:

Lada,

While I agree that tools are easier to update than WG documents, and 
that a broken yanglint isn't a strong reason to avoid the proposed 
axis construct, I do think it will have a cost. In current YANG 
practice, XML axis constructs are esoteric, and many implementations 
will either not support it, or have not been tested properly in this 
area before. Many engineers will never have seen this before, and 
might stumble.


Bottom line, this is valid YANG, and it is supposed to work. For many 
people it will definitely be less readable than a relative path. I 
expect choosing the axis solution will slow the uptake of this module.


I disagree. Tools should faithfully implement the standard, and 
especially those that are used as "authoritative" in RFC validation 
process. I don't see how axes could be considered esoteric - in fact, 
they are very fundamental in XPath and things like '..' or '//' are 
just syntactic sugar for axes contructs.


I'm not going to argue with you when it comes to XPath in general. Axes 
are (a fundamental) part of it.


I'm just speaking of current YANG practice. Out of the 45k YANG modules 
in the IETF YANG repo on Github (which includes standard, experimental 
and many vendor modules), I did not find any using axes today. I think 
that observation makes it reasonable to call them esoteric in YANG context.


This is a slippery slope. It's quite likely that none of existing 
modules has ever used other XPath features, such as some built-in 
functions. Does it mean that implementations may ignore them and fail 
upon encountering such features. Who is going to decide what is esoteric 
and what not?


RFC 8470 lists some XPath features that should not be used for good 
reasons (including some axes), but the rest should IMO be OK to use.




I have seen axes used in the real world YANG modules a handful of times. 
Each time it led to real world problems. They could be worked around and 
resolved, but it required YANG expert involvement and additional coding 
and testing efforts. My conclusion is that usage of axes is typically 
causing trouble and decreasing readability+understanding in the real world


In my experience, the complexity is not so much in XPath itself but 
rather in brittle semantics of 'when'.


Lada



Best Regards,
/jan



--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] [yang-doctors] YANG 'when' with absolute path

[Jan Lindblad]

Lada,

>> While I agree that tools are easier to update than WG documents, and that a 
>> broken yanglint isn't a strong reason to avoid the proposed axis construct, 
>> I do think it will have a cost. In current YANG practice, XML axis 
>> constructs are esoteric, and many implementations will either not support 
>> it, or have not been tested properly in this area before. Many engineers 
>> will never have seen this before, and might stumble.
>> 
>> Bottom line, this is valid YANG, and it is supposed to work. For many people 
>> it will definitely be less readable than a relative path. I expect choosing 
>> the axis solution will slow the uptake of this module.
> 
> I disagree. Tools should faithfully implement the standard, and especially 
> those that are used as "authoritative" in RFC validation process. I don't see 
> how axes could be considered esoteric - in fact, they are very fundamental in 
> XPath and things like '..' or '//' are just syntactic sugar for axes 
> contructs.

I'm not going to argue with you when it comes to XPath in general. Axes are (a 
fundamental) part of it.

I'm just speaking of current YANG practice. Out of the 45k YANG modules in the 
IETF YANG repo on Github (which includes standard, experimental and many vendor 
modules), I did not find any using axes today. I think that observation makes 
it reasonable to call them esoteric in YANG context.

I have seen axes used in the real world YANG modules a handful of times. Each 
time it led to real world problems. They could be worked around and resolved, 
but it required YANG expert involvement and additional coding and testing 
efforts. My conclusion is that usage of axes is typically causing trouble and 
decreasing readability+understanding in the real world.

Best Regards,
/jan

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

Re: [netmod] [yang-doctors] YANG 'when' with absolute path

[Ladislav Lhotka]

Jan Lindblad  writes:

> Italo,
>
> While I agree that tools are easier to update than WG documents, and that a 
> broken yanglint isn't a strong reason to avoid the proposed axis construct, I 
> do think it will have a cost. In current YANG practice, XML axis constructs 
> are esoteric, and many implementations will either not support it, or have 
> not been tested properly in this area before. Many engineers will never have 
> seen this before, and might stumble.
>
> Bottom line, this is valid YANG, and it is supposed to work. For many people 
> it will definitely be less readable than a relative path. I expect choosing 
> the axis solution will slow the uptake of this module.

I disagree. Tools should faithfully implement the standard, and especially 
those that are used as "authoritative" in RFC validation process. I don't see 
how axes could be considered esoteric - in fact, they are very fundamental in 
XPath and things like '..' or '//' are just syntactic sugar for axes contructs.

Lada

>
> Best Regards,
> /Jan
>
>
>> On 28 Jan 2022, at 12:12, Italo Busi 
>>  wrote:
>> 
>> Thanks Michal for the clarification
>> 
>> We have discussed this issue among the co-authors of 
>> draft-ietf-ccamp-flexigrid-yang and we are not sure about how to address a 
>> WG LC comment we have received on this topic
>> 
>> While the YANG code using the ancestor instead of relative paths looks 
>> easier to read and understand to an human code writer/reader, we are 
>> concerned about whether it is worthwhile standardizing in IETF a YANG data 
>> model which fails compilation with yanglint
>> 
>> The YANG code is correct (at least it passes pyang validation) but it fails 
>> yanglint validation just because yanglint does not support axes, so we 
>> expect that as soon as we upload the updated draft, the IETF datatracker 
>> will signal yang validation errors
>> 
>> Is there any guideline/suggestion from Netmod WG and YANG doctors on how to 
>> deal with such a case?
>> 
>> Thanks, Italo (on behalf of co-authors)
>> 
>>> -Original Message-
>>> From: Michal Vaško [mailto:mva...@cesnet.cz ]
>>> Sent: martedì 18 gennaio 2022 08:07
>>> To: Italo Busi mailto:italo.b...@huawei.com>>
>>> Cc: Ladislav Lhotka >> >; Martin Björklund
>>> mailto:mbj+i...@4668.se>>; netmod@ietf.org 
>>> 
>>> Subject: Re: [netmod] YANG 'when' with absolute path
>>> 
>>> Hi,
>>> 
>>> yanglint uses its own XPath implementation, which unfortunately does not
>>> support axes, hence the error.
>>> 
>>> Regards,
>>> Michal
>>> 
>>> On Monday, January 17, 2022 16:59 CET, Italo Busi
>>>  wrote:
>>> 
 Lada, Martin,
 
 Thanks for your suggestion and thanks Tom for having raised this issue
 to Netmod WG
 
 We have tried to follow your suggestion and replaced the relative paths 
 with:
  when "ancestor::nw:network/nw:network-types/tet:te-topology"
 
 You can find the updated YANG module on github:
 
 https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-flexigrid-yang/tree/
 wg-lc-resolution
 
 However, we have found some issues when compiling the new code with
>>> yanglint. This is the error that we have got from the on-line YANG 
>>> validator:
 
  libyang err : Invalid character 'a'[1] of expression
>>> 'ancestor::nw:network/nw:network-types/tet:te-topology/flexgt:flexi-grid-
>>> topology'. (/ietf-flexi-grid-
>>> topology:{augment='/nw:networks/nw:network/nt:link/tet:te/tet:te-link-
>>> attributes/tet:underlay/tet:primary-path/tet:path-
>>> element/tet:type/tet:label/tet:label-hop/tet:te-label/tet:technology'})
  YANGLINT[E]: Processing schema module from
>>> /var/yang/tmp/yangvalidator/yangvalidator-v2-workdir-tNQJZOjI/ietf-flexi-
>>> grid-topology.yang failed.
 
 Is this an issue with yanglint or with the updated code?
 
 Pyang compilation does not return any error/warning
 
 Thanks in advance
 
 Aihua, Sergio and Italo
 
> -Original Message-
> From: Ladislav Lhotka [mailto:ladislav.lho...@nic.cz]
> Sent: domenica 2 gennaio 2022 10:58
> To: Martin Björklund 
> Cc: c...@tzi.org; netmod@ietf.org
> Subject: Re: [netmod] YANG 'when' with absolute path
> 
> 
> 
> On 02. 01. 22 10:43, Martin Björklund wrote:
>> Hi,
>> 
>> Ladislav Lhotka mailto:ladislav.lho...@nic.cz>>
>>> wrote:
>>> Carsten Bormann mailto:c...@tzi.org>> writes:
>>> 
 On 2021-12-30, at 13:29, tom petch
>>> mailto:ie...@btconnect.com>> wrote:
> 
>   when
> "../../../../../../nw:network-types/tet:te-topology/“
 
 I’m probably showing my ignorance about YANG again, but what is
 the reason this is not phrased as
 
   when "./ancestor::nw:network-types/tet:te-topology/“
>>> 
>>> Yes, this would work, with a minor correction:
>>> 
>>> when 

Re: [netmod] [yang-doctors] YANG 'when' with absolute path

[Jan Lindblad]

Italo,

While I agree that tools are easier to update than WG documents, and that a 
broken yanglint isn't a strong reason to avoid the proposed axis construct, I 
do think it will have a cost. In current YANG practice, XML axis constructs are 
esoteric, and many implementations will either not support it, or have not been 
tested properly in this area before. Many engineers will never have seen this 
before, and might stumble.

Bottom line, this is valid YANG, and it is supposed to work. For many people it 
will definitely be less readable than a relative path. I expect choosing the 
axis solution will slow the uptake of this module.

Best Regards,
/Jan


> On 28 Jan 2022, at 12:12, Italo Busi  
> wrote:
> 
> Thanks Michal for the clarification
> 
> We have discussed this issue among the co-authors of 
> draft-ietf-ccamp-flexigrid-yang and we are not sure about how to address a WG 
> LC comment we have received on this topic
> 
> While the YANG code using the ancestor instead of relative paths looks easier 
> to read and understand to an human code writer/reader, we are concerned about 
> whether it is worthwhile standardizing in IETF a YANG data model which fails 
> compilation with yanglint
> 
> The YANG code is correct (at least it passes pyang validation) but it fails 
> yanglint validation just because yanglint does not support axes, so we expect 
> that as soon as we upload the updated draft, the IETF datatracker will signal 
> yang validation errors
> 
> Is there any guideline/suggestion from Netmod WG and YANG doctors on how to 
> deal with such a case?
> 
> Thanks, Italo (on behalf of co-authors)
> 
>> -Original Message-
>> From: Michal Vaško [mailto:mva...@cesnet.cz ]
>> Sent: martedì 18 gennaio 2022 08:07
>> To: Italo Busi mailto:italo.b...@huawei.com>>
>> Cc: Ladislav Lhotka > >; Martin Björklund
>> mailto:mbj+i...@4668.se>>; netmod@ietf.org 
>> 
>> Subject: Re: [netmod] YANG 'when' with absolute path
>> 
>> Hi,
>> 
>> yanglint uses its own XPath implementation, which unfortunately does not
>> support axes, hence the error.
>> 
>> Regards,
>> Michal
>> 
>> On Monday, January 17, 2022 16:59 CET, Italo Busi
>>  wrote:
>> 
>>> Lada, Martin,
>>> 
>>> Thanks for your suggestion and thanks Tom for having raised this issue
>>> to Netmod WG
>>> 
>>> We have tried to follow your suggestion and replaced the relative paths 
>>> with:
>>>  when "ancestor::nw:network/nw:network-types/tet:te-topology"
>>> 
>>> You can find the updated YANG module on github:
>>> 
>>> https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-flexigrid-yang/tree/
>>> wg-lc-resolution
>>> 
>>> However, we have found some issues when compiling the new code with
>> yanglint. This is the error that we have got from the on-line YANG validator:
>>> 
>>>  libyang err : Invalid character 'a'[1] of expression
>> 'ancestor::nw:network/nw:network-types/tet:te-topology/flexgt:flexi-grid-
>> topology'. (/ietf-flexi-grid-
>> topology:{augment='/nw:networks/nw:network/nt:link/tet:te/tet:te-link-
>> attributes/tet:underlay/tet:primary-path/tet:path-
>> element/tet:type/tet:label/tet:label-hop/tet:te-label/tet:technology'})
>>>  YANGLINT[E]: Processing schema module from
>> /var/yang/tmp/yangvalidator/yangvalidator-v2-workdir-tNQJZOjI/ietf-flexi-
>> grid-topology.yang failed.
>>> 
>>> Is this an issue with yanglint or with the updated code?
>>> 
>>> Pyang compilation does not return any error/warning
>>> 
>>> Thanks in advance
>>> 
>>> Aihua, Sergio and Italo
>>> 
 -Original Message-
 From: Ladislav Lhotka [mailto:ladislav.lho...@nic.cz]
 Sent: domenica 2 gennaio 2022 10:58
 To: Martin Björklund 
 Cc: c...@tzi.org; netmod@ietf.org
 Subject: Re: [netmod] YANG 'when' with absolute path
 
 
 
 On 02. 01. 22 10:43, Martin Björklund wrote:
> Hi,
> 
> Ladislav Lhotka mailto:ladislav.lho...@nic.cz>>
>> wrote:
>> Carsten Bormann mailto:c...@tzi.org>> writes:
>> 
>>> On 2021-12-30, at 13:29, tom petch
>> mailto:ie...@btconnect.com>> wrote:
 
   when
 "../../../../../../nw:network-types/tet:te-topology/“
>>> 
>>> I’m probably showing my ignorance about YANG again, but what is
>>> the reason this is not phrased as
>>> 
>>>   when "./ancestor::nw:network-types/tet:te-topology/“
>> 
>> Yes, this would work, with a minor correction:
>> 
>> when "./ancestor::node()/nw:network-types/tet:te-topology"
>> 
>> because 'nw:network-types' isn't an ancestor of the context node.
>> Also, the initial './' isn't actually needed, hence
>> 
>> when "ancestor::node()/nw:network-types/tet:te-topology"
> 
> Or the more direct:
> 
> when "ancestor::nw:network/nw:network-types/tet:te-topology"
 
 Right, this is the best option.
 
> 
> This style works if we can guarantee that 

Re: [netmod] [yang-doctors] YANG 'when' with absolute path

[Ladislav Lhotka]

On 02. 02. 22 1:00, Robert Varga wrote:

On 28/01/2022 12:12, Italo Busi wrote:
The YANG code is correct (at least it passes pyang validation) but it 
fails yanglint validation just because yanglint does not support axes, 
so we expect that as soon as we upload the updated draft, the IETF 
datatracker will signal yang validation errors


Is there any guideline/suggestion from Netmod WG and YANG doctors on 
how to deal with such a case?


I do not believe a deficiency in one tool should hold back publication. 
Tools are updated more easily than SDO documents after all and one would 
hope this will create a bit of an incentive to fix the tool.


+1

Lada



Regards,
Robert

___
yang-doctors mailing list
yang-doct...@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors


--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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