Re: [netmod] schema mount open issue #1

[Per Hedeland <[e-mail]>]

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:

# 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
>