Re: [netmod] schema mount and YANG library

[Ladislav Lhotka <[e-mail]>]

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