On 2017-08-29 15:40, Lou Berger wrote: > > > On August 29, 2017 9:03:22 AM Per Hedeland <[email protected]> wrote: > >> 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: >> > > This point was at the root of the discussion of whether or not we even needed > the mount Point extension at all and whether just having the scheme amount > module identify mounts with in a container was > sufficient. > > I believe the perspective from Lada and Martin was that it didn't really add > value. Those of us in the routing area working on models using scheme mount > uniformly agreed that it was important to keep > the extension to enable module designers to indicate to implementers where > Mount points were intended to be used in the modules they were defining and > for client users/ implementers to reliably > identify where modules would be mounted. We also thought that the use of the > mount Point extension in modules would have certain tooling benefits over > just putting a comment in the description of a > container that it was to be used as a mount point. > > Yes, we can make the current node-less Mount Point extension work, but it > certainly seems like a clumsier and more complex solution
Well, my comment *only* addressed your repeated claim that it was different from file system semantics - I can't see that it is. The mount-point extension does not define a data node. Mounting a file system does not create a directory node. Whether this is a strong argument for the non-data-node-defining semantics of mount-point is perhaps a subjective matter. --Per > Lou > > > > >> # 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
