Ladislav Lhotka <[email protected]> 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 <[email protected]> wrote: > > > > > > > Lou Berger <[email protected]> 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
