Hi Lada,
Please see inline ...
On 22/01/2016 12:41, Ladislav Lhotka wrote:
Robert Wilton <rwil...@cisco.com> 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.
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.
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
