Re: [netmod] schema mount and YANG library

[Martin Bjorklund <[e-mail]>]

Hi,

joel jaeggli <[e-mail]> wrote:
> 
> 
> On 1/18/18 11:15 AM, Martin Bjorklund wrote:
> > 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!
> Do we believe that documents using normative referencing to this draft
> e.g. in routing would require changes in order to accommodate an updated
> draft?
> 
> If yes then we're doing ourselves a clear dis-service by essentially
> clearing the boards of the existing draft.

As Lada wrote earlier, two of the three drafts need updated *examples*
in their appendicies.  They do not need any changes to their normative
sections.

> If that is the case we
> should consider publishing this one possibly with an appropriate
> applicability statement; the work on the new one can proceed so that at
> least they have a stable reference. This assumes not fundamental flaws
> that make the current one unusable.

Since some time back, we require all drafts to be NMDA compliant.  Why
should SM be different?  Note that this solution does not *require*
NMDA.

One reason for SM being late is that it has been difficult to find a
technical solution for which even the authors could agree.  The
current draft is a compromise.  By using YLbis we can solve some of
these issues, and since this is a central building block I think it
would be very unwise to publish it just to avoid updating two
examples.


/martin



> 
> 
> > /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
> >>
> >>
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
>