On Tue, 2018-01-16 at 10:34 -0500, Lou Berger wrote: > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote: > ... (trimming to topic) > > > > > > > > > rejectected by the WG multiple times. FWIW there are drafts > > > > > > > > > already > > > > > > > > > with > > > > > > > > > > > > > > > > No at all. The first and last time I proposed this was on 15 > > > > > > > > December > > > > > > > > 2017: > > > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg19753.ht > > > > > > > > ml > > > > > > > > > > > > > > > > > > > > > > Oh, I certainly would call you proposing that the schema for > > > > > > > inline be > > > > > > > part of the rest of the schema Mount module well before that. I'm > > > > > > > sure > > > > > > > I can dig up mail / slides it really necessary... > > > > > > > > > > > > I don't think this has been proposed before. All previous proposals > > > > > > were basically variants on what is now "use-schema", which works > > > > > > fine > > > > > > when all instances have the same schema. This new proposal solves > > > > > > the > > > > > > issue with different schemas in different instances. > > > > > > > > > > > > > > > > I thought the previous proposals that as well, so don't see material > > > > > difference - at least from the usage standpoint. I also don't see why > > > > > the previous arguments that resulted in consensus for using Yang > > > > > Library underneath the an in line Mount Point don't apply. > > > > > > > > B/c it doesn't work well with the NMDA. You can't mount yang library > > > > in the configuration datastores; it has to be mounted in operational. > > > > With meta-data, you can actually report the correct schema even in > > > > running. (This is actually true also for pre-NMDA systems). > > > > > > > > > > Understood and agree there is nothing new here and the current version > > > of SM (including inline) has the same limitation as rfc7895, and I'd > > > expect it to behave the same once we have rfc7985bis -- in fact the > > > inline case "just works" with YL-bis as defined today. > > Martin, > > you didn't respond to this point. > > > > The argument I recall being the key point on inline was handling the > > > large variety of possible different implementation approaches for > > > modules using inline. > > > > I think these still are covered. > > > > > For example an LNE that is implemented using > > > VMs which can be managed by the host at different times of the VMs > > > operational life cycle based on customer/provider requirements. I > > > really don't see how YL-bis has any bearing on this point and > > > > Using the new proposed meta data annotation together with the new YL > > means that SM can support the use case above also in an NMDA server. > > I think the new proposed solution covers more use cases than the > > previous solution. > > how so? The inline mount point would contain YL-bis and have the same > information there, just scoped for the mount point. It's true a client
As Martin already wrote, this cannot be done for in config datastores. > > would need to understand the mount point's schema only upon parsing the > YL under the mount point and this schema could not be shared across > inline mount points. But this is as was discussed in the past and > unchanged from YL. > > > Do you think that there is any use case that the proposed solution > > cannot handle, but the previous solution did? > > yes. with VM/container technologies the YL / schema can change under > the mount point from time to time during normal operation (i.e., during > runtime, no reboot) and, in some implementations, may require some level > of rpc operation to access even the schema. The new (and previously > proposed approach) of having inline schema available from the top level > greatly complicates these cases. Also keep in mind that there will be Why? I assume that new schemas can be added as entries of the parent YL "schema" list even at runtime. So you just do it, and change the @schema-ref leafref with which the mount point instance undergoing the change is annotated. > cases where the ability to access information under an inline mount > point will dynamically change in operation (and top level YL would need > to remove schema information for the inline mount point.) As before, > from the usage standpoint, these changes don't provide a whole lot of > value and seem to optimizing for something not needed in the inline case. > > > > I think > > > it is incumbent upon those revisiting past/closed WG decisions (in > > > this case, inline schema being represented by YL) to argue why the > > > decision needs to be revisited. > > > > I'm repeating my self: b/c the current solution doesn't work well with > > the NMDA. > > I simply don't understand how YL-bis works at the root node but doesn't > work equally at an inline mount point. Can you elaborate? I propose that we update the schema mount draft in a separate branch on GitHub, and then continue the discussion. Lada > > Lou > > > > > > > /martin > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
