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. - 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. /js 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
