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. Lada > > > > > /martin > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
