Ladislav Lhotka <[email protected]> wrote: > Martin Bjorklund <[email protected]> writes: > > > 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. > > What about my proposal > > https://mailarchive.ietf.org/arch/msg/netmod/_q3YcPR_KobOlFx5HWDA5Oa9oZo > > Its advantage is that it doesn't automatically expose 1.0-only server to > 1.1 stuff if a module that's imported without revision is upgraded to > 1.1.
But a 1.0 only server would only implement 1.0 modules so there wouldn't be any problem there. The problem with "upgraded to 1.1" is that I don't really understand what exactly it means, and what does the server do if there are errors in this process? /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
