Andy Bierman <[email protected]> writes: > 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
I don't think this has to be a strict rule for clients. After all, a client can send any request and it is up to the server to decide whether the request is valid and send a reply or error message. > > > > 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. Does this apply only to the case when the old and new revisions of "foo" are identical except for yang-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. But then an old 1.0-only client is stuck, right? Lada > > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
