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

From: Robert Varga <[email-masked]>
Date: Wed, 2 Feb 2022 01:00:55 +0100

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.

Regards,
Robert

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 2 Feb 2022 09:26:12 +0100

On 02. 02. 22 1:00, Robert Varga 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
>>

+1

Lada

> 
> Regards,
> Robert
> 
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

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

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 2 Feb 2022 09:47:36 +0100

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 <Italo.Busi=[email-masked]> 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
> 
> Thanks, Italo (on behalf of co-authors)
> 
>> -----Original Message-----
>> From: Michal Vaško [mailto:[email-masked] <mailto:[email-masked]>]
>> Sent: martedì 18 gennaio 2022 08:07
>> To: Italo Busi <[email-masked] <mailto:[email-masked]>>
>> Cc: Ladislav Lhotka <[email-masked] <mailto:[email-masked]>>; Martin Björklund
>> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> 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
>> <Italo.Busi=[email-masked]> 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:[email-masked]]
>>>> Sent: domenica 2 gennaio 2022 10:58
>>>> To: Martin Björklund <[email-masked]>
>>>> Cc: [email-masked]; [email-masked]
>>>> Subject: Re: [netmod] YANG 'when' with absolute path
>>>> 
>>>> 
>>>> 
>>>> On 02. 01. 22 10:43, Martin Björklund wrote:
>>>>> Hi,
>>>>> 
>>>>> Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>>>>> Carsten Bormann <[email-masked]<mailto:[email-masked]>> writes:
>>>>>> 
>>>>>>> On 2021-12-30, at 13:29, tom petch
>> <[email-masked]<mailto:[email-masked]>> 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 there will be exactly
>>>>> one node "nw:network" among our ancestors.
>>>>> 
>>>>> It is perhaps easier to get this style right w/o a YANG compiler
>>>>> (which would detect if the number of ".." in the relative path is
>>>>> wrong), but the relative path might be easier to understand for a
>>>>> casual reader.
>>>> 
>>>> +1
>>>> 
>>>> Lada
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> /martin
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Lada
>>>>>> 
>>>>>>> 
>>>>>>> ?
>>>>>>> 
>>>>>>> Grüße, Carsten
>>>>>>> 
>>>>>>> netmod mailing list
>>>>>>> [email-masked]<mailto:[email-masked]>
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>> 
>>>>>> --
>>>>>> Ladislav Lhotka
>>>>>> Head, CZ.NIC Labs
>>>>>> netmod mailing list
>>>>>> [email-masked]<mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>>>> --
>>>> Ladislav Lhotka
>>>> Head, CZ.NIC Labs
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Feb 2022 10:51:50 +0100

> 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 th…

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

> [email-masked]

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 2 Feb 2022 11:15:54 +0100

Lada,

> 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 f…

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 2 Feb 2022 11:40:49 +0100

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Feb 2022 13:46:12 -0800

> 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

---

From: tom petch <[email-masked]>
Date: Fri, 4 Feb 2022 09:53:10 +0000

From: netmod <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Sent: 02 February 2022 21:46

<tp>
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 <[email-masked]<mailto:[email-masked]>> wrote:

/*

Andy

Lada

_______________________________________________
yang-doctors mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/yang-doctors