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. 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. > 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. > 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. > 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. 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. > > 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. 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
