On Tue, Oct 4, 2022 at 7:02 AM Rob Wilton (rwilton) <rwilton=
40cisco....@dmarc.ietf.org> 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.
>
>
I do not think these extensions need to change.
In general, I would prefer a new YANG version but this specific extension
works with the most common usage mode.
OK to use extension:
import foo {
prefix f;
}
Not OK to use extension:
import foo {
prefix f;
revision-date 2000-01-01;
}
If no revision-date is present, then a YANG 1.1 tool should expect any
revision.
The 'revision-or-derived' extension cannot be used together with
'revision-date' because a YANG 1.1
tool is expecting an exact revision in this case.
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.
>
>
The trade-off for using an extension is that is conditional and optional to
implement.
A general YANG tool can ignore the 'nacm:default-deny-all' extension, but
it is mandatory
for a NACM implementation to support it.
I would be interested in Juergen's and the WG's opinion on this proposed
> change in behaviour.
>
> Regards,
> Rob
>
>
Andy
> // As a contributor to the versioning work.
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
