On Wed, 2018-01-17 at 10:43 -0500, Lou Berger wrote: > > On January 17, 2018 9:42:43 AM Martin Bjorklund <[email protected]> wrote: > > > Lou Berger <[email protected]> wrote: > > > > > > > > > On 1/17/2018 3:20 AM, Martin Bjorklund wrote: > > > > Lou Berger <[email protected]> wrote: > > > > > > > > > > On 1/16/2018 11:15 AM, Robert Wilton wrote: > > > > > > On 16/01/2018 15:50, Martin Bjorklund wrote: > > > > > > > Lou Berger <[email protected]> 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/curre > > > > > > > > > > > > > > > nt/msg19753.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > I agree, it works for non-NMDA servers. But see below. > > > > > > > > > > > > > > > > > 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 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 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 this is an implementation issue, rather than a problem > > > > > > > with > > > > > > > the proposed mechanism, and it is present in the current solution > > > > > > > as > > > > > > > well. An implementation that can handle dynamically changing > > > > > > > mounted > > > > > > > YLs in the current solution can do that in the new solution as > > > > > > > well. > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > With NMDA, a server may have one schema for the config datastore > > > > > > > and > > > > > > > another one for operational (one is a superset of the other). A > > > > > > > mounted YL can only be present in operational. Thus, there's no > > > > > > > way a > > > > > > > client can learn the schema for config. > > > > > > > > > > > > If the LNE mounted the full YL-bis at the mount point then you would > > > > > > have the list of datastores, and the schema associated with each > > > > > > datastore. Of course, this would only be available in operational, > > > > > > but > > > > > > that is the same as a regular server support YL-bis. > > > > > > > > > > exactly my point. > > > > > > > > Yes, you're right. But it requires the usage of YL-bis. > > > > > > > > > > I thought that the problem with the current solution and NMDA, was > > > > > > that > > > > > > there is no way to find out what the LNE schema is if the LNE isn't > > > > > > booted, and hence isn't providing <operational>. > > > > > > > > > > I've never heard anyone mention this issue/limitation. > > > > > > > > This has been dicussed, but this does not change with the introduction > > > > of the meta annotation; if the server has off-line knowledge of the > > > > instance's schema then it can populate an inline YL as well as the > > > > meta annotation and corresponding SM data. > > > > > > > > > My > > > > > understanding of the previously raised objections were (a) that the > > > > > full schema can't be obtained by just reading the top level YL and (b) > > > > > that when multiple inline mount points have the same schema the > > > > > information can't be combined using a shared schema approach as is > > > > > taken in base SM. > > > > > > > > Right. Both these issues are addressed by using a meta annotation. > > > > > > But when we discussed this the last time having inline schema > > > available at the top level (in the SM module), the general consensus > > > was that having YL under inline was the preferred approach. > > > > What is new now is that we have an indirection; each instance has its > > own pointer to the schema at the top level. In the previous > > discussion, having the schema at the top level implied that all > > instances shared the same schema, and *that* was rejected. > > > > Indirection was possible at the previous time and is part of the current > scheme Mount definition. Yes, you need to use different mount points to > reference different schema, but take a look at the ni document that's > exactly what we are doing there. So I don't believe this is the point that
What Martin and I are talking about is a mount point that is a list node of the "use-schema" type. There is no way how different entries of this list could have different schemas. The same applies to a container mount point that is inside a list. Then you can also have multiple *instances* of the mount point, and with "use-schema" there is no way how these instances could have different schemas. Lada > > caused the previous proposal to be rejected. > > > > Lada > > > stated that he didn't like the approach, but would go with the WG > > > decision. Why are we reopening this closed discussion -- many months > > > after we closed the issue? Most who contributed, notably users, have > > > moved from SM assuming it's a solved problem. > > > > > > At this point, I think the case needs to be made why the existing > > > mechanisms in the draft are broken vs how they might be improved. My > > > understanding is that there was one issue that could be clarified by > > > the proposed text I included when restarting this discussion. > > > > > > What else is *broken* in the current draft? > > > > My main concern is actually the YL version. I strongly think SM need > > to use YL-bis rather that the old YL, so that it can support NMDA. > > > > Right now to SM is independent of Yang Library version and can run with > either. I certainly would expect use of Yang Library bis and nmda to have > advantages. > > > The implementation effort for supporting the new YL in clients and > > servers is minimal, esp. when compared to the efforts involved in > > supporting SM. > > > > Adding an indirection is (for me) less important, but it has the > > benefit of solving the two issues (a) and (b) above, and I haven't > > seen any technical problem with it. > > > > (A) has implementation implications and those participating in the > discussion at the time expressed as not being worth the cost. > I don't believe b was seen as a significant issue either. > > > Do you have any technical concerns with using an annotation as an > > indirection? > > > > The technicsl issue I have with the approaches the same one that was raised > when debated previously, ie the implementation overhead of requiring inline > schemas to be available at the top level. > > > From a process perspective, I don't think it's fair to those who provided > > input or contributed in the past in order to get scheme mount to satisfy > their requirements to reopen something that is not broken. Particularly > because a number of those contributors are implementers and users who are > now focused on other topics. > > Lou > > > > > /martin > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
