> On 15 Sep 2015, at 15:22, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Tue, Sep 15, 2015 at 2:31 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > Andy Bierman <a...@yumaworks.com> writes: > > > On Mon, Sep 14, 2015 at 8:02 AM, 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? > >> > > > > > > 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. > > > Not sure what you mean. > A tool that does not claim conformance because it does not recognize the > YANG language does not have any rules to follow. > > We cannot make any rules whatsoever that a YANG 1.0 tool > must follow wrt/ other YANG language versions. That much is rather clear.
I don’t want to enforce classification of clients and then require that a 1.0 client MUST exit when seeing yang-version 1.1. Lada > > > > > > > > > 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? > > > It is up to the server vendor, as Martin said. > > > > > > 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? > > > Yep -- the version written in YANG 1.1 might diverge from the last revision > written in YANG 1.0. Then forklift upgrades are needed. And since YANG is > far > from stable, one might expect to go through churn every year until YANG is > stable. > > > Lada > > > Andy > > > > > > > > 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 > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
