On Wed, Sep 2, 2020 at 3:55 AM Juergen Schoenwaelder < [email protected]> wrote:
> I continue to have a problem with changing YANG import semantics using > extension statements. Versioning people should understand that this is > an NBC change and hence they should request that the YANG version > number is changed. > > +1 IMO it is a huge mistake to think YANG will be easier to use in the long run by adding optional extensions to YANG 1.1 instead of introducing a new language version. YANG 1.1 will splinter into several dialects, all relying on different subsets of an ad-hoc set of language extensions. /js > Andy > > On Wed, Sep 02, 2020 at 10:51:38AM +0000, Rob Wilton (rwilton) wrote: > > Hi, > > > > During the NETMOD 108 meeting I had made a comment that imports using > revision-or-derived are not done using a semantic version number, but > instead are done by revision label, which limits how they behave and what > they are allowed to do. Some participants were concerned that this might > be confusing or even broken, and the outcome of that short discussion was > that I should send an email to NETMOD with an example to help explain how > they are proposed to work. > > > > The main principle here is that the versioning drafts have a clear > distinction between supporting an abstract version label vs a specific > version label scheme (such as YANG Semver). > > > > The new "revision-or-derived" extension is defined as part of base > draft-ietf-netmod-yang-module-versioning. The "revision-or-derived" > extension takes a single argument that can either be a "revision date" or a > "revision label". It can be used regardless of the versioning scheme that > is being used as a revision label, but therefore is also restricted to > treating the revision label as an opaque textual label for a revision date. > > > > So, making use of the examples in section 4.1 of > https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-01 > > > > When a module has an import statement like this: > > > > import example-module { > > rev:revision-or-derived 2.0.0; > > } > > > > Then the processing to find a suitable revision to import would be > something like this (ignoring the issue of which revision is chosen from > the set of suitable candidate revisions): > > > > 1) Iterate suitable candidate "example-module" YANG files. > > 2) For each candidate file, parse the revision history, and check back > through the revision history to see if a revision with label "2.0.0" > exists. If it does, then that module revision is a suitable candidate for > import. If no revision with label "2.0.0" exists then that module revision > does not satisfy the import. Note the tooling does not need to understand > the format of the revision label at all, a textual comparison between > labels is sufficient. > > > > The algorithm works equivalently if the import was done using a revision > date instead of a label (e.g., rev:revision-or-derived 2019-02-01), except > that obviously the comparison in the revision history is done on the > revision date rather than the revision labels. > > > > > > ------- > > > > So, how does this interact with YANG Semver (or vanilla Semver 2.0.0)? > > > > Well, this still works because each version of a YANG module contains > the revision history back to the root of the version tree. > > > > E.g., the YANG file defining version 2.2.0 would contain revisions for > versions 2.2.0, 2.1.0, 2.0.0, 1.0.0 in its revision history, and hence > would satisfy an import using label "2.0.0" or derived" solely because a > revision with that label exists in its revision history. > > > > However, if the revision history had entries pruned (i.e., perhaps 2.1.0 > hadn't been included in the revision history so that it was just 2.2.0, > 2.0.0, 1.0.0) then this particular YANG file for version 2.2.0 WOULD NOT > satisfy an import for "revision-or-derived 2.1.0;" because the module's > revision history does not contain revision 2.1.0. > > > > So, the import revision-or-derived works fine for Semver version labels > as long as the revision history is consistent and complete. > > > > ------- > > > > Finally, there has been some discussion about whether it would be useful > to have an import statement that restricts imports to only backwards > compatible versions - I'll post a separate email on this. > > > > If the WG decided that this is useful, then this could still be > supported, and without needing to understand the revision label. Instead, > it can be done by checking the revision history for the "rev:nbc-changes" > substatement that indicates where NBC changes have occurred in the revision > history. As long as the allocated YANG Semver revision labels are > consistent with the use of the rev:nbc-changes" substatement in the > revision history then it would still behave in the intuitive way. > > > > > > Regards, > > Rob > > > > [As an individual contributor] > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder 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
