Re: [netmod] schema mount and YANG library

[Ladislav Lhotka <[e-mail]>]

On Thu, 2018-01-18 at 13:25 -0800, joel jaeggli 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?

As I wrote, the LNE and NI documents will have to update the examples in their
(non-normative) appendices. Drafts that just define specific YANG modules
shouldn't be affected even if they use schema mount.

It is IMO not a big deal.

Lada

> 
> If yes then we're doing ourselves a clear dis-service by essentially
> clearing the boards of the existing draft.  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.
> 
> 
> > /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
> > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67