Hi guys, I can understand that concern; and in particular for something like the new import by "revision-or-derived". Ignoring that extension can mean tools may not build the right schema (although is that any worse than today without using import by revision ?).
Despite that issue, I'd still advocate for revision-or-derived to be taken to standard now. It is part of a few things that cause problems today that really need to be addressed in the short term. But for things like the rev:non-backwards-compatible tag, and using YANG semver, do those actually cause any new problems (vs what they help solve) ? It doesn't cause tools to build the wrong thing, or servers to implement the wrong thing. It only helps supply information about what is already happening today (particularly in vendor modules, but also in standard modules) that isn't being described at all (NBC changes that really do impact the client, but the module name is kept the same). The WG had a fair bit of discussion 2-3 years ago that this versioning work was needed and should be adopted and progressed. That is still the case IMO. Jason > -----Original Message----- > From: Kent Watsen <kent+i...@watsen.net> > Sent: Monday, June 14, 2021 1:17 PM > To: Andy Bierman <a...@yumaworks.com> > Cc: Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@nokia.com>; > netmod@ietf.org > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 > > > > I meant the current work is using extensions instead of new language > statements. > > Not that the yang-version will never be changed in the future. > > Ah, okay. > > > > It is not a matter of "when" if new functionality is added via extensions. > > In theory the WG could add new functionality to YANG 1.1 this way for > years. > > In practice it might be difficult to achieve widespread interoperability if > nobody > > agrees what "YANG next" actually contains. Also, YANG 1.1 clearly says a > tool MAY > > skip over and ignore ANY external statement, so it is problematic to use > extension-stmt > > as if it was defining real statements. It is better to have a tool clearly > > fail > > with an "unsupported YANG version" error than it is to silently ignore > external statements. > > Agreed. > > > K. > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
