Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

Robert Wilton <rwilton@cisco.com> Mon, 11 December 2017 10:57 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C75124205; Mon, 11 Dec 2017 02:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 sFSm57EglJW3; Mon, 11 Dec 2017 02:57:54 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2CCF120724; Mon, 11 Dec 2017 02:57:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14746; q=dns/txt; s=iport; t=1512989874; x=1514199474; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=DjOKLPzFUGl6LWwRYXSzl7tH51MgrgSjOPf+qHCqX40=; b=ElvBYidiZ7pA1SOmJZYa8y2sb0zf24ri/JFveyv6lidbwW3ehnTT8olX b09pWkzK14iQOHMydQigrrxCizAzRpjOKnbq5uWsLDwkK8dRc5YziOHBi IUlbS/8HnRxJy59MjfTnwED9GbtW9SwUx7dslWPIpj7PAAu/LZXU1oQfB M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAQBXYy5a/xbLJq1SCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDD4EVdCeEAoohdI9WL5FBhUuCFQoYAQmESk8ChSsYAQEBAQE?= =?us-ascii?q?BAQEBayiFIgEBAQECAQEBIUsLBQsLGCcDAgInHxEGAQwGAgEBF4oFCBCnQoInJ?= =?us-ascii?q?oo8AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYNog2GBaSmDAoNJgSwUgyuCYwWZS4l?= =?us-ascii?q?Gh3mNKIIWY4kYJIcujQqBVYd/gTsfOSaBKTIaCBsVOoIpCYIQgjxBNwEBiWUBA?= =?us-ascii?q?QE?=
X-IronPort-AV: E=Sophos;i="5.45,391,1508803200"; d="scan'208,217";a="777616"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2017 10:57:51 +0000
Received: from [10.63.23.92] (dhcp-ensft1-uk-vla370-10-63-23-92.cisco.com [10.63.23.92]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBBAvoxA015329; Mon, 11 Dec 2017 10:57:51 GMT
To: Andy Bierman <andy@yumaworks.com>, Kent Watsen <kwatsen@juniper.net>
Cc: "netmod@ietf.org" <netmod@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <b3159aa5-93e4-23eb-406e-083289a4767d@transpacket.com> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <C030AD08-2E8B-4248-994B-04C802296024@juniper.net> <CABCOCHQZLirVDqGNysAkRFXruPKxyXrBQ+xyagU9y3QHRV6d0g@mail.gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com>
Date: Mon, 11 Dec 2017 10:57:50 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CABCOCHQZLirVDqGNysAkRFXruPKxyXrBQ+xyagU9y3QHRV6d0g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------72EB40BA8927C7E67E2F34CA"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/zzpkvxMRtGY0QWfDZUw2Mj5zLsg>
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Dec 2017 10:57:57 -0000

Hi,


On 08/12/2017 18:01, Andy Bierman wrote:
> Hi,
>
> A library per datastore sounds too complicated.
> I prefer the proposal that was made at the IETF meeting that had
> a 'not-implemented-in' leaf-list and a single module list.
The use case that this particular design doesn't work particularly well 
for is if you have a dynamic datastore that just contains a few modules 
that are not supported via the conventional datastores.

I think that there are future uses cases where the set of modules used 
for a dynamic datastore could be really quite different and separate 
from conventional configuration.  E.g. if dynamic subscribers were 
managed through a dynamic configuration datastore rather than RADIUS.

>
> Why is it interesting to have a separate module list for regular 
> modules and imported modules?
Several reasons:
1) It means that the list of implemented modules have a single key and 
hence any references to an implemented module are cleaner/simpler.
2) The model structure naturally more strictly enforces that only a 
single revision/version of a module is implemented.  (E.g. it prevents a 
server stating that two revisions of a module are both implemented).
3) I genuinely think that the list of implemented modules is more 
interesting to the client than the imported, but not implemented modules.

For a server, I would design it to "implement" one revision of every 
module that it uses (including those that don't contain any data nodes, 
RPCs, actions, notifications, or deviations), and then the "import-only" 
list becomes the list of modules that the server implements to satisfy 
"import-by-revision" and these are stated in the implemented schema anyway.


> I prefer to keep the conformance leaf and not change the module list.
>
> NMDA needs to be possible to implement with a single schema tree such 
> that a module
> is implemented in all datastores, or a subset of all datastores.  
> Otherwise it probably won't
> get supported in clients.
All solutions accommodate this requirement.

For me, some of the interesting design questions have revolved around:
- is it better to reduce duplication in the list of modules reported at 
the cost of increased model complexity?
- does the solution extend to schema mount?
- how well does the solution cope with with configuration datastores 
that support very different sets of modules?

To a lesser extent we have also been considering how well the solution 
extends to packaging and semantic versioning, but I think that it is 
quite tricky to know who these are going to pan out. E.g. I think that 
the restriction that a given schema will only implement a single 
revision of a module will end up still holding, but I'm not sure that 
everyone has that same view point.

Thanks,
Rob


>
>
> Andy
>
>
>
> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwatsen@juniper.net 
> <mailto:kwatsen@juniper.net>> wrote:
>
>     CC-ing NETCONF, where the draft is being worked on.
>
>     Kent
>
>
>     On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
>     > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
>     > >
>     > > Yes. The default value for yang-library-datastore leaf is
>     ds:operational
>     > > (the only possible one for the ds:operational datastore). This
>     is backward
>     > > compatible. If one needs different model for 'running', etc.
>     then a new
>     > > datastore identity has to be defined  and set in place of the
>     default value.
>     > > Then this identity can be used to read the yang-library data with
>     > > <get-data>.
>     > >
>     >
>     > Sorry, but I have to ask this: How do I obtain the schema for the
>     > datastore (lets call it <running-library>) that reports the
>     schema for
>     > <running>? Is there another <running-library-library> datastore?
>     Will
>     > the recursion end? Perhaps it does since <running-library-library>
>     > might have itself listed as the schema defining datastore. I guess
>     > Lada will like these kind of meta and meta-meta datastores.
>
>     Not really. Metadata needn't be in datastores.
>
>     Lada
>
>     >
>     > /js
>     >
>     --
>     Ladislav Lhotka
>     Head, CZ.NIC Labs
>     PGP Key ID: 0xB8F92B08A9F76C67
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org <mailto:netmod@ietf.org>
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e=
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e=>
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org <mailto:netmod@ietf.org>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf