On Thu, Sep 17, 2015 at 3:39 AM, Martin Bjorklund <m...@tail-f.com> wrote:
> Ladislav Lhotka <lho...@nic.cz> wrote:
> >
> > > On 15 Sep 2015, at 15:54, Martin Bjorklund <m...@tail-f.com> wrote:
> > >
> > > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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.
>
This is still a problem:
A YANG version 1 (sub)module MAY import a version 1.1 module.
This assumes the tools understand YANG 1.1.
YANG 1 says it is undefined what happens if the YANG 1 compiler
finds a yang-version value other than '1'.
You want to make a distinction between a YANG 1.1 capable tool
and a YANG 1.0 capable tool. Obviously a YANG 1 capable tool
is not required to EVER accept a YANG 1.1 module.
So when the YANG author imports a YANG 1.1 module from a YANG 1 module
and no revision date is given, there really are no rules that YANG 1.1 can
specify
that would apply to a YANG 1 tool. There is no way to enforce any
interoperability
requirements wrt/ the revision of the imported module that is used in this
case.
>
> > > 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).
>
>
Yes -- and there is no way we are ever changing this code.
The full list of revision dates is needed so the client and server will
produce the same schema set. YANG 1 would be unusable without this info.
>
> /martin
>
>
Andy
>
> >
> > 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
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
