On 2017-08-29 14:34, Lou Berger wrote: > On 08/29/2017 03:37 AM, Martin Bjorklund wrote: >> Lou Berger <[email protected]> wrote: >>> Lada, >>> >>> >>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote: >>>> Lou Berger píae v Po 28. 08. 2017 v 09:40 -0400: >>>>> Lada, >>>>> >>>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote: >>>>>>> Can you please take a look at it and see if we have any other >>>>>>> disconnects? >>>>>> This is really scary. >>>>> I agree! >>>>> >>>>>> How can we expect poor data modellers to understand the >>>>>> concept if we have such fundamental disconnects, after so many hours of >>>>>> discussing it? >>>>> This highlights why getting the text in (any) document is so important, >>>>> and why discussions shouldn't be viewed as being closed until the impact >>>>> on the text is agreed to! >>>> I think many people still don't make much distinction between schema mount >>>> (manipulation of the schema) and data mount. I still believe we need to >>>> clearly >>>> separate these two concepts, preferably using two different mechanisms. >>> >>> Frankly, I'm focused on removing blocking issues on the current WG >>> deliverable, i.e., schema mount. >>> ... >>>>> Lou >>>>> >>>>> PS is your view aligned with martin or our example? >>>> If you mean shifting the XPath context node to the mount point instance, >>>> then >>>> yes. >>> >>> funny, you answered yes to a choice! I was asking if you think the >>> mount point shows up as a node in the data tree, i.e., as shown in the >>> example in >>> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1? >>> >>> from my perspective and my co-authors in the RTG area using schema >>> mount, we've never heard of a (filesystem) mount point that doesn't show >>> in the (directory) structure and this is the mental analogue we've been >>> assuming. Since there never was an explicit example/discussion or text >>> to dissuade us of this >> >> The current text says: >> >> A "container" or "list" node becomes a mount point if the >> "mount-point" extension (defined in the "ietf-yang-schema-mount" >> module) is used in its definition. > > interesting, read that a few times to (now) get the gist of your intent. > >> >> But of course we should clarify this. >> > > > >>> , this disconnect was never noticed. Certainly >>> this needs to be explicit in the document (either way). The following >>> change could be made to the schema mount draft (at a minimum): >>> >>> OLD >>> A mount point defines a place in the node hierarchy where >>> other data models may be attached. A server that implements a >>> NEW >>> A mount point defines a node in a data tree under which >>> instances of >>> other data models may be attached. A server that implements a >> >> I strongly object to letting the extension define a new data node. > >> This would be a new type of data node that presumably look a lot like >> a container, > > agreed, just like a mount point looks a lot like a directory in a unix > file system.
It seems to me that the schema mount concept is 100% equivalent to the Unix file system analogy in this particular respect. You need a pre-existing directory to mount a remote file system (or for that matter a disk device). The directory gains the property of being a mount point by the process of mounting, and loses it by the process of unmounting: # mount earth:/home /foo mount: /foo: No such file or directory # mkdir /foo # mount earth:/home /foo # ls /foo (... lots of user directories ...) # umount /foo # ls /foo # --Per >> and you'd have to define all sorts of rules for this new >> node (how it is encoded in XML, JSON, CBOR; how it is handled in >> edit-config, how it is mapped to RESTCONF resources etc etc). > > I'm don't see this, the rules would be the same as a container, as in > "mount points in data trees are encoded identically as containers". > >> >> If you thought that the extension implicitly creates a node, adding an >> explicit container won't do any harm; it will not change the schema >> tree from what you thought it was. > > Well we could make this work, but it feels like every model that uses > schema has added complexity to its definition and use to perhaps avoid > making some minor tooling changes. Keep in mind that any use of the > mount point extension will required changes in tooling. > >> >> But I think we should also restrict the mount-point extension so that >> there cannot be more than one mount-point in a given container. >> > In this case, I'd go further and say that the only thing in the > container (of the module schema) is the mount point and a mount point > extension is only valid within a container. (Then the semantics are the > same as we expected, just the syntax is different.) > > Lou > > >> >> /martin >> >> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
