Hi, joel jaeggli <[email protected]> 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? > > 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 <[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 > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
