Re: [netmod] schema mount and YANG library

[Ladislav Lhotka <[e-mail]>]

On Tue, 2018-01-16 at 16:13 +0100, Martin Bjorklund wrote:
> Lou Berger <[e-mail]> wrote:
> > 
> > 
> > On 1/16/2018 8:50 AM, Martin Bjorklund wrote:
> > > Lou Berger <[e-mail]> wrote:
> > >>
> > >> On January 16, 2018 8:24:42 AM Martin Bjorklund <[e-mail]>
> > >> wrote:
> > >>
> > >>> Lou Berger <[e-mail]> wrote:
> > >>>> Lada,
> > >>>>
> > >>>>
> > >>>> On January 16, 2018 7:07:15 AM Ladislav Lhotka <[e-mail]> wrote:
> > >>>>
> > >>>>> On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
> > >>>>>> Lada,
> > >>>>>>
> > >>>>>> It sounds like you are proposing in (1) a fairly significant change
> in
> > >>>>>> the
> > >>>>>> direction of the draft and in (2) a basic approach that has been
> > >>>>> It is no change in direction, just a simplification of the
> > >>>>> schema-describing
> > >>>>> state data. Given the recent developments in 7895bis it makes no sense
> > >>>>> to me to
> > >>>>> have two "schema" lists if we can have just one.
> > >>>>>
> > >>>> Managing transition is hard. It's also highlights why Yang Library
> > >>>> this needs to be at least equally discussed in this group.
> > >>>>
> > >>>> I will talk with my co-chairs and perhaps the ADs to get their opinion
> > >>>> on making such a change this point in the process.
> > >>>>
> > >>>>
> > >>>>>> 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.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.
> > 
> > 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.

Yes, I think they are.

> 
> > 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.
> 
> Do you think that there is any use case that the proposed solution
> cannot handle, but the previous solution did?
> 
> > 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.

We can try to update the draft and the examples, it should then be much more
clear. It is really very little extra work.

Lada

> 
> 
> /martin
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67