Hi, Juergen Schoenwaelder <[email protected]> wrote: > On Thu, Apr 05, 2018 at 02:33:40PM +0200, Martin Bjorklund wrote: > > Hi, > > > > Thank you for this review! Comments inline. > > > > Juergen Schoenwaelder <[email protected]> wrote: > > > 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? > > > > Howabout: > > > > This document defines a mechanism to add the schema trees defined by > > a set of YANG modules into the schema tree defined in another YANG > > module. > > > > This is better. > > > (see more below on terminology) > > > > > 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. > > > > I don't agree that this is a "serious limitation", and I don't think > > an abstract should list things that the document doesn't do. > > OK. Remove 'serious' but clearly this schema mount mechanism is not as > flexible as it could me. What about this: > > This document defines a mechanism to add the schema trees defined > by a set of YANG modules onto mount points defined in another YANG > module. > > This at least hints at the fact that mount points are rather static > citizens.
Ok. I tweaked it to: This document defines a mechanism to add the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in some YANG module. > > > 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. > > > > Howabout: > > > > OLD: > > > > + Run-time: the mounted schema is defined by instance data that is > > part of the mounted data model. If there are multiple instances of > > the same mount point (e.g., in multiple entries of a list), the > > mounted data model may be different for each instance. > > > > NEW: > > > > + Run-time: the mounted schema can vary at run time and is defined by > > instance data that is part of the mounted data model. If there are > > multiple instances of the same mount point (e.g., in multiple > > entries of a list), the mounted data model may be different for each > > instance. > > Better. > > > > * 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... > > > > I have imported "schema tree" from 7950, and changed teh definition of > > top-level schema to: > > > > - top-level schema: a set of modules in which the schema > > trees of each module (except augments) start at the root node. > > Still sounds complicated and not quite clear. Do you mean this: > > - top-level schema: a set of schema trees of a set of modules starting > at the root node > > > > 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. > > So what are you planning to do about the term 'schema' used throughout > the module? We kind of define what a top-level schema is but leave > schema undefined and perhaps we would also benefit from having a term > like mounted schema. I am thinking along these lines: > > schema = collection of schema trees with a common root > top-level schema = schema rooted at the root node > mounted schema = schema rooted at a mount point > parent schema (of a mounted schema) = schema containing the mount point These are good definitions, I have added them. Thank you! > > > * 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. > > > > I have changed "subschema" to "schema", and removed "schema level": > > > > NEW: > > > > YANG modules in a mounted schema MAY again contain mount points > > under which other schemas can be mounted. Consequently, it is > > possible to construct data models with an arbitrary number of > > mounted schemas. A schema for a mount point contained in a mounted > > module can be specified by implementing "ietf-yang-library" and > > "ietf-yang-schema-mount" modules in the mounted schema, and > > specifying the schemas exactly as it is done in the top-level > > schema. > > OK > > > > Why are parent-references only useful for the 'shared-schema' case? > > > An 'inline' mount can't refer to stuff outside the mount jail? > > > > Correct. We have debated if this makes sense for inline or not. As > > it is, the model is designed so that this can be added in the future, > > if it turns out that this is needed. > > OK > > > > 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. > > > > The YANG module says: > > > > When XPath expressions in the mounted schema > > are evaluated, the 'parent-reference' leaf-list is taken > > into account. > > > > and > > > > For the purposes of evaluating XPath > > expressions whose context nodes are defined in the > > mounted schema, the union of all these nodesets > > together with ancestor nodes are added to the > > accessible data tree. > > OK. I probably did not read carefully enough. My understanding is now > that the set of parent-reference xpath expressions yields a union of > nodesets that are becoming part of the context for the evaluation of > any xpath expression appearing in a mounted schema. And these parent > references are specific to a mount point instance. May make sense. > > > > 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? > > > > As you note, the 'namespace' list is global, so there is just one list > > that covers all mount-points. It's not really correct to state that > > the 'namespace' list is "provided for 'inline' mounts". > > OK. It seems that for a client capable to support a 'shared schema', > the 'inline' schema really is just a special case without parent > references. (I wonder whether anything should be said to YANG library > version numbers, whether they are always scoped by the mount point > or have meaning across mount points; if two YANG library instances > in mounted schemas have the same version number, does this imply > that these YANG library instances are identical or is this just a > version number clash? But then this probably goes across the spirit > of not talking about YANG library too much.) When you say "version number" do you mean the YANG library checksum? I don't think the YL document guarantees that there can never be clashes. > > > I guess I do not really > > > understand the distinction. If there are no parent-references, what > > > is the difference between 'shared-schema' and 'inline'? > > > > The difference is that shared-schema can have parent-references, and > > that all instances of such a mount point have exactly the same > > schema. > > See comment above about YANG library version numbers. I am trying to > understand which assumption a client can make to be efficient in both > cases (and whether it is possible to be efficient while essentially > handling inline and shared-schema using a common approach). > > > > * Security Considerations > > > > > > I agree with others that something needs to be said how NACM applies > > > to mounted schemas. > > > > I have added the following (short) section: > > > > 7. Interaction with the Network Configuration Access Control Model > > (NACM) > > > > If NACM [RFC8341] is implemented on a server, it can be used to > > control access to nodes defined by the mounted schema in the same way > > as for nodes defined by the top-level schema. > > > > For example, suppose the module "ietf-interfaces" is mounted in the > > "root" container in the "logical-network-element" list defined in > > [I-D.ietf-rtgwg-lne-model]. Then the following NACM path can be used > > to control access to the "interfaces" container (where the character > > '\' is used where a line break has been inserted for formatting > > reasons): > > > > <path xmlns:lne= > > "urn:ietf:params:xml:ns:yang:ietf-logical-network-element" > > xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"> > > /lne:logical-network-elements\ > > /lne:logical-network-element/lne:root/if:interfaces > > </path> > > This helps. Can I also mount NACM into a mount point? If yes, what if > both are present? Yes you can mount NACM. To keep things simple, I think the inner NACM should not affect the access control done in the parent. Consider the use cases for this. In a NI situation, it doesn't make much sense to mount NACM. In an LNE (or in a "peer mount") situation, it may make sense to mount NACM if the LNE (or device) supports it. In this case, if I try to access any mounted data in the parent, access is controlled by the parent. If I have access, the parent may send a request over to the mounted device to read/write the data. That device will use its local copy of NACM to control access, or some other mechanism. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
