Re: [netmod] IEEE Std 802.1Qcw invalidates trivial YANG data tree

[Don Fedyk <[e-mail]>]

Hi 

I'd suggest that the 802.1 Yangsters group should track this, and a 802.1 Maintenance item should be raised.  (those can proceed in parallel).  I had cautioned some 802.1 editors about the drawbacks of putting xpath conditions in YANG.  

Cheers,
Don    

-----Original Message-----
From: netmod <[e-mail]> On Behalf Of Florian Kauer
Sent: Thursday, February 8, 2024 9:31 AM
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [netmod] IEEE Std 802.1Qcw invalidates trivial YANG data tree

Hi,
thanks a lot Lada! This is exactly the change that fixes the issue (see below for the full diff) and with that we were able to use the YANG model in our implementation.
But what now, do we need a Corrigendum for IEEE 802.1Qcw-2023? What is the next step?

Greetings,
Florian

--- schemas/standard/ieee/published/802.1/ieee802-dot1q-sched.yang      2024-02-02 09:50:22.135503812 +0100
+++ [e-mail] 2024-02-02 14:54:24.290563673 
+++ +0100
@@ -33,6 +33,10 @@
     
     This version of this YANG module is part of IEEE Std 802.1Q; see the
     standard itself for full legal notices.";
+  revision 2024-01-30 {
+    description
+      "Draft for fixing incorrect must statements.";  }
   revision 2023-10-22 {
     description
       "Published as part of IEEE Std 802.1Qcw-2023.
@@ -77,7 +81,7 @@
       }
       refine "gate-control-entry/time-interval-value" {
         must
-          "(. <= ../../../supported-interval-max )";
+          "not (. > ../../../supported-interval-max )";
       }
       augment "gate-control-entry" {
         description
@@ -187,9 +191,9 @@
       }
       container admin-control-list {
         must
-          "(count(./gate-control-entry) <= ../supported-list-max)" {
+          "not(count(./gate-control-entry) > ../supported-list-max)" {
           error-message
-            "Number of elements in admin-control-list must not be greater"+
+            "Number of elements in admin-control-list must not be 
+ greater "+
             "than supported-list-max";
         }
         description
@@ -202,9 +206,9 @@
       }
       container oper-control-list {
         must
-          "(count(./gate-control-entry) <= ../supported-list-max)" {
+          "not(count(./gate-control-entry) > ../supported-list-max)" {
           error-message
-            "Number of elements in oper-control-list must not be greater"+
+            "Number of elements in oper-control-list must not be 
+ greater "+
             "than supported-list-max";
         }
         config false;
@@ -217,7 +221,7 @@
       }
       container admin-cycle-time {
         must
-          "(./numerator div ./denominator <= "+
+          "not (./numerator div ./denominator > "+
           "../supported-cycle-max/numerator div "+
           "../supported-cycle-max/denominator )" {
           error-message
@@ -235,7 +239,7 @@
       }
       container oper-cycle-time {
         must
-          "(./numerator div ./denominator <= "+
+          "not (./numerator div ./denominator > "+
           "../supported-cycle-max/numerator div "+
           "../supported-cycle-max/denominator )" {
           error-message


On 15.12.23 10:48, Ladislav Lhotka wrote:
> Hi Florian,
> 
> Florian Kauer <[e-mail]> writes:
> 
>> Hi,
>> I know this is bad timing since Qcw was just published, but - at least with libyang - the following YANG data tree that specifies nothing Qcw related is no longer valid when just loading the Qcw YANG models:
>>
>> interface.json:
>> {
>>   "ietf-interfaces:interfaces": {
>>     "interface": [
>>       {
>>         "if-index": 1,
>>         "name": "eth0",
>>         "type": "iana-if-type:ethernetCsmacd",
>>         "oper-status": "down",
>>         "admin-status": "down",
>>         "statistics": {
>>           "discontinuity-time": "2023-12-15T10:04:12.345+00:00"
>>         }
>>       }
>>     ]
>>   }
>> }
>>
>> yanglint interface.json ieee802-dot1q-sched.yang 
>> ieee802-dot1q-sched-bridge.yang ieee802-types.yang 
>> ieee802-dot1q-types.yang ieee802-dot1q-bridge.yang 
>> [e-mail] [e-mail]
>>
>> results into
>>
>> libyang err : Number of elements in admin-control-list must not be 
>> greaterthan supported-list-max (Data location 
>> "/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bri
>> dge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/admin
>> -control-list".) libyang err : Number of elements in 
>> oper-control-list must not be greaterthan supported-list-max (Data 
>> location 
>> "/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bri
>> dge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/oper-
>> control-list".) libyang err : admin-cycle-time must not be greater 
>> than supported-cycle-max (Data location 
>> "/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bri
>> dge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/admin
>> -cycle-time".) libyang err : oper-cycle-time must not be greater than 
>> supported-cycle-max (Data location 
>> "/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bri
>> dge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/oper-
>> cycle-time".)
>> YANGLINT[E]: Failed to parse input data file "interface.json".
>>
>> My first expectation was a bug in libyang, but Michal is convinced that libyang's behavior is correct in this regard:
>> https://github.com/CESNET/libyang/issues/2140
>>
>> I have not enough experience in YANG to properly argue if either the 
>> YANG model or libyang needs to be changed, but I don't think we want 
>> to force every interface to specify a 
>> /ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-brid
>> ge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/suppor
>> ted-list-max etc. just because the Qcw YANG models are loaded.
>>
>> I hope I have just a misunderstanding and I am looking forward to your responses!
> 
> I am afraid I don't have good news. Apparently, the problem is in this "must" statement:
> 
> must
>   "(count(./gate-control-entry) <= ../supported-list-max)" {
>   error-message
>     "Number of elements in admin-control-list must not be greater"+
>     "than supported-list-max";
> }
> 
> The Xpath expression can never be true unless the "../supported-list-max" leaf exists. This is a common XPath trap, it should have been written like so:
> 
>   "not(count(./gate-control-entry) > ../supported-list-max)"
> 
> This would be true also in the case when "../supported-list-max" doesn't exist.
> 
> Lada
> 
>>
>> Greetings,
>> Florian
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
> 

_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod