Juergen Schoenwaelder <[email protected]> wrote: > On Mon, Sep 14, 2015 at 03:19:14PM +0200, Martin Bjorklund wrote: > > Hi, > > > > Martin Bjorklund <[email protected]> wrote: > > > Hi, > > > > > > I think we agreed that is ok for a YANG 1.1 module to import a YANG > > > 1.0 module. > > > > > > But should it also be ok for a 1.0 module to import a 1.1 module? > > > > > > If we make this illegal, we might run into problems. For example, > > > ietf-ip imports ietf-interfaces. Suppose we update ietf-interfaces > > > and the new version use YANG 1.1. Is it ok for a server to implement > > > the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces? If the > > > answer is no, it means that we either have to update all modules to > > > 1.1 more or less at the same time (including vendor models!), or we > > > keep existing modules on 1.0 "forever". > > > > I suggest we add this text: > > > > ------------------- > > > > * Coexistence with YANG version 1 > > > > A YANG version 1.1 module MUST NOT include a YANG version 1 submodule, > > and vice versa. > > Vice versa? I assume you mean 'a YANG version 1 module MUST NOT > include a YANG version 1.1 submodule. Perhaps it is clearer to spell > this out explicitly?
Ok. > > > A YANG version 1 module or submodule MUST NOT import a YANG version > > 1.1 module by revision. > > > > A YANG version 1.1 module or submodule MAY import a YANG version > > 1 module by revision. > > > > A YANG version 1.1 module or submodule MAY import a YANG version 1 > > module without revision, and vice versa. This rule exists in order to > > allow implementations of existing YANG version 1 modules together with > > YANG version 1.1 modules. Without this rule, updating a single module > > to YANG version 1.1 would have a cascading effect on modules that > > import it, requiring all of them to also be updated to YANG version > > 1.1, and so on. > > Again, perhaps expand 'vice versa' to be very clear. Ok. > The interesting case here if I understand things correctly is a YANG > version 1 module or submodule importing from a YANG 1.1 module, which > is legal if the import is without a revision. Hm. So in order to avoid > a cascading effect, I have to avoid import by revision and then I am > golden? No you don't have to import by revision, according to the proposed rule. > What about importing by revision the last revision that is > still YANG 1? Sure, this is ok. > I heard that may be troublesome with the YANG library No, this works fine w/ YANG library. > but then perhaps the problem is there? I mean, if I import something > that only exists in a 1.1 version, should I then not really upgrade to > 1.1 as well? Sure. The use case is for example servers that implement ietf-ip (which imports ietf-interfaces), and ietf-interfaces. Suppose we update ietf-interfaces to 1.1. It should still be ok for a server to implement ietf-ip with the new ietf-interfaces. > Would it not work if an import of ietf-interfaces from a > version 1 module simply resolves to the latest ietf-interfaces > revision that is still version 1? But that would mean either that a server is stuck implementing version 1 modules, or that the server must implement both the version 1 and version 1.1 module - and we have already said that this isn't possible. A set of simpler rules would be: A YANG version 1.1 module MUST NOT include a version 1 module. A YANG version 1 module MUST NOT include a version 1.1 module. A YANG version 1.1 (sub)module MAY import a version 1 module. A YANG version 1 (sub)module MAY import a version 1.1 module. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
