> On 17 Sep 2015, at 12:39, Martin Bjorklund <[email protected]> wrote: > > 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.
Do you mean that it depends on what revisions are actually available to the tool? The formulation looks like it it aimed at module authors. > >>> 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? Probably not, it would be useful to have it. > >> , 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). But that means it is impossible to reuse top-level typedefs/groupings from a module without implementing all its data. And what if different modules import different revisions of the same module? Lada > > > /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 >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
