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. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
