> On 22 Jan 2016, at 14:28, Robert Wilton <rwil...@cisco.com> wrote: > > 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.
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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
