Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
Martin Bjorklund <mbj@tail-f.com> Fri, 08 December 2017 15:03 UTC
Return-Path: <mbj@tail-f.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 75D74124D68 for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2017 07:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 fK3xBuqJM-IB for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2017 07:03:08 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B834F1243FE for <netmod@ietf.org>; Fri, 8 Dec 2017 07:03:07 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 7DC8E1AE0398; Fri, 8 Dec 2017 16:03:06 +0100 (CET)
Date: Fri, 08 Dec 2017 16:03:06 +0100
Message-Id: <20171208.160306.109290175567894287.mbj@tail-f.com>
To: vladimir@transpacket.com
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com>
References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZbiJfWynrCFZKhzwrbs_qP6mxPU>
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: Fri, 08 Dec 2017 15:03:21 -0000
Vladimir Vassilev <vladimir@transpacket.com> wrote: > On 11/15/2017 06:29 PM, Robert Wilton wrote: > > > I don't think that this is really a good idea. You would end up > > returning server metadata in addition to the configuration. > Obviously RFC 7895 defines only config false; data and I was not > proposing a change to that. But I agree something has to be added to > complete the solution. Special purpose datastore identities can be > defined that return instance of yang-library data when read with > <get-data>. (Datastores with yang-library config false; only data not > represented in 'operational') > > Adding this special yang-library-datastore to the proposed > ietf-datastores container e.g. > > module: ietf-datastores > +--ro datastores > | +--ro datastore* [name] > | +--ro name identityref > | +--ro yang-library-datastore identityref > I don't understand this proposal. How would a client learn the library for <running>? For <operational>? /martin > Notifications can indicate which yang-library-datastore is their > origin (adding optional parameter in ietf-datastores through > augmentation to the notifications in ietf-yang-library). > > > > > I still think that the YANG library proposal is the best solution. > The solution I propose has an obvious advantage for all designing > systems that use single model for operational and the configuration > datastores in terms of keeping the already implemented model and full > backward compatibility without maintaining the obsolete /modules-state > container in addition to any of the 3 proposals with additional > indirection layers added. I am not sure if there are any disadvantages > for the rest but I would like to read some arguments. > > Vladimir > > > > Thanks, > > Rob > > > > > > On 16/11/2017 01:21, Vladimir Vassilev wrote: > >> Hello, > >> > >> I have a proposal based on <get-data> that provides an elegant > >> solution to consider as a 3rd option. It is based on keeping exactly > >> the same model as in RFC 7895 and using <get-data> RPC to retrieve > >> datastore specific yang-library instance data in a similar way one > >> would use <get-data> to retrieve the datastore contents. In addition a > >> top level config=false container e.g. /datastores with list of > >> supported datastores that does not need to be part of the yang-library > >> module: > >> > >> module: ietf-datastores > >> +--ro datastores > >> | +--ro datastore* [name] > >> | +--ro name identityref > >> > >> Vladimir > >> > >> On 11/09/2017 05:51 PM, Robert Wilton wrote: > >>> > >>> Hi, > >>> > >>> Given some of the feedback related to the complexity of the YANG > >>> library bis structure, we have come up with two other possible > >>> structures for the YANG library data: > >>> > >>> (1) A simplified structure to make YANG library meet the NMDA > >>> requirements, but that is closer to the existing YANG library > >>> structure, and arguably simpler. > >>> (2) An enhanced version of the structure (1) above, that is also > >>> extended to allow the structure to be reused for schema-mount via an > >>> augmentation. > >>> > >>> For reference, at the end of this email, I have also included the tree > >>> diagram of the existing YANG library, and the current YANG library bis > >>> draft (draft-ietf-netconf-rfc7895bis-02) version. > >>> > >>> Considering the two new YANG library structures: > >>> > >>> ------------------------ > >>> > >>> *(1) A simplified structure to make YANG library meet the NMDA > >>> *requirements, but that is closer to the existing YANG library > >>> *structure.* > >>> > >>> The main changes are: > >>> (i) Split "implemented modules" and "import-only-modules" into two > >>> separate lists, making the most important list (i.e. implemented > >>> modules) keyed by module name only and hence easier to reference. > >>> (ii) Assume modules are implemented in all datastores by default (with > >>> a "not-implemented-in" leaflist of datastores that a module is not > >>> implemented in). > >>> (iii) Assume that features are implemented in all datastores by > >>> default (with a "not-implemented-in" leaflist of datastores that a > >>> feature is not implemented in). > >>> (iv) Deleted module-sets. > >>> (v) Datastores are now just a list of supported datastores (that could > >>> potentially be extended with further per datastore properties in > >>> future). > >>> > >>> Manually generated tree output for proposed YANG library: > >>> > >>> module: ietf-yang-library > >>> +--ro yang-library > >>> +--ro modules > >>> | +--ro module* [name] > >>> | | +--ro name yang:yang-identifier > >>> | | +--ro revision? revision-identifier > >>> | | +--ro schema? inet:uri > >>> | | +--ro namespace inet:uri > >>> | | +--ro submodule* [name] > >>> | | | +--ro name yang:yang-identifier > >>> | | | +--ro revision? yang:yang-identifier > >>> | | | +--ro schema? inet:uri > >>> | | +--ro not-implemented-in* > >>> | | | -> /yang-library/datastore/name > >>> | | +--ro feature* [name] > >>> | | | +--ro name yang:yang-identifier > >>> | | | +--ro not-implemented-in* > >>> | | | -> /yang-library/datastore/name > >>> | | +--ro deviation* > >>> | | -> ../name > >>> | | > >>> | +--ro import-only-module* [name revision] > >>> | +--ro name yang:yang-identifier > >>> | +--ro revision union > >>> | +--ro schema? inet:uri > >>> | +--ro namespace inet:uri > >>> | +--ro submodule* [name] > >>> | +--ro name yang:yang-identifier > >>> | +--ro revision yang:revision-identifier > >>> | +--ro schema? inet:uri > >>> +--ro datastore* [name] // Allows future per datastore properties. > >>> | +--ro name identityref > >>> +--ro checksum string > >>> > >>> ------------------------------ > >>> > >>> *(2) An enhanced version of the structure (1) above, that is extended > >>> *to allow the structure to be reused for schema-mount via an > >>> *augmentation.* > >>> > >>> This is similar to the structure above, except that the "the set of > >>> modules" is contained in a list of named schema (e.g. similar to the > >>> schema mount draft), allowing this structure to be re-used for schema > >>> mount. > >>> > >>> Schema mount would be expected to augment yang-library to add in the > >>> additional schema mount information. In the tree diagram, I have > >>> shown the schema-mount mount-point augmentation, but not including > >>> namespaces yet. > >>> > >>> Every server would be required to provide at least one schema in the > >>> schema list, and the primary schema for the device would always be > >>> given the name "primary". > >>> > >>> module: ietf-yang-library > >>> +--ro yang-library > >>> +--ro schema* [name] > >>> | +--ro name string > >>> | +--ro checksum string > >>> | +--ro module* [name] > >>> | | +--ro name yang:yang-identifier > >>> | | +--ro revision? yang:revision-identifier > >>> | | +--ro schema? inet:uri > >>> | | +--ro namespace inet:uri > >>> | | +--ro submodule* [name] > >>> | | | +--ro name yang:yang-identifier > >>> | | | +--ro revision? yang:yang-identifier > >>> | | | +--ro schema? inet:uri > >>> | | +--ro not-implemented-in* > >>> | | | -> /yang-library/datastore/name > >>> | | +--ro feature* [name] > >>> | | | +--ro name yang:yang-identifier > >>> | | | +--ro not-implemented-in* > >>> | | | -> /yang-library/datastore/name > >>> | | +--ro deviation* > >>> | | | -> ../name > >>> | | +- schema-mount:mount-point* [label] > >>> | | +--ro label yang:yang-identifier > >>> | | +--ro config? boolean > >>> | | +--ro (schema-ref) > >>> | | +--:(inline) > >>> | | | +--ro inline? empty > >>> | | +--:(use-schema) > >>> | | +--ro use-schema* [name] > >>> | | +--ro name > >>> | | | -> /yang-library/schema/name > >>> | | +--ro parent-reference* yang:xpath1.0 > >>> | | > >>> | +--ro import-only-module* [name revision] > >>> | +--ro name yang:yang-identifier > >>> | +--ro revision union > >>> | +--ro schema? inet:uri > >>> | +--ro namespace inet:uri > >>> | +--ro submodule* [name] > >>> | +--ro name yang:yang-identifier > >>> | +--ro revision yang:revision-identifier > >>> | +--ro schema? inet:uri > >>> +--ro datastore* [name] // Allows future per datastore properties. > >>> | +--ro name identityref > >>> +--ro checksum string > >>> > >>> Please can you provide comments on these structures, in particular: > >>> > >>> Is this version better (i.e. simpler) that the version currently in > >>> draft-ietf-netconf-rfc7895bis-02 (below)? > >>> > >>> Should we try and make the structure extensible for schema-mount via > >>> augmentation (i.e. version (2)), or is it better that schema-mount has > >>> its own separate subtree? > >>> > >>> For reference only I have included the existing YANG library and YANG > >>> library bis draft tree diagrams. > >>> > >>> Thanks, > >>> Rob > >>> > >>> > >>> ----------------------------- > >>> > >>> *** FOR REFERENCE ONLY *** > >>> > >>> (3) The current YANG library structure in YANG library bis > >>> (draft-ietf-netconf-rfc7895bis-02) > >>> > >>> module: ietf-yang-library > >>> +--ro yang-library > >>> +--ro modules > >>> | +--ro module* [id] > >>> | +--ro id string > >>> | +--ro name yang:yang-identifier > >>> | +--ro revision? revision-identifier > >>> | +--ro schema? inet:uri > >>> | +--ro namespace inet:uri > >>> | +--ro feature* yang:yang-identifier > >>> | +--ro deviation* [module] > >>> | | +--ro module -> ../../id > >>> | +--ro conformance-type enumeration > >>> | +--ro submodule* [name] > >>> | +--ro name yang:yang-identifier > >>> | +--ro revision? revision-identifier > >>> | +--ro schema? inet:uri > >>> +--ro module-sets > >>> | +--ro module-set* [id] > >>> | +--ro id string > >>> | +--ro module* -> ../../../modules/module/id > >>> +--ro datastores > >>> | +--ro datastore* [name] > >>> | +--ro name identityref > >>> | +--ro module-set > >>> | -> ../../../module-sets/module-set/id > >>> +--ro checksum string > >>> > >>> ----------------------------- > >>> > >>> *** FOR REFERENCE ONLY *** > >>> > >>> (4) The current YANG library structure (RFC 7895) > >>> > >>> +--ro modules-state > >>> +--ro module-set-id string > >>> +--ro module* [name revision] > >>> +--ro name yang:yang-identifier > >>> +--ro revision union > >>> +--ro schema? inet:uri > >>> +--ro namespace inet:uri > >>> +--ro feature* yang:yang-identifier > >>> +--ro deviation* [name revision] > >>> | +--ro name yang:yang-identifier > >>> | +--ro revision union > >>> +--ro conformance-type enumeration > >>> +--ro submodule* [name revision] > >>> +--ro name yang:yang-identifier > >>> +--ro revision union > >>> +--ro schema? inet:uri > >>> > >>> > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Robert Wilton
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Martin Bjorklund
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Robert Wilton
- Re: [netmod] [Netconf] Alternative YANG library s… Andy Bierman
- Re: [netmod] [Netconf] Alternative YANG library s… Robert Wilton
- Re: [netmod] [Netconf] Alternative YANG library s… Andy Bierman
- Re: [netmod] [Netconf] Alternative YANG library s… Robert Wilton
- Re: [netmod] [Netconf] Alternative YANG library s… Martin Bjorklund
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Martin Bjorklund
- Re: [netmod] [Netconf] Alternative YANG library s… Juergen Schoenwaelder
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Juergen Schoenwaelder
- Re: [netmod] [Netconf] Alternative YANG library s… Ladislav Lhotka
- Re: [netmod] [Netconf] Alternative YANG library s… Kent Watsen
- Re: [netmod] [Netconf] Alternative YANG library s… Andy Bierman
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Juergen Schoenwaelder
- Re: [netmod] [Netconf] Alternative YANG library s… Robert Wilton
- Re: [netmod] [Netconf] Alternative YANG library s… Robert Wilton
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Juergen Schoenwaelder
- Re: [netmod] [Netconf] Alternative YANG library s… Robert Wilton
- Re: [netmod] [Netconf] Alternative YANG library s… Andy Bierman
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Juergen Schoenwaelder
- Re: [netmod] [Netconf] Alternative YANG library s… Martin Bjorklund
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Martin Bjorklund
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Juergen Schoenwaelder
- Re: [netmod] [Netconf] Alternative YANG library s… Vladimir Vassilev
- Re: [netmod] [Netconf] Alternative YANG library s… Robert Wilton
- Re: [netmod] [Netconf] Alternative YANG library s… Andy Bierman