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

Robert Wilton <rwilton@cisco.com> Wed, 13 December 2017 14:55 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 AF8EE124B0A; Wed, 13 Dec 2017 06:55:36 -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 tNW59Nyn6-4Y; Wed, 13 Dec 2017 06:55:33 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E052F120227; Wed, 13 Dec 2017 06:55:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25462; q=dns/txt; s=iport; t=1513176933; x=1514386533; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=7HWsKJt/TwllmdJwxpCCozLpL5ZC4WTNyLOvR5Jssf4=; b=XWJxjyojPAjlLMXJsEzXj8EbfK4pNIGd0tT1ZG3JbJKDPLsRkBez5Y4Q UGZgWSxWFDJ7Mlroz26Hqlq7rPstpGCn0IQmRUZwmeGdlqrk4NcwTH312 gdjxpCgAhM14pP1NreYKKVrJ/v/cxjrMZF9lPMsMKVHLU0CosC1RVZsa8 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0COAACtPjFa/xbLJq1UCRkBAQEBAQEBAQEBAQEHAQEBAQGDD4EVdCeEAoohdJAOfpYTghUKGAEJhEpPAoVSGAEBAQEBAQEBAWsohSMBAQEBAgEBASFLCxALGCAHAwICJx8RBg0GAgEBF4oFCBCoZYInJoo2AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYNgg2GBaSmCTDaDLgEYgSwUgyuCYwWSFIc+iU2He40sghZjiRokhzGNEIFWiACBOx85JYEpMhoIGxU6gikJghCCPEE3AQGKOAEBAQ
X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208,217";a="885961"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 14:55:30 +0000
Received: from [10.63.23.92] (dhcp-ensft1-uk-vla370-10-63-23-92.cisco.com [10.63.23.92]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBDEtU0j009264; Wed, 13 Dec 2017 14:55:30 GMT
To: Andy Bierman <andy@yumaworks.com>
Cc: Kent Watsen <kwatsen@juniper.net>, "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> <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com> <CABCOCHSoa8b8=ieips0QguHovi=-8qATb+A3F+iKFu34ikA8Jw@mail.gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <60876a73-3dec-9a4f-e313-1787b432fb34@cisco.com>
Date: Wed, 13 Dec 2017 14:55:30 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CABCOCHSoa8b8=ieips0QguHovi=-8qATb+A3F+iKFu34ikA8Jw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------829A8D330DE6ABA13763460A"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6aHfrBjNhynD00vW3c40Lc5EWhM>
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: Wed, 13 Dec 2017 14:55:37 -0000


On 11/12/2017 20:55, Andy Bierman wrote:
>
>
> On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton <rwilton@cisco.com 
> <mailto:rwilton@cisco.com>> wrote:
>
>     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.
>
>
>
> IMO you are replacing universally meaningful keys  (module-name, 
> revision-date) with an arbitrary name,
> It is not cleaner and not simpler for a client.
No, for alternatives A and B, the list key is the module name itself, 
nor an arbitrary name.
Alternative C uses an arbitrary name.


>
>
>     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).
>
>
>
> How is that the case if the schema list includes its own module list?
> You mean there is a "unique" statement in the outer list that insures 
> that a module/revision
> shows up at most once in all instances of the inner module list?
For alt A, each schema represents a single list (so no duplicated 
implemented modules are possible).

For alt B, yes, the rule is that there must be no duplicates in the 
module-sets that are combined into a single schema.


>
>     3) I genuinely think that the list of implemented modules is more
>     interesting to the client than the imported, but not implemented
>     modules.
>
>
>
> The conformance leaf was good enough.
> Duplicating the module list and removing the conformance leaf is 
> aggressively non-backward compatible.
>
>
>     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.
>
>
>
> Seems to me all new solutions allow a server to violate the MUST in 
> the NMDA draft that
> there is a superset of all modules.  A client has to look for every 
> module in a server-specific
> set of named schema sets, and then reconcile all these sets.
> I still prefer the single module list with a conformance leaf and a 
> leaf-list indicating
> the supported (or unsupported) datastores.
So, this is a trade off between a more expressive model vs a more 
constrained model.

It is worth noting that the existing YANG library (RFC 7895) allows 
servers to produce illegal module lists because they could implement 
multiple revisions of the same module.

Thanks,
Rob


>
>
>
>     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
>
>>
>>
>>     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 <mailto:Netconf@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/netconf
>>     <https://www.ietf.org/mailman/listinfo/netconf>
>
>