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

Vladimir Vassilev <vladimir@transpacket.com> Fri, 08 December 2017 14:36 UTC

Return-Path: <vladimir@transpacket.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 EEA75124D37 for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2017 06:36:25 -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 iv86Yz3O58iS for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2017 06:36:22 -0800 (PST)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6695A1243FE for <netmod@ietf.org>; Fri, 8 Dec 2017 06:36:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id A61E51540892; Fri, 8 Dec 2017 15:36:20 +0100 (CET)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wDMKGCuadGUC; Fri, 8 Dec 2017 15:36:20 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 7ADC71540898; Fri, 8 Dec 2017 15:36:20 +0100 (CET)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OPJ6-2eeHT8l; Fri, 8 Dec 2017 15:36:20 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 560941540892; Fri, 8 Dec 2017 15:36:20 +0100 (CET)
To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <e35fe233-af5b-58f2-35e4-901eb7eea454@cisco.com> <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com>
From: Vladimir Vassilev <vladimir@transpacket.com>
Message-ID: <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com>
Date: Fri, 08 Dec 2017 15:36:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_b1SN5iTbn6_BORygbpvIMf4WQM>
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 14:36:26 -0000

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

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
>>
>