Re: [netmod] YANG library structure

Ladislav Lhotka <> Fri, 08 December 2017 12:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB9191200C1 for <>; Fri, 8 Dec 2017 04:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uvdVTNgmNdkn for <>; Fri, 8 Dec 2017 04:10:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3E092124D68 for <>; Fri, 8 Dec 2017 04:10:09 -0800 (PST)
Received: by (Postfix, from userid 109) id 7301D18215DC; Fri, 8 Dec 2017 13:10:05 +0100 (CET)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id 777991820E6E; Fri, 8 Dec 2017 13:09:57 +0100 (CET)
From: Ladislav Lhotka <>
To: Martin Bjorklund <>,
In-Reply-To: <>
References: <>
Mail-Followup-To: Martin Bjorklund <>,
Date: Fri, 08 Dec 2017 13:09:58 +0100
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [netmod] YANG library structure
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: Fri, 08 Dec 2017 12:10:12 -0000

Martin Bjorklund <> writes:

> Hi,
> There has been quite a lot of discussion about the YANG library
> data model on the list.  The authors of draft-ietf-netconf-rfc7895bis
> have tried to understand all arguments in the discussion, and provide
> a solution.  Below are 3 solution proposals (we have discussed more,
> but they are basically just variations on the same themes).
> Absolute Requirements
> ---------------------
> o  RFC 7950, Section 5.6.5 says:
>      A server MUST NOT implement more than one revision of a module.

I believe YANG library should be liberated from the dependence on
servers and protocols and become part of a formal data model
specification. It is not just some state data but rather metadata, and
it is also perfectly conceivable that a server does not publish its YANG
library at all (e.g. for security reasons or constrained devices).

And then, I would suggest to consider dropping the above requirement
for the *general* YANG library, i.e. design it so that it can in
principle support multiple revisions of the same module. This is
important because

- it allows for supporting multiple revisions of some hardware
  (e.g. line cards) in the same device

- the server needn't represent just a single device but may be used for
  configuring a network of devices, and then the above restriction could
  be severely limiting.

This said, it would still be possible for a specific protocol to impose
such a restriction.


> Alt. B.
> -------
>   Each datastore refers to a schema, and each schema contains a list
>   of references to module-sets, and each module-set contains a flat
>   list of all modules, features, etc.

I like this one because different schemas will often need to reuse the
same module sets, and it will also be quite easy to add schema mount
specification to this.


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