Re: [netmod] Unintended when-expression semantics in many IETF YANG modules

Ladislav Lhotka <> Thu, 09 June 2022 09:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3508C14F749 for <>; Thu, 9 Jun 2022 02:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C043QzHy__-H for <>; Thu, 9 Jun 2022 02:35:37 -0700 (PDT)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4F0CC14F741 for <>; Thu, 9 Jun 2022 02:35:37 -0700 (PDT)
Received: from (unknown [IPv6:2001:1488:fffe:6:a8c6:1fff:fec3:5de1]) by (Postfix) with ESMTPSA id 2471C140589; Thu, 9 Jun 2022 11:35:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1654767333; bh=5zNFMmgHluvVT4YnZgL9yhTeayhWQfo7khQhaYwQnDQ=; h=From:To:Subject:Date:From; b=TayaM34weVCsSnfWJ1ZtiOXln3Qh1o1RqVLzFz0QtXU3e+by/XH/+6u4n10w6jKrK Td4NQ47M56C7oX+PCO6AEcRLpsWbaShTV99nRDPvzew5gEWKc+SYH0LHVQJkkOR4Kq V/MqHwxesjbwRNyvBrZaUuxXXP8n4fjmo8bWI724=
From: Ladislav Lhotka <>
To: "Jan Lindblad (jlindbla)" <>, NetMod WG <>
In-Reply-To: <>
References: <>
Mail-Followup-To: "Jan Lindblad (jlindbla)" <>, NetMod WG <>
Date: Thu, 09 Jun 2022 11:35:32 +0200
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.103.4 at mail
X-Virus-Status: Clean
X-Rspamd-Queue-Id: 2471C140589
X-Spamd-Result: default: False [0.00 / 99.00]; ASN(0.00)[asn:25192, ipnet:2001:1488::/32, country:CZ]; WHITELISTED_IP(0.00)[2001:1488:fffe:6:a8c6:1fff:fec3:5de1]
X-Spamd-Bar: /
X-Rspamd-Server: mail
Authentication-Results:; auth=pass
Archived-At: <>
Subject: Re: [netmod] Unintended when-expression semantics in many IETF YANG modules
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Jun 2022 09:35:42 -0000

"Jan Lindblad \(jlindbla\)" <> writes:

> A few days ago, as I was looking for examples of when-expressions in standard modules, I stumbled over this in RFC 8944:
>      augment "/nw:networks/nw:network" {
>        when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
>          description
>            "Augmentation parameters apply only for networks
>             with L2 topology.";
>        }
>        description
>          "Configuration parameters for the L2 network
>           as a whole.";
>        uses l2-topology-attributes;
>      }
> ... and a few other similar constructs in there.
> As you can see the when expression is unconstrained when it comes to which network it refers to, which changes the semantics from "Augmentation parameters apply only for networks with L2 topology" as the authors are wishing for to "Augmentation parameters apply to all networks as soon as there is at least one with L2 topology".
> Aside from RFC 8944, I also noticed very similar problems in RFC 9094, RFC 8542, RFC 8294, RFC 8513 and RFC 8782. The list may be incomplete.

Yes, I remember flagging this issue in at least one of my YD reviews. I think this also led to the myth that YANG Doctors prefer relative paths to absolute. :-)

> What do we do with the broken YANGs modules in these RFCs?

A bis is needed in each case, errata unfortunately won't work.

> Since this seems to be a rather frequently occurring issue, are there any mitigation steps we should take in NETMOD, apart from strengthening the YANG Doctor review process?

Hardly anything. It is IMO too late to part with XPath 1.0. On the one hand, it is a complicated beast, unnecessarily for YANG purposes. On the other hand, many YANG module authors don't bother to learn even the basics.

> What can we reasonably do to ensure all YANG Doctor reviews catch these valid, but unintended XPath expressions before publication?

Tools cannot help much with "false positive" results of XPath evaluation, we just have to be careful and double-check especially absolute paths.


> Best Regards,
> /Jan Lindblad
> _______________________________________________
> netmod mailing list

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