On Thu, 2018-01-18 at 13:25 -0800, joel jaeggli wrote: > > On 1/18/18 11:15 AM, Martin Bjorklund wrote: > > 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! > > 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 <[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 > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
