On Wed, Jul 24, 2019 at 07:10:23AM -0700, Andy Bierman wrote: > On Wed, Jul 24, 2019 at 6:52 AM Ladislav Lhotka <lho...@nic.cz> wrote: > > > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > > > > > On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote: > > >> > > >> This problem is actually not limited to YANG itself - people are > > reporting > > >> problems with the transition to NMDA. > > >> > > > > > > The YANG update from 1 to 1.1 mostly affected compiler writers - and > > > to a much lesser extend module authors and module implementors. NMDA, > > > affects client and server implementors much more directly, additional > > > instrumentation on the server side needs to be written, application > > > logic on the client side needs to be adjusted. NMDA is an evolution of > > > architectural principles and this already indicates that there is a > > > certain investment to make. > > > > But both updates induced some changes in YANG modules that affect users > > and integrators. Take ietf-ospf module as an example: it is of course a > > great addition to the YANG module collection, but in order to use it, all > > tools have to support > > > > - YANG 1.1, e.g. because of the special XPath functions, and > > > > - NMDA, because otherwise state data are missing. > >
I believe the majority of parsers (there were not that many) started to support YANG 1.1 quite quickly after RFC publication. NMDA support will take longer and this is not a surprise. To me, it makes sense to distinguish these two updates. And neithers says what the update of YANG next will be. Implementation complexity and transition complexity was one of the things we considered for each YANG 1.1 improvement. /js -- 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
