On Tue, 2019-07-23 at 16:22 +0000, Balázs Lengyel wrote: > Hello, > I share your concerns. However I see some ways of mitigating the problem: > 1) Maybe the extension based solution is better than many people would > believe. If we put new features (like status-information, > import-revision-or-derived, preliminary-status etc.) into extensions e.g. > Yang1-2:status-information older systems can just ignore them while never > systems would still be able to use them. This might not work for all new > functionality, but would definitely work for some.
This could work only for extensions that do not affect YANG semantics. For example, if a server actively uses schema mount, then a client that ignores it is next to useless. For critical extensions that affect YANG semantics, it would IMO be necessary to develop modules supporting them in separate branches, along with their 1.1-only versions. > 2) Some yang-next ideas are really clarifications of yang 1.1 (e.g. Clarify > YANG "status" keyword usage (e.g., hierarchical)) so they will not disturb > current users. Of course, clarifications and bug fixes are OK. Lada > Regards Balazs > > -----Original Message----- > From: netmod <[email protected]> On Behalf Of Ladislav Lhotka > Sent: 2019. július 23., kedd 12:03 > To: NETMOD WG <[email protected]> > Subject: [netmod] YANG next > > Hi, > > this morning I attended the side meeting "Next Step of IETF YANG". I was > somewhat misled into thinking that it would be about future evolution of > YANG the language, which was not the case at all. However, my personal > conclusion from the meeting is that it would be a total disaster to throw in > a new version of YANG within the next few years or so. > > The operators and equipment vendors are busy putting together YANG modules > and tools, filling the gaps, coping with NMDA, schema mount, IETF versus > OpenConfig etc. A new YANG version (and modules written in it) would IMO be > extremely counter-productive at this rather turbulent stage. > > So, if we want to continue the yang-next discussion, I think we first have > to figure out how to evolve YANG without making waves in the current YANG > pond and let the operators and vendors do their work, without which YANG can > never succeed. > > Lada > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > 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
