On Tue, Sep 15, 2015 at 2:31 AM, Ladislav Lhotka <[email protected]> wrote:
> 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. > > 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. > > > > > > > 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 > >> [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
