[netmod] js review of draft-ietf-netmod-schema-mount-09
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 29 March 2018 09:03 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
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 40E5E12D87C for <netmod@ietfa.amsl.com>; Thu, 29 Mar 2018 02:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 xBFDMdlulrPh for <netmod@ietfa.amsl.com>; Thu, 29 Mar 2018 02:03:11 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E111241F3 for <netmod@ietf.org>; Thu, 29 Mar 2018 02:03:09 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E387EDF6 for <netmod@ietf.org>; Thu, 29 Mar 2018 11:03:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id GaxlZgL0Gro4 for <netmod@ietf.org>; Thu, 29 Mar 2018 11:03:07 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Thu, 29 Mar 2018 11:03:07 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDE0B20035 for <netmod@ietf.org>; Thu, 29 Mar 2018 11:03:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id O0WH1Z5P5Ncn; Thu, 29 Mar 2018 11:03:07 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08A0C20031; Thu, 29 Mar 2018 11:03:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0048542A24E1; Thu, 29 Mar 2018 11:03:05 +0200 (CEST)
Date: Thu, 29 Mar 2018 11:03:05 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netmod@ietf.org
Message-ID: <20180329090305.eqshcqvqo33r5bsf@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/5kgQFDfVRjPKyFlGXWKd_x-l91M>
Subject: [netmod] js review of draft-ietf-netmod-schema-mount-09
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, 29 Mar 2018 09:03:18 -0000
Here is my review of draft-ietf-netmod-schema-mount-09. * Abstract This document defines a mechanism to combine YANG modules into the schema defined in other YANG modules. I do not know what this says - I think this text is confusing. What does it mean to 'combine' YANG modules? What is the notion of 'schema' used here? Does the text help someone to decide whether this mechanisms is something worth to study in order to solve a given modeling problem? (A good abstract would IMHO do that.) Note that the mount mechanisms has serious limitations as well that perhaps need to spelled out right up-front, i.e., it only works with pre-defined mount-points (augments are much more flexible in this regard, the schema mount defined here is by its very design not very flexible. * Introduction s/Furthermore,// 'In some cases' ... 'often' - hm is this something that is required occasionally or often? There are more uses of fill words like 'often' that do not really seem to be needed. s/new generic mechanism/new mechanism/ While I think I understand the difference made between implementation-time and run-time, the description is somewhat confusing since the run-time mount will also be exposed via YANG library and hence defining implementation-time by 'defined by a server implementor and is as stable as YANG library information of the server' is somewhat fuzzy. I assume what you mean is that in the case 2. the mounted schema is fixed at implementation time while in the case 3. the mounted schema may vary and be discovered at run-time. However, you do not define things this way but rather talk about properties that do however not define things. * Glossary of New Terms o top-level schema: a schema according to [RFC7950] in which schema trees of each module (except augments) start at the root node. You do not import 'schema' from RFC 7950 since, well, it is not defined in RFC 7950. I think you often mean a schema tree (as defined in RFC 7950) when you use 'schema'. Well, even this is not true since a 'schema tree' according to RFC 7950 is scoped to a module. RFC 8342 defines a 'datastore schema' but then I am not sure this corresponds to 'schema' as used in this draft. In fact, the mounted schema may be considered part of the 'datastore schema'. I think we are handwaving with our terminology here but then perhaps I am the only one who cares... What we actually have are schema tree (of a module per RFC 7950) and a collection of schema trees sharing a common root (this is likely what is meant with "schema" in this document). And then schema mount simply provides a mechanism to have additional (statically defined) roots in a schema. * Specification of the Mounted Schema I still struggle with the term 'inline' (and to a lesser extend with 'shared'). I am likely in the minority. * Multiple Levels of Schema Mount What is a 'subschema'? What is a 'schema level'? Is a subschema the same as a schema, i.e. a collection of schema trees with a common root? If we need terms such as 'subschema' or 'schema level', then we should define them. But perhaps just some tweaking the text to avoid new terms can solve the issue. * Referring to Data Nodes in the Parent Schema I stumbled across this here but in general is 'data model' the same as 'schema'? Note that the text in section 4 talks about 'mounted data model' and 'top-level data model' and 'mounted data model' but elsewhere you talk about * schemas. Perhaps using just one term is better and more consistent? Why are parent-references only useful for the 'shared-schema' case? An 'inline' mount can't refer to stuff outside the mount jail? Looking at the YANG definition of 'parent-reference', I am left somewhat clueless in which situations these xpath expressions are evaluations and when the nodesets are merged with other xpath expression evaluation results. It seems that these parent references are the only actual difference between 'inline' and 'shared-schema' mounts. * Data Model I have not really understood what the difference between 'inline' and 'shared-schema' is. I understand that the later can have 'parent-references' but it is unclear why the other can't and if there is not strong architectural reason why there have to be two choices. It also seems that the 'namespace' list is only meaningful if there are parent references, no? So why is this then global, i.e. also provided for 'inline' mounts? I guess I do not really understand the distinction. If there are no parent-references, what is the difference between 'shared-schema' and 'inline'? * Security Considerations I agree with others that something needs to be said how NACM applies to mounted schemas. /js PS: I have not checked the examples in the appendix. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
- [netmod] js review of draft-ietf-netmod-schema-mo… Juergen Schoenwaelder
- Re: [netmod] js review of draft-ietf-netmod-schem… Martin Bjorklund
- Re: [netmod] js review of draft-ietf-netmod-schem… Juergen Schoenwaelder
- Re: [netmod] js review of draft-ietf-netmod-schem… Martin Bjorklund
- Re: [netmod] js review of draft-ietf-netmod-schem… Juergen Schoenwaelder
- Re: [netmod] js review of draft-ietf-netmod-schem… Martin Bjorklund
- Re: [netmod] js review of draft-ietf-netmod-schem… Juergen Schoenwaelder
- Re: [netmod] js review of draft-ietf-netmod-schem… Martin Bjorklund
- Re: [netmod] js review of draft-ietf-netmod-schem… Juergen Schoenwaelder
- Re: [netmod] js review of draft-ietf-netmod-schem… Martin Bjorklund
- Re: [netmod] js review of draft-ietf-netmod-schem… Lou Berger