Ladislav Lhotka <[email protected]> wrote: > > > On 15 Sep 2015, at 15:54, Martin Bjorklund <[email protected]> wrote: > > > > Juergen Schoenwaelder <[email protected]> wrote: > >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote: > >>> > >>> 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. > >>> > >> > >> Is the confusion is between implements and imports here? The module > >> ietf-ip will _import_ an older version 1 ietf-interfaces while the > >> server _implements_ a newer version 1.1 ietf-interfaces module. Is > >> this not going to work? > >> > >>>> 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. > >> > >> But this seems only true if import === implemented. > >> > >>> 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. > >> > >> It is the last one we are discussing, no? I am trying again: Why is > >> the MAY needed? Why is it not sufficient for a version 1 module to > >> work with an import for (the latest) version 1 module? > > > > How about this: > > > > ------------------- > > > > * Coexistence with YANG version 1 @coexistence@ > > > > A YANG version 1.1 module MUST NOT include a YANG version 1 submodule, > > and a YANG version 1 module MUST NOT include a YANG version 1.1 > > submodule. > > Does this apply only to include-by-revision? Because otherwise how can > we tell?
It is supposed to apply to both; if it is include by revision it is obvious, but for include w/o revision it means that any tool (server, client, ...) MUST treat version mismatch as an error. > > 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. > > > > If a YANG version 1 module A imports module B without revision, and > > module B is updated to YANG version 1.1, a server MAY implement both > > What about imports that are only for groupings/typedefs? They are supposed to be covered. > “Implement” > doesn’t cover this case Do we have a word that covers them as well? >, and such imported modules don’t appear in > hello. Well this is not clear in 6020. They may or may not appear in the hello. (I think most implementations actually do include them in the hello). /martin > > Lada > > > these modules at the same time. In such cases, a NETCONF server MUST > > advertise both modules using the rules defined in ^announce^, and > > SHOULD advertise module A and the latest revision of module B that is > > specified with YANG version 1 according to the rules defined in > > ^RFC6020^. > > > > 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. > > > > ---------------- > > > > Note that this text again talks about NETCONF in the main text... > > > > > > /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
