Re: [netmod] Import by revision-date or label vs semantic version

[Andy Bierman <[e-mail]>]

On Wed, Sep 2, 2020 at 3:55 AM Juergen Schoenwaelder <
[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>