Re: [netmod] schema mount and YANG library

[Martin Bjorklund <[e-mail]>]

Ladislav Lhotka <[e-mail]> wrote:
> On Thu, 2018-01-18 at 14:39 +0100, Juergen Schoenwaelder wrote:
> > Ignoring process issues (not sure there are any), does it make sense
> > to publish a YANG module on the standards-track that is replaced by
> > something different 3-6 months later?
> 
> IMO such a document churn would be a serious mistake. In the documents that are
> currently on the table (at least NMDA, YLbis, SM) we are dealing with quite a
> few tricky and interrelated things, so it's important to come up with a coherent
> view into which all the components nicely fit. And I believe we are now quite
> close.
> 
> Publishing an interim solution that is a priori known to be technically inferior
> would just confuse people. The fact that it can be hacked to support two or
> three particular data models (albeit important) doesn't warrant to do so.

I strongly agree with this!


/martin

> > 
> > Note that the NMDA contributors, after getting the overall design
> > done, move sequentially through the details of the documents; we first
> > focused on the NMDA document, which is in the RFC editor queue now. We
> > then focussed on the protocol extensions, which are now in WG last
> > call. Currently we are focusing on getting the new yang library
> > finalized. If no major isses pop up, the NMDA work may be complete by
> > the London IETF. Hence the 3 months lower bound mentioned above.
> 
> I agree, and will try to help.
> 
> Thanks, Lada
> 
> > 
> > /js
> > 
> > On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
> > > Martin,
> > > 
> > > I do agree with that at some point we will need to revisit scheme mount in
> > > the context of YL-bis, as there are different possible solutions for
> > > handling different datastores mounting  different schema. I think Rob laid
> > > out the options pretty well here, ie doing it now or publishing as is and
> > > immediately working on the document that covers both.
> > > 
> > > As I mentioned before I think this is as much a process issue as anything
> > > else - and have a planned call to discuss possible directions with chairs. I
> > > hope we can have some propose next steps on this to the working group in
> > > short order.
> > > 
> > > Lou
> > > 
> > > 
> > > On January 18, 2018 2:57:23 AM Martin Bjorklund <[e-mail]> wrote:
> > > 
> > > > Lou Berger <[e-mail]> wrote:
> > > > > 
> > > > > 
> > > > > On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
> > > > > ...
> > > > > > > > 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.
> > > > > > 
> > > > > > No this is not correct.  SM uses a grouping from the old YANG
> > > > > > library (for the "use-schema" case),
> > > > > 
> > > > > I thought YLbis was an updat e to UL (i.e., no name change) as such SM
> > > > > can include either.
> > > > 
> > > > The old "modules-state" structure is deprecated, and a new structure
> > > > that allows multiple datastores is defined.  Note that YLbis can be
> > > > used by both NMDA-capabale and non-NMDA-capabale servers.
> > > > 
> > > > > >   and talks about mounting
> > > > > > "modules-state" ("inline" case).
> > > > > 
> > > > > In informative descriptions only.  Certainly these can be changed to
> > > > > allow for YL-bis if need be.
> > > > > 
> > > > > > > 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.
> > > > > > 
> > > > > > Ok.  I'm ok with keeping the inline case as it is.  However, I think
> > > > > > we need to use the new YL-bis, so that we can support the NMDA.
> > > > > 
> > > > > Given that NMDA support is not yet fully defined, we're still in the
> > > > > transition period where support for both NMDA and non-NMDA
> > > > > implementations need to be considered.  Rob presented some options
> > > > > earlier in the thread that I think captures this.
> > > > 
> > > > Again, note that YLbis supports both NMDA and non-NMDA servers.
> > > > 
> > > > Also note that YLbis is just a different read-only monitoring
> > > > structure.  Given an implementation that supports the old YL, it is
> > > > trivial to add support for YLbis (especially compared to the more than
> > > > non-trivial amount of work required to support schema mount...).
> > > > 
> > > > 
> > > > /martin
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> 
>