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

Andy Bierman <andy@yumaworks.com> Thu, 16 November 2017 02:42 UTC

Return-Path: <andy@yumaworks.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 DF680126DFB for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 18:42:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 jouwkw-fFQyH for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 18:42:24 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9223012940B for <netmod@ietf.org>; Wed, 15 Nov 2017 18:42:23 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id i14so552005lfc.1 for <netmod@ietf.org>; Wed, 15 Nov 2017 18:42:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yRhikocCnyKm2xoZpv4Ij5OtGYqsJiUGNvL5cGEThcY=; b=U3nzQEo7ipZ0Ch+C2sCyZTCaxNP77mcDnh+tN/MTjMUxzqL88h87eBVcjv0OhZVitB LGcpAO7+ih9vZjmUsImgVreejVlYMBHe3r3ZER8r3jMZx76GEcfsrBkGOIRbJF/AHJaJ fqYGsf4aOgqmsf017DMpxUVBfghOxQVK41yhuq6WY9/pp3paLZBZ6vxDHuM0O3wESqz/ 5dzMTcQjEdxgeNkuLNeVOinJKpn1CAj/Tpl1RbEKJJ9nvYhzqIAx+Totl78K+ZunV37o UzUJn53OalTMaSczhsgJNqzdEhTa09OHs8rqINyxCBt1e3N/aVC0PRbepP4AE8T7N2KA KyAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yRhikocCnyKm2xoZpv4Ij5OtGYqsJiUGNvL5cGEThcY=; b=gmk4qhyr96oXCgN09/1KynsG7qNDXAttFBmDgrj8wx6n+VqIBz64mTqyS00pWLt0h5 0Ei1JyqtFGA6kCTDl9nhuJCkrDm2HJwCuKUb8jIuDyNEjwj/T0YIlG00Mc+ettttoPEm v7ufzObGG7nz2jmFUJ86gSykUC+riPzQAfNr3eDiibDtLf546gbde9ioYFUuludG1Uri pzNE4GmxaHz0INMRa1EXRBgpLAEIHoYIsCPeCs3P+RxLFNtuKmJKdK8vyjbyo3Trz3BO 01EksSnB/VcNxPO4DsAHyFujPFnb4+q9Z36hS8MamF+2SHZlmLDwn555FppvczTkOURs r35A==
X-Gm-Message-State: AJaThX7Ts7vWgcTe0Rw1o+eSigZxXUYX3yRx9bkssG+QvJ798nPCdtKk sA2aW9b9u7WSt/U0topsHNRTAtXooRQ+0ePhz7F/rw==
X-Google-Smtp-Source: AGs4zMYeSfdBmT6uxSIe+/qQfxkqosR9gPZJgubv0+yOva0QC2xPsqqx7B9twqqyYvSmFdjhtobuxSyZIbK6RladdYo=
X-Received: by 10.25.225.140 with SMTP id l12mr51953lfk.106.1510800141701; Wed, 15 Nov 2017 18:42:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Wed, 15 Nov 2017 18:42:20 -0800 (PST)
In-Reply-To: <a5e7e88a-bd15-f9e9-5a1c-58497b6c84cb@cisco.com>
References: <e35fe233-af5b-58f2-35e4-901eb7eea454@cisco.com> <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <CABCOCHS_uni9xJxS=+1-R7LcA35WiVxLPAeFO=NgL+RnFDVc8w@mail.gmail.com> <a5e7e88a-bd15-f9e9-5a1c-58497b6c84cb@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 15 Nov 2017 18:42:20 -0800
Message-ID: <CABCOCHQsai2t72RC2WbwYcr80DOZZmfVXF94XEmkVhVXnT=gOg@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Vladimir Vassilev <vladimir@transpacket.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a113c2f46c5eaf3055e1091c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/qiw_JbzGjOP14MpaCx7szvvZQEs>
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: Thu, 16 Nov 2017 02:42:30 -0000

On Wed, Nov 15, 2017 at 4:53 PM, Robert Wilton <rwilton@cisco.com> wrote:

> Hi Andy,
>
> On 16/11/2017 02:29, Andy Bierman wrote:
>
> Hi,
>
> The per-datastore feature aspect of NMDA is a new and significant change
> to YANG.
>
>     |  |  +--ro feature* [name]
>     |  |  |  +--ro name        yang:yang-identifier
>     |  |  |  +--ro not-implemented-in*
>     |  |  |              -> /yang-library/datastore/name
>
>
> YANG does not define feature conformance at this granularity.
> I strongly object to this change to YANG conformance.
> A server can only advertise a YANG feature if it implemented on the entire
> server.
>
>
> This extra complexity is not present on the openconfig solution or
> requirements.
>
> In terms of comparison, it definitely is:
> - you can have different features for the config and state trees (e.g.
> "router-id" feature in RFC 8022).
> - sometimes the conventions are not followed completely consistently, e.g.
> different types, or semantics between config and state.
> - sometimes the structures differ between config and state.
>
> So, the problem comparing between config and state is not easier in either
> the IETF split tree or OpenConfig solutions.
>
> Comparing any datastore to <operational> is much more complex (any may not
> be possible)
> if the features are different for a given module.
>
> You can always compare (except deviations in operational).  If a feature
> is enabled on any configuration datastore then it must also be enabled on
> operational.
>
>
This is not apparent from the text. The draft-02 library is very out of
date at this point.

I only care about restricting the conventional datastores, <intended> and
<operational>.
It will be a massive client rewrite if the client cannot compare <intended>
to <operational>
with 1 schema tree.

If the updated draft reflects the feature-in-operational requirement above
then
I have no objections to the proposed YANG library functionality.

I am still concerned about per-datastore deviations.
IMO, the server MUST implement the same deviations in these special
datastores.
If that cannot be done, the operational node will not be present. Another
leaf node
(like admin-state/oper-state) needs to be used instead.

If the server does implement per-datastore deviations,
clients may not work (if they use the conventional datastore schema tree
for <operational>).
The same thing happens if the client ignores plain-old-deviations now,
so this is not a big deal.




E.g.  take "router-id" feature from RFC8022bis (that was also defined in
> RFC8022).
>
> This feature can be enabled:
> (i) everywhere (i.e. <conventional> + <i2rs-ephemeral> + <operational>), or
> (ii) <conventional> + <operational>, or
> (iii) <i2rs-ephemral> + <operational>, or
> (iv) <operational> only, or
> (v) or in none of them.
>
>

I still think the WG needs to define YANG conformance for datastores,
The question "what datastores does server implementation X support for
module foo?" is covered.
The question "what datastores MUST, SHOULD, MAY a compliant server
implementation
support for module foo?" is totally ignored.


Hence, <operational> always contains a superset of the nodes.
>
>
> I do not see how <operational> can be true superset of the conventional
> datastores
> if the features are different.
>
>
> Because of the statement above.
>
> Thanks,
> Rob
>
>


Andy


>
>
> Andy
>
>
> On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
>> I don't think that this is really a good idea.  You would end up
>> returning server metadata in addition to the configuration.
>>
>> I still think that the YANG library proposal is the best solution.
>>
>> 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 listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>
>