> -----Original Message----- > From: Martin Bjorklund <[email protected]> > Sent: 24 March 2019 16:22 > To: Rob Wilton (rwilton) <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [netmod] import-by-semver issue > > "Rob Wilton (rwilton)" <[email protected]> wrote: > > Hi Juergen, > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder <[email protected]> > > > Sent: 24 March 2019 15:31 > > > To: Rob Wilton (rwilton) <[email protected]> > > > Cc: Andy Bierman <[email protected]>; NetMod WG > <[email protected]> > > > Subject: Re: [netmod] import-by-semver issue > > > > > > On Sun, Mar 24, 2019 at 02:07:15PM +0000, Rob Wilton (rwilton) wrote: > > > > Hi Andy, > > > > > > > > There are many ways to write and design compilers. > > > > > > > > Compilers that don’t understand import-by-semver just ignore the > > > > extension, > > > no deviation is required. They just import whichever arbitrary > > > revision that they would have imported anyway, as specified by YANG > > > 1.1. The import-by-semver statement just reduces the set of valid > > > modules revisions that can be used for import. > > > > > > > > > > If two compilers (one supporting semver, the other not) resolve > > > imports differently, then the design is in my view somewhat broken, > > > in particular if you allow NBC changes. > > > > But that is true of YANG compilers today. If there are multiple > > revisions of a module that could be chosen, then each compiler is at > > liberty to decide which revision to choose (last paragraph of section > > 5.1.1 in RFC 7950). > > This is by design, of course. With an "open" import (not import by > revision), the > server implementor is free to implement any set of modules that work together. > > > So, I would argue that "import-by-version" doesn't make YANG compilers > > any less consistent that they are already today, since that > > inconsistency already exists. > > I don't think I understand Andy's objection. I also think that this > is just another implementation detail. > > > I presume that the real solution here is to explicitly define the full > > set of implemented, import-only-modules to the compiler so that it > > always compiles a consistent schema. Perhaps other compilers have > > different ways to solve this problem. > > > > Note, I also think that YANG library has a similar inconsistency. > > I.e. there is no guarantee that two different compilers will construct > > exactly the same datastore schema from the YANG library output. > > Can you elaborate? Given an instance of YANG library, it should be clear > which > set of modules are used.
For modules that are "import-only" rather than "implemented" then some modules might use import-by-revision to import a specific revision, and other modules might just use import (without revision). In this case, the compiler can choose which revision it uses to satisfy that import (e.g. getting different grouping definitions). In draft-verdt-netmod-yang-semver-00, we aim to resolve this ambiguity with the following text that incorporates semver, a similar solution or just using the latest revision dates could also be devised: 5.2. Resolving ambiguous module imports A YANG datastore schema, defined in [RFC8525], can specify multiple revisions of a YANG module in the schema using the 'import-only' list, with the requirement from [RFC7950] that only a single revision of a YANG module may be implemented. If a YANG module import statement does not specify a specific version or revision within the datastore schema then it could be ambiguous as to which module revision the import statement should resolve to. Hence, a datastore schema constructed by a client using the information contained in YANG library may not exactly match the datastore schema actually used by the server. The following rules remove the ambiguity: If a module import statement could resolve to more than one module revision defined in the datastore schema, and one of those revisions is implemented (i.e., not an 'import-only' module), then the import statement MUST resolve to the revision of the module that is defined as being implemented by the datastore schema. If a module import statement could resolve to more than one module revision defined in the datastore schema, and none of those revisions are implemented, but one of more modules revisions specify a YANG semantic version, then the import MUST resolve to the module with the greatest version number, according to the version comparison rules in Section 3. If a module import statement could resolve to more than one module revision defined in the datastore schema, none of those revisions are implemented, and none of the modules revisions have a YANG semantic version number, then the import MUST resolve to the module that has the most recent revision date. Thanks, Rob > > > > > I > > think that this is a design bug, but also one that we attempt to > > address in draft-verdt-netmod-yang-semver-00. > > > > Thanks, > > Rob > > > > > > > > /js > > > > > > -- > > > 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
