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 <netmod-boun...@ietf.org> On Behalf Of Florian Kauer
Sent: Thursday, February 8, 2024 9:31 AM
To: marina.gutierrez.lo...@gmail.com; stds-802-y...@listserv.ieee.org;
netmod@ietf.org; stds-802-...@listserv.ieee.org
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
+++ ieee802-dot1q-sc...@2024-01-30.yang 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 <florian.ka...@linutronix.de> 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
>> iana-if-t...@2023-01-26.yang ietf-interfa...@2018-02-20.yang
>>
>> 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
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
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
