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?
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.
/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 <m...@tail-f.com> wrote:
>
> > Lou Berger <lber...@labn.net> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
