On Mon, Sep 14, 2015 at 8:02 AM, 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?
>
Here is the guidance put in RFC 6020 for this occasion:
Handling of the "yang-version" statement for versions other than "1"
(the version defined here) is out of scope for this specification.
Any document that defines a higher version will need to define the
backward compatibility of such a higher version.
All current Yuma based tools see the yang-version 1.1; and exit:
ietf-entity.yang:54.16: error(314): wrong version
Error: cannot continue with unknown YANG language version
The solution outlined this morning should mostly work.
A YANG 1.0 client may be able to use only revisions written in YANG 1.0,
even if the server has upgrades some of those modules to YANG 1.1.
Note that a server has total control when it introduces modules
written in YANG 1.1. Not the client.
If module 'foo' is upgraded to a new module revision,
and the new module revision uses YANG 1.1, then
the server will advertise the last YANG 1.0
revision for module 'foo' in the YANG 1.0 <hello>.
The YANG 1.1 library will contain both module revisions,
and the server will set conformance to 'implement' for the 1.1 version.
If the data that existed in the last revision written in YANG 1.0
has changed in the implemented revision written in YANG 1.1,
then the server should not (or must not?) advertise the 'phantom'
YANG 1.0 revision anymore.
Andy
> > > 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?
>
> /js
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
