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