IETF Logo Mail Archive

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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 02 July 2018 10:48 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA04130F13; Mon, 2 Jul 2018 03:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDil5v5zkAod; Mon, 2 Jul 2018 03:48:12 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id C8CA4130E06; Mon, 2 Jul 2018 03:48:11 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 68EC222BEB4A; Mon, 2 Jul 2018 12:48:09 +0200 (CEST)
Date: Mon, 02 Jul 2018 12:48:09 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "t.petch" <ietfc@btconnect.com>
Cc: netconf@ietf.org, ibagdona@gmail.com, mjethanandani@gmail.com, netconf-chairs@ietf.org, draft-ietf-netconf-rfc7895bis@ietf.org
Message-ID: <20180702104809.esyhspttv4ul2rz3@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "t.petch" <ietfc@btconnect.com>, netconf@ietf.org, ibagdona@gmail.com, mjethanandani@gmail.com, netconf-chairs@ietf.org, draft-ietf-netconf-rfc7895bis@ietf.org
References: <152899335818.26447.7759890925422555917.idtracker@ietfa.amsl.com> <03ac01d411ef$f7d0cfe0$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <03ac01d411ef$f7d0cfe0$4001a8c0@gateway.2wire.net>
User-Agent: NeoMutt/20180622
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/rgb3fTh8ScpAZGftmUYGrFrlA9M>
Subject: Re: [Netconf] Last Call: <draft-ietf-netconf-rfc7895bis-06.txt> (YANG Library) to Proposed Standard
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jul 2018 10:48:15 -0000

On Mon, Jul 02, 2018 at 11:32:12AM +0100, 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?
>

Why does the size of the module set matter? Creating these module sets
is left to the implementations, some may want to go for big module
sets, other for more modular module sets (that may be easier to share
and combine). Some implementors may have 'packages' or 'bundles' of
modules that they may map to module sets. For the clients, it should
not matter how a server splits things into module sets.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

v2.23.0 | Report a Bug | By Email