Re: [netmod] Comparison of structural-mount and ysdl drafts

["Eric Voit (evoit)" <[e-mail]>]

Robert,

Per (1) below, if you are looking to mount yang from one device to another, the drafts to look at are:
   draft-clemm-netmod-mount-03
   draft-voit-netmod-peer-mount-requirements-03

At this point NETMOD as a whole has not attempted to address whether any common syntax or requirements should bind this aggregate set of four drafts.

Eric


> -----Original Message-----
> From: netmod [mailto:[e-mail]] On Behalf Of Ladislav Lhotka
> Sent: Friday, January 22, 2016 10:00 AM
> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
> Cc: [e-mail]
> Subject: Re: [netmod] Comparison of structural-mount and ysdl drafts
> 
> 
> > On 22 Jan 2016, at 14:28, Robert Wilton <[e-mail]> wrote:
> >
> > Hi Lada,
> >
> > Please see inline ...
> >
> > On 22/01/2016 12:41, Ladislav Lhotka wrote:
> >> Robert Wilton <[e-mail]> writes:
> >>
> >>> Hi Lada, Martin,
> >>>
> >>> I've reviewed both draft-bjorklund-netmod-structural-mount-00 and
> >>> draft-lhotka-netmod-ysdl-00.
> >>>
> >>> In comparing these two drafts, the main differences that I perceive are:
> >>>
> >>> 1) structural-mount allows the mounted data model to publish its
> >>> supported schema at the mount point, but ysdl requires the mounting
> >>> device to know and publish the schema for all mounted data models.
> >> I am not sure what you mean by "publish" but I think really the only
> >> difference is that structural-mount provides schema information as
> >> regular state data and YSDL as meta-data.
> > I was really referring to the inline-yang-library option in structural mount that
> allows the actual YANG schema to be deferred to the mounted device
> implementing yang-library (and which is available at the mount point).  This is
> the option that I would anticipate would be used in the LNE model.
> 
> YSDL doesn't address any kind of remote mounts. It just adds a pull-style method
> for the schema construction but everything is local to the device. I think that
> mounting data from other devices is a different matter with specific problems
> (access) that don't exist in YSDL.
> 
> >
> >>
> >> In my view, the definition of a data model schema is really
> >> meta-data. The module "ietf-yang-structural-mount" and its data would
> >> require special treatment anyway - for example, it has to be found in
> >> a well-known location, so it cannot itself be mounted.
> > Yes, I can see how it is meta-data, but I'm not sure that it is significantly
> different from the information provided in yang-library which is represented a s
> regular YANG operational module.
> 
> It doesn't really matter how the schema info is retrieved, as long as it is state
> data available at a well-known location. As I wrote, YSDL could be just an
> augmentation of yang-library.
> 
> Lada
> 
> >
> > For structural-mount: A mounted model should be able to make the mount-
> points structure available at the mount point if required. I.e. the solution is able
> to naturally recurse (as Martin confirmed in reply to Robert Varga's email).
> >
> >>
> >>> 2) A corollary of (1) is that structural-mount also allows different
> >>> schema data models to be published at the mount point (e.g. under a
> >>> list), but ysdl does not.
> >> True, but it can be easily emulated by using either a choice (or a
> >> "dynamic choice" using "when") and defining different sub-schemas as
> >> different cases. I'd argue this is a more robust approach.
> > I don't think that emulating this with a choice is going to be particularly clean.
> In addition, the device that is doing the mounting doesn't necessarily know what
> models the mounted device actual implements.  For ysdl to work for this
> scenario, the mounting device would probably need to query the yang-library
> (and/or ysdl meta-information to allow the solution to recurse) for each
> mounted device to construct the meta-data for it. At this point I would argue
> that it is easier to just provide direct access to the yang-library for the mounted
> device (as structural-mount solution proposes).
> >
> >>
> >>> 3) structural-mount has a mount node embedded directly in the
> >>> schema, where as for ysdl, the equivalent mount points are only
> >>> specified in the ysdl meta-schema.
> >>> 4) ysdl is extensible to cover other non mount related use-cases
> >>> (such as anydata) where being able to dynamically make available the
> >>> schema is useful.
> >>> 5) structural-mount also covers RPCs and Notifications, whereas
> >>> these appear to be outside the scope of ysdl.
> >> This is just an omission on the part of YSDL. The approach proposed
> >> for structural-mount can be used as well.
> > OK.
> >
> >>
> >>> 6) The ysdl meta-data language appears to be more flexible, and
> >>> hence also more complex, than the equivalent "mount-points" schema
> >>> defined in structural-mount.
> >>> 7) For structural-mount the "mount-points" table is returned as a
> >>> normal oper data YANG module in the mounting device, whereas for
> >>> ysdl, protocol extensions would be required to NETCONF/RESTCONF to
> >>> access the schema meta-data.
> >> First, structural-mount uses an extension that has to be considered
> >> mandatory because otherwise no interoperability can take place. So I
> >> don't think that it seamlessly integrates into NETCONF/RESTCONF.
> > I think that only clients and devices that need to mount other models would
> need to support it.  Whether this means it becomes mandatory would
> presumable depend on how widely the mount node used in standard YANG
> models.
> >
> >>
> >> And second, I actually considered to simply extend yang-library with
> >> the YSDL data, but I decided to keep it separate in order to avoid
> >> additional delays for the yang-library spec.
> >>
> >>> Considering these differences:
> >>>
> >>> For points (1) and (2), I can think of scenarios where having a
> >>> mounted device being able to provide its schema via yang-library and
> >>> for that schema to differ for different mounted devices is probably
> >>> a requirement for some plausible mount scenarios.  E.g. one that I
> >>> can think of is the case that you have a YANG controller that is
> >>> exposing an aggregated YANG model for a set of devices, it seems
> >>> that you would need to be accommodate mounted devices that are made
> >>> by different vendors and running different software versions which
> >>> would imply that their schema may also be different.
> >> Right, you would use a (dynamic) choice in this case.
> > As per above, I'm not really convinced that this works as a solution.
> >
> >>
> >>> For point (3), this is a matter of preference, I like that fact that
> >>> the mount point is explicit in the schema in structural-mount.  The
> >>> ysdl
> >> But this means using a YANG extension with all the problems regarding
> >> conformance. And this extension is quite far-reaching.
> > I would think that depends on how many models end up needing to mount
> other models.
> >
> > Thanks,
> > Rob
> >
> >
> >>
> >> Lada
> >>
> >>> meta-schema appears to be more flexible because it can in effect put
> >>> mount points anywhere, but even with structural mount this same
> >>> flexibility could presumably still be achieved by augmenting with a
> >>> mount point.
> >>>
> >>> For point (4), I think that this is useful functionality, and
> >>> perhaps if structural-mount is to be used as the base draft going
> >>> forward it might be worth considering whether the solution could be
> >>> able to cover, or be cleanly extended, to this use case.
> >>>
> >>> For point (5), I definitely think that it is beneficial that
> >>> structural-mount has an intuitive solution for RPCs and Notifications.
> >>>
> >>> For points (6) and (7) my gut instinct is that the structural-mount
> >>> would be easier to standardize and also less work to implement.
> >>>
> >>>
> >>> Some of my points above may be incorrect, and that might swing the
> >>> balance between the two solutions, so please correct me if I have
> >>> got anything wrong.  Otherwise, just considering the written drafts
> >>> as they stand now, my personal preference is that I would favour
> >>> using structural-mount as a starting point for a solution.
> >>>
> >>> Martin, I also have some comments/questions on the structural-mount
> >>> draft, I'll put these into a separate email.
> >>>
> >>> Thanks,
> >>> Rob
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod