Re: [netmod] schema mount open issue #1

[Per Hedeland <[e-mail]>]

On 2017-08-29 15:40, Lou Berger wrote:
> 
> 
> On August 29, 2017 9:03:22 AM Per Hedeland <[e-mail]> wrote:
> 
>> On 2017-08-29 14:34, Lou Berger wrote:
>>> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>>>> Lou Berger <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
> 
>