On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka <[email protected]> wrote:
> 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. > > I hope a summary of the meeting is posted to the WG mailing list. > 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. > > IMO a new version of YANG would not be disruptive (if done right). The issue is whether it is cleaner in the long-run to introduce NBC changes properly with a new version number, or not so properly, through YANG extensions. E.g -- adding a leaf to the datastore that says "I don't follow the rules in 7950" is still breaking the YANG 1.1 contract. Using extensions instead of real statements is problematic because they are optional to implement (as you point out all the time). Seems like the WG is going the YANG extension route, which has its own set of problems compared to a new YANG language version. Lada > Andy > > -- > 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
