Re: [netmod] Abusing YANG extensions

Ladislav Lhotka <> Thu, 03 May 2018 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7E59126C83 for <>; Thu, 3 May 2018 05:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SA3vlGV5n1Ho for <>; Thu, 3 May 2018 05:57:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 421A61204DA for <>; Thu, 3 May 2018 05:57:46 -0700 (PDT)
Received: by (Postfix, from userid 109) id 606EF182015B; Thu, 3 May 2018 15:02:32 +0200 (CEST)
Received: from localhost ( []) by (Postfix) with ESMTPSA id 6FE6E1820157; Thu, 3 May 2018 15:02:30 +0200 (CEST)
From: Ladislav Lhotka <>
To: Andy Bierman <>, NetMod WG <>
In-Reply-To: <>
References: <>
Mail-Followup-To: Andy Bierman <>, NetMod WG <>
Date: Thu, 03 May 2018 14:57:51 +0200
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [netmod] Abusing YANG extensions
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 May 2018 12:57:49 -0000

Andy Bierman <> writes:

> Hi,
> The discussion about yang-data is stuck because the NETMOD WG does not
> understand or does not agree on what it means to abuse a YANG extension
> and use it improperly.

In my view, we should strictly separate the concerns of YANG and

1. YANG should deal only with (abstract) schemas and rules for
   determining whether a given instance data tree is valid or not. All
   other considerations should be removed (moved elsewhere).

2. Extensions must not tinker with #1. In other words, if extensions are
   removed, the resulting schemas must be the same and validity rules as

> If a tool implementing a standard cannot do so without implementing
> certain extensions, then those extensions are not optional,
> but rather they are mandatory, and therefore violating YANG 1.1.


> The NACM extensions are OK because they can be safely ignored
> unless the implementation supports NACM, These extensions
> are only implemented by the server, so the client is not impacted.

Yes, this satisfies #2 above.

> The <config> element is a use-case where YANG fails completely.
> According to YANG, the <config> element should only contain child nodes
> if they are defined directly or defined with the augment-stmt.
> YANG says absolutely nothing about nested data nodes that contain
> top-level data nodes.
> The "mount-point" extension in YANG Schema Mount also violates
> YANG 1.1 in this way. A plain client that does not support schema-mount
> will find container and list elements that contain undefined child nodes.
> If the server chooses to support schema-mount, the client
> is forced to support it, and this is a violation of YANG 1.1.

This is a bit more complicated, the extension itself doesn't cause any
data to appear under the mount point - it is some state data that the
client may understand or not. That's why I think YANG library and schema
mount data have to be treated specially (as metadata describing
datastore organization).

> However, the yang-data extension cannot possibly interfere with standard
> YANG 1.1 statements because it is used to specify data structures
> that are outside the plain data nodes, instead of over-riding the
> definitions of the plain data nodes.

YANG inside yang-data has somewhat different rules (described in the
description) and still the text of RFC 7950 has to be interpreted
liberally, e.g. because there is in general no server and hence no YANG

YANG (according to #1 above) should be able to cover such uses out of
the box.


> Andy
> _______________________________________________
> netmod mailing list

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