Re: [netmod] schema mount open issue #1

[Martin Bjorklund <[e-mail]>]

Lou Berger <[e-mail]> 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íše 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.
> 
> > 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.)

I was thinking about this as well, but I thought that maybe rejecting
any other data node is a CLR.  Maybe there is a good use case for
e.g. an action in a mount point.


/martin