On Tue, Jul 23, 2019 at 11:00 AM Ladislav Lhotka <[email protected]> wrote:
> On Tue, 2019-07-23 at 09:22 -0700, Andy Bierman wrote: > > > > > > 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. > > I think so, minutes were taken. > > > > > > 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. > > I don't see much difference provided that the extensions will be properly > signalled. But we have to take into account that some tools that people > use may > not be updated for quite some time, and if they cannot properly work with > modules written for the new version (or extensions), then things will > break. > > So you want to work on YANG 1.2, but just the parts you want to change? ;-) There is no such thing as a critical extension in YANG 1.1. IMO it would be a bad idea to develop standard modules that relied on tool support of any extension. A tool is allowed to skip any extension when parsing a module. This cannot be changed in YANG 1.1. > This problem is actually not limited to YANG itself - people are reporting > problems with the transition to NMDA. > > > > > 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). > > Yes, hence critical extensions. However, the problem is still the same - > these > changes require updated tools, and not all tools will be updated > immediately. I > think that we should make sure that (at least in the IETF) all modules > will be > compatible with tools supporting YANG 1.1, say for the next 5 years. > > I am OK with the current WG priorities such as versioning. Those YANG extensions simply clarify YANG 1.1 so no rules are broken and no YANG 1.1 functionality is removed if a tool ignores the extensions. Also OK with not working on YANG 1.2 or critical extensions. There are no must-have features at this time. Lada > > Andy > > > > 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
