On Mon, Jun 14, 2021 at 10:40 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.ste...@nokia.com> wrote:
> 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. > > The all-or-none approach to the versioning work is producing more "none" than "all". ;-) YANG was designed to be used in a linear and singular release train. This is clearly not the way the real world can use YANG. Ignoring this pain point is making the problem worse over time. There are many corner-cases that the DT is spending a lot of time on that do not cause the deployment problems that a revision label could solve. My original point: Fix this problem with the best engineering solution possible even if that means a new YANG language version. Import-by-semver should not be super-complicated and it should not be optional for a compiler to use. Import-by-exact-revision is flawed and not worth preserving. Jason > Andy > > > -----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
