Re: [netmod] schema mount open issue #1

["Xufeng Liu" <[e-mail]>]

> -----Original Message-----
> From: netmod [mailto:[e-mail]] On Behalf Of Lou Berger
> Sent: Tuesday, August 29, 2017 8:35 AM
> To: Martin Bjorklund <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [netmod] schema mount open issue #1
> 
> 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.)
> 
[Xufeng] To me, the statement "mount-point" is confusing, because it
indicates more like an object such as "leaf", "leaf-list", or "list", rather
than a property such as "presence" or "must". It would be better to make the
name sound more towards "making the container a mount point". The following
current description on the mount-point statement does not make this better:

       description
         "The argument 'name' is a YANG identifier, i.e., it is of the
          type 'yang:yang-identifier'.
          ...
          A mount point defines a place in the node hierarchy where
          other data models may be attached.
          ...";

Added to the confusion is the history of LNE and NI models, which initially
used "leaf root", then "anydata root", and then changed to "mount-point
root". Since the beginning, the "root" has always been shown in the tree
view, just like a "leaf" (not like the "presence"). In the Sec 4 of the
current draft-ietf-netmod-schema-mount-06, there still the following tree:

     +--rw interfaces
     |  +--rw interface* [name]
     |     ...
     +--rw network-instances
        +--rw network-instance* [name]
           +--rw name
           +--rw root
              +--rw routing
                 ...

   Here, the "root" node is the mount point for the NI schema.

In a container, it is confusing syntax to use the similar substatement
syntax for both property and contained objects, but this is beyond the
point.

Thanks,
- Xufeng

> Lou
> 
> 
> >
> > /martin
> >
> >
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod