Re: [netmod] schema mount open issue #1

[Martin Bjorklund <[e-mail]>]

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.

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, 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).

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.

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.


/martin