Re: [netmod] YANG library structure

Lou Berger <lberger@labn.net> Fri, 08 December 2017 11:10 UTC

Return-Path: <lberger@labn.net>
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 23BF6127010 for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2017 03:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 BnVdvD9U16v7 for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2017 03:10:56 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3421200C1 for <netmod@ietf.org>; Fri, 8 Dec 2017 03:10:56 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 30CF11AB245 for <netmod@ietf.org>; Fri, 8 Dec 2017 04:10:55 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id jPAr1w0092SSUrH01PAu9w; Fri, 08 Dec 2017 04:10:55 -0700
X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=ocR9PWop10UA:10 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=L0RXs2Xe9Y4Ek8hgSpIA:9 a=CjuIK1q_8ugA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=pFLttOZSGF1XQiuxSvUTyvVUOTJGUHgzebVLjJato8w=; b=ai5WqD3mBU+24uScI+qZ+QFOqL laZue30jLscogfGq0L9TOJMTVo7imwfWrl2cKVC/kjnHc3ISVOzrj6YQUWRUOqUR+or3jhlmC2Y74 bDs5epNFsxAsBdZJZcz3lHPfo;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:52605 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <lberger@labn.net>) id 1eNGYN-001AcW-35; Fri, 08 Dec 2017 04:10:51 -0700
From: Lou Berger <lberger@labn.net>
To: Martin Bjorklund <mbj@tail-f.com>, <netmod@ietf.org>
Date: Fri, 08 Dec 2017 06:10:49 -0500
Message-ID: <16035d216a8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20171208.104741.1957721911727198135.mbj@tail-f.com>
References: <20171208.104741.1957721911727198135.mbj@tail-f.com>
User-Agent: AquaMail/1.11.0-568 (build: 101100004)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1eNGYN-001AcW-35
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([11.4.0.163]) [100.15.86.101]:52605
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GU23ZeK_5FborHK0d_wX4k981mg>
Subject: Re: [netmod] YANG library structure
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 11:10:59 -0000

Martin,

Thanks for raising this, there's definitely some open issues as well as 
confusion on this topic. In the different options listed below you say that 
each datastore refers to a schema, correct? What is the mechanism you would 
use to do this?

In talking to some others on this topic, they suggested using a library per 
datastore. I haven't look into this enough to know if that is a good or bad 
idea, but it seems functionally equivalent to your first option but 
realized in a different way. Just something to add to the mix.

Lou


On December 8, 2017 4:48:15 AM Martin Bjorklund <mbj@tail-f.com> wrote:

> Hi,
>
> There has been quite a lot of discussion about the YANG library
> data model on the list.  The authors of draft-ietf-netconf-rfc7895bis
> have tried to understand all arguments in the discussion, and provide
> a solution.  Below are 3 solution proposals (we have discussed more,
> but they are basically just variations on the same themes).
>
> Absolute Requirements
> ---------------------
>
> o  RFC 7950, Section 5.6.5 says:
>
>      A server MUST NOT implement more than one revision of a module.
>
> o  draft-ietf-netmod-revised-datastores says:
>
>      The conventional configuration datastores [...] share exactly
>      the same datastore schema
>
> o  draft-ietf-netmod-revised-datastores says:
>
>      The datastore schema for <operational> MUST be a superset of the
>      combined datastore schema used in all configuration datastores
>      except that YANG nodes supported in a configuration datastore MAY
>      be omitted from <operational> if a server is not able to
>      accurately report them.
>
>
> These requirements (of course) still hold, and we think that the YANG
> library document should explain what they imply for the data reported
> as part of the library.  (For example, all conventional datastores
> MUST have a reference to the same "schema").
>
>
> Objectives (in no particular order)
> -----------------------------------
>
> 1. As efficient as possible for a client to consume.
>
>    Since the size of the yang library can be quite large, it should
>    be possible for clients to cache the yang library information.
>
> 2. A dynamic datastore must be able to implement a module or feature
>    that is not implemented in the conventional datastores.
>
> 3. It must be possible to NOT implement a module or feature in
>    operational, even if it is implemented in some other datastore.
>
>    This is required for transition purposes; a server that wants to
>    implement <operational> should not have to implement all modules at
>    once.
>
> 4. A given module can only be implemented in one revision in all
>    datastores.  If a module is implemented in more than one
>    datastores, the same revision is implemented in all these
>    datastores.
>
> 5. Multiple revisions can be used for import, if import-by revision
>    is used.
>
> 6. Nice to have: make it possible to be used by schema mount
>
>
> It should be noted that because of 2 and 3 (and 6), the original data
> model in RFC 7895 cannot be used.
>
>
> Use Cases
> ---------
>
> Here's a set of use cases that must be supported.
>
>   C1. conventional + operational, all have the same schema
>
>   C2. conventional + operational, ietf-hardware is not implemented in
>       conventional
>
>   C3. conventional + operational, some modules not yet implemented in
>       operational, and some modules are partly implemented in
>       operational.
>
>   C4. conventional + operational + ephemeral, ephemeral has its own
>       set of modules
>
>
>
> Alt. A.
> -------
>
>   Each datastore refers to a schema, and each schema contains a flat
>   list of all modules, features, etc.
>
>     +--ro yang-library
>        +--ro schema* [name]
>        |  +--ro name                  string
>        |  +--ro checksum              string
>        |  +--ro module* [name]
>        |  |  +--ro name         yang:yang-identifier
>        |  |  +--ro revision?    revision-identifier
>        |  |  +--ro namespace    inet:uri
>        |  |  +--ro location*    inet:uri
>        |  |  +--ro submodule* [name]
>        |  |  |  +--ro name        yang:yang-identifier
>        |  |  |  +--ro revision?   revision-identifier
>        |  |  |  +--ro location*   inet:uri
>        |  |  +--ro feature* [name]
>        |  |  |  +--ro name    yang:yang-identifier
>        |  |  +--ro deviation* [module]
>        |  |     +--ro module    -> ../../name
>        |  +--ro import-only-module* [name revision]
>        |     +--ro name         yang:yang-identifier
>        |     +--ro revision     union
>        |     +--ro namespace    inet:uri
>        |     +--ro location*    inet:uri
>        |     +--ro submodule* [name]
>        |        +--ro name        yang:yang-identifier
>        |        +--ro revision?   revision-identifier
>        |        +--ro location*   inet:uri
>        +--ro datastore* [name]
>        |  +--ro name      identityref
>        |  +--ro schema    -> ../../schema/name
>        +--ro checksum     string
>
>
>   How does this solution handle the use cases above?
>
>   C1: One schema, all datastores refer to this schema.
>
>   C2: Two schemas, "conventional" and "operational".  They differ in
>       just one element (ietf-hardware).  All other module information
>       is entirely duplicated in both.
>
>   C3: Two schemas, "conventional" and "operational".  They differ in
>       the modules not implemented in operational, and operational also
>       has some deviation modules with "not-implemented".
>
>   C4: Three schemas, "conventional", "ephemeral", "operational".
>       "operational" contains the union of all modules in the other
>       two.
>
>
>   Pro: simple on the client, simple on the server
>
>   Con: verbose, since a single difference requires a complete, new,
>        schema.
>
>
> Alt. B.
> -------
>
>   Each datastore refers to a schema, and each schema contains a list
>   of references to module-sets, and each module-set contains a flat
>   list of all modules, features, etc.
>
>   When combining module-sets into a schema there MUST NOT be any
>   duplicate module definitions in the module-sets.
>
>
>     +--ro yang-library
>        +--ro module-set* [name]
>        |  +--ro name                  string
>        |  +--ro checksum              string
>        |  +--ro module* [name]
>        |  |  +--ro name         yang:yang-identifier
>        |  |  +--ro revision?    revision-identifier
>        |  |  +--ro namespace    inet:uri
>        |  |  +--ro location*    inet:uri
>        |  |  +--ro submodule* [name]
>        |  |  |  +--ro name        yang:yang-identifier
>        |  |  |  +--ro revision?   revision-identifier
>        |  |  |  +--ro location*   inet:uri
>        |  |  +--ro feature* [name]
>        |  |  |  +--ro name    yang:yang-identifier
>        |  |  +--ro deviation* [module]
>        |  |     +--ro module    -> ../../name
>        |  +--ro import-only-module* [name revision]
>        |     +--ro name         yang:yang-identifier
>        |     +--ro revision     union
>        |     +--ro namespace    inet:uri
>        |     +--ro location*    inet:uri
>        |     +--ro submodule* [name]
>        |        +--ro name        yang:yang-identifier
>        |        +--ro revision?   revision-identifier
>        |        +--ro location*   inet:uri
>        +--ro schema* [name]
>        |  +--ro name          string
>        |  +--ro checksum      string
>        |  +--ro module-set*   -> ../../module-set/name
>        +--ro datastore* [name]
>        |  +--ro name      identityref
>        |  +--ro schema    -> ../../schema/name
>        +--ro checksum      string
>
>   How does this solution handle the use cases above?
>
>   C1: One module-set, one schema, all datastores refer to this schema,
>       the schema refers to the single module-set.
>
>   C2: Two schemas, "conventional" and "operational", and two
>       module-sets.  One module-set contains just "ietf-hardware" and
>       the other everything else.  The "operational" schema refers to
>       both module-sets, and the "conventional" to just the one without
>       "ietf-hardware".
>
>   C3: Two schemas, "conventional" and "operational", and three
>       module-sets.  One module-set contains all modules fully
>       implemented in both conventional and operational, one contains
>       the modules implemented only in conventional, and one the
>       modules and deviations for the partly implemented modules in
>       operational.
>
>   C4: Three schemas, "conventional", "ephemeral", "operational", but
>       just two module-sets. "conventional" refers to one of the
>       module-sets, and "ephemeral" to the other.  "operational" refers
>       to both.
>
>   Pro: less verbose
>
>   Con: the client has to follow extra references and must combine the
>        result from the references into a single schema.
>
>
> Alt. C.
> -------
>
>   (This is the draft -02 version with just some name changes)
>
>   Each datastore refers to a schema, and each schema contains a list
>   of references to each module it includes.
>
>     +--ro yang-library
>        +--ro module* [id]
>        |  +--ro id                  string
>        |  +--ro name                yang:yang-identifier
>        |  +--ro revision?           revision-identifier
>        |  +--ro location*           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 location*   inet:uri
>        +--ro schema* [name]
>        |  +--ro name      string
>        |  +--ro module*   -> ../../module/id
>        +--ro datastore* [name]
>        |  +--ro name          identityref
>        |  +--ro schema    -> ../../schema/name
>        +--ro checksum       string
>
>   How does this solution handle the use cases above?
>
>   C1: One schema, all datastores refer to this schema,
>       the schema refers to all modules.
>
>   C2: Two schemas, "conventional" and "operational", and the module
>       list contains all modules.  The "operational" schema refers to
>       all modules, and "conventional" to all modules except
>       "ietf-hardware".
>
>   C3: similar to C2, except there will be two entries in the module
>       list for evenry module that is partly implemented in
>       operational.
>
>   C4: Three schemas, "conventional", "ephemeral", "operational", and
>       the module list contains all modules.
>       Each schema refers to the modules it supports.
>
>   Pro: All modules available are listed in one place.
>
>   Con: the client has to follow extra references and must combine the
>        result from the references into a single schema.
>
>        the least "direct" solution due to the module "id".
>
>        probably a bit tricky to implement on the server.
>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>