Re: [Netconf] Last Call: <draft-ietf-netconf-rfc7895bis-06.txt> (YANG Library) to Proposed Standard

Robert Wilton <> Mon, 02 July 2018 10:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EA14130F2B; Mon, 2 Jul 2018 03:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sk0L30lBVLis; Mon, 2 Jul 2018 03:51:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBECF130E06; Mon, 2 Jul 2018 03:51:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3597; q=dns/txt; s=iport; t=1530528669; x=1531738269; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=MXo1DnewKt8yihve/BnlyTXMaYBdbZcC+fbPdC0xLgA=; b=WBzATjJ1NCTWqo/pXsBD+80TbdgHeTG+NyVTHgKY++aEXnRpZ+rBLI/g mymE120Na7GEz5RnZuoEt3hDXWGJzVjgqVy8dEMkFFe5hGTyOC9hg+Tfe 77lDV3wG+K1W6uXlwIqDfmQ+nq2rujALme0M79kzIa57PPDtON9S/x3zQ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAoAzpb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQrfyiDeYhjjTkIIogujnALI4FUgnUCg1E3FQECAQECAQE?= =?us-ascii?q?CbRwMhTYBAQEBAyMPAQU2CwwECxIDAQICAiYCAiEoDgYBDAYCAQGDHAGBZwM?= =?us-ascii?q?VD6cfghyEW4IzDYEugSkFgQuJOD+BDycMglyCVkICAwGBRoMXglUCmRsrCYY?= =?us-ascii?q?GhgyDBQaBQIQMgkaFQ4ozT4EzhVKBVyKBUjMaCBsVgnABM4JMiEiFPz4wkV0?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.51,298,1526342400"; d="scan'208";a="4918488"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2018 10:51:06 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id w62Ap6mW004302; Mon, 2 Jul 2018 10:51:06 GMT
To: "t.petch" <>,
References: <> <03ac01d411ef$f7d0cfe0$>
From: Robert Wilton <>
Message-ID: <>
Date: Mon, 2 Jul 2018 11:51:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <03ac01d411ef$f7d0cfe0$>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Netconf] Last Call: <draft-ietf-netconf-rfc7895bis-06.txt> (YANG Library) to Proposed Standard
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Jul 2018 10:51:12 -0000

Hi Tom,

It is entirely up to the server implementation to decide what modules 
should be put together into a single module set.

Some examples of categories that could be used to group different 
related modules together:

(i) Modules that are common across all datastores, vs modules that are 
only used for particular datastores (e.g. a dynamic datastore).

(ii) Modules for different versions of software could be reported as 
separate module sets.  Only the module set(s) associated with a 
particular software version would expect to be used.  This hypothetical 
example is from the YANG versioning work, and may or may not become a 
recommendation depending on how that work pans out ...

(iii) Sometimes vendors want to split their software up into separate 
packages, and module sets could be used to represent these different 
packages (e.g. core, vs L2VPN, vs L3VPN, vs Subscribers, etc).

(iv) Sometimes devices need to support different schemas at the same 
time (e.g. The IETF ecosystem, vs OpenConfig ecosystem, vs vendor native 
ecosystem).  Again, this is another case where module sets may be useful 
to differentiate between the different groups.

Of course, if a server is very simple, and none of the above applies, 
then it could choose to have just a single module set.

Does that help clarify their potential usage?


On 02/07/2018 11:32, t.petch wrote:
> One aspect of this leaves me puzzled; what is a module set?
> Yes, I see that a data store schema is made up of module sets, which are
> made up of modules, but given, say, 40 modules, what criteria decide
> whether this is one set of 40, two of 20, half a dozen of varying size
> or what?
> Tom Petch
> ----- Original Message -----
> From: "The IESG" <>
> To: "IETF-Announce" <>
> Cc: <>om>; <>om>;
> <>rg>; <>rg>;
> <>
> Sent: Thursday, June 14, 2018 5:22 PM
>> The IESG has received a request from the Network Configuration WG
> (netconf)
>> to consider the following document: - 'YANG Library'
>>    <draft-ietf-netconf-rfc7895bis-06.txt> as Proposed Standard
>> The IESG plans to make a decision in the next few weeks, and solicits
> final
>> comments on this action. Please send substantive comments to the
>> mailing lists by 2018-06-28. Exceptionally, comments may
> be
>> sent to instead. In either case, please retain the
> beginning of
>> the Subject line to allow automated sorting.
>> Abstract
>>     This document describes a YANG library that provides information
>>     about the YANG modules, datastores, and datastore schemas used by a
>>     network management server.  Simple caching mechanisms are provided
> to
>>     allow clients to minimize retrieval of this information.  This
>>     version of the YANG library supports the Network Management
> Datastore
>>     Architecture by listing all datastores supported by a network
>>     management server and the schema that is used by each of these
>>     datastores.
>>     This document obsoletes RFC 7895.
>> The file can be obtained via
>> IESG discussion can be tracked via
>> No IPR declarations have been submitted directly on this I-D.
> .