On Tue, Oct 4, 2022 at 12:15 PM Jürgen Schönwälder < [email protected]> wrote:
> Rob, > > I understand your attempt to find a compromise but from a technical > perspective I consider the design of computer languages where the > resolution of imports is vaguely defined and to a large extend > implementation specific more than questionable. > > The simple facts are: > > - Import by exact revision is limited and generally not very > useful. This is where we agree. > > - YANG 1.1 allows to add definitions but not to remove revisions. > Hence, import-by-minimum-revision makes sense for the YANG 1.1 > update model. The versioning work aims at allowing module authors to > arbitrarily add, remove, or modify definitions. Hence, for the new > update model, you need more complex import constraints than just > import by a minimum revision. > This is the requirement for most YANG modules. It is needed when the imported schema item was added is a specific version, which is not the first revision. It would be a big improvement if import-stmt had "revision-date-or-later" in addition to "revision-date" as sub-statements. This missing feature does not require SemVer. The main reason YANG 1.1 has import-exact-revision is that we were concerned about "grouping drift". We did not want the module conformance to change over time because the "uses" expansion from imported modules changes. This problem comes back with "revision-or-later" import semantics. > - Maintaining revision constraints in statement inside YANG modules > implies that changes of imported modules may cause updates of > importing modules. I think we have sufficient experience with this > not working well in practice, in particular with a relatively static > publication process. > > - A proper computer language should have well defined import semantics > such that independent implementations behave in a predictable ways. > > I do not know why it is a holy grail to touch the YANG version number. > Perhaps people are afraid of not being able to control the process > once a version number bump is on the table. Whatever the reason is, it > has a bit of Monty Python humor if the same people try to convince me > that an IETF flavor of semantic version numbers are the solution to > all versioning problems. > > I am hoping for a technically sound solution that provides predictable > behaviour of independently developed tools. Some "hints" that may be > used or ignored at the discretion of an implementation do not really > meet that bar. > > Agree with these points > /js > Andy > > On Tue, Oct 04, 2022 at 02:02:00PM +0000, Rob Wilton (rwilton) wrote: > > Hi Juergen, WG, > > > > draft-ietf-netmod-yang-module-versioning defines section "4. Import by > derived revision" that allows an author to specify a minimum revision of a > module that is allowed to satisfy a YANG import. > > > > IIRC, and hopefully you will correct me if I am wrong, you had two > concerns about this approach: > > (1) It potentially changes the behaviour of a YANG compiler without a > corresponding version change in the YANG language. > > (2) It is embedding version constraint information directly into the > YANG module. > > > > The main reason for wanting this import was to help specify a minimum > import dependency, e.g., perhaps a module depends on a new type that is > only defined in version 1.1 and not available in any of the previous > versions. Here, having some level of minimum dependency in the importing > YANG module seems broadly helpful (like a more helpful version of the > existing import by exact revision-date), given that in many cases modules > may be independently versioned. > > > > Anyway, I would like to propose a change (a softening) of the definition > of the "revision-or-derived" extension statement in the Module Versioning > Draft so rather than referring to a hard "minimum required revision" for > the import to be valid, instead it is changed to refer to a softer > "suggested minimum revision". I.e., the intention is that the > "revision-or-derived" statement is no longer a hard constraint on the > import statement at all, it is just a suggestion for use by tooling and > module readers, and which they are at liberty to entirely ignore. > > > > Tools that support the "revision-or-derived" would generally be expected > to pick a revision that is derived from the revision/version specified in > the "revision-or-derived" statement but are not required to do so. E.g., > if they don't have a suitable version available, then they can import > another module version. Further, if such a tool does choose a version that > isn't derived from the "revision-or-derived" statement then generating a > YANG compiler warning message would be reasonable, but not required. > > > > The potential benefits of the new approach are: > > - arguably, this approach is more compatible with existing YANG 1.1 > import rules. > > - sets of YANG modules that were compiled by tools that don't understand > the "revision-or-derived" statement would still compile with tools that do > understand it, possibly with the addition of some warning messages.. > > - with a branched revision history, there are cases where the tighter > import constraint isn't so helpful. > > > > If/when YANG 2.0 comes along, we could either keep with the relaxed > definition proposed above, or possibly tighten the definition to what we > have today. > > > > I would be interested in Juergen's and the WG's opinion on this proposed > change in behaviour. > > > > Regards, > > Rob > > > > // As a contributor to the versioning work. > > -- > Jürgen Schönwälder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
