On Tue, Sep 15, 2015 at 6:47 AM, Ladislav Lhotka <[email protected]> wrote:
> > > On 15 Sep 2015, at 15:22, Andy Bierman <[email protected]> wrote: > > > > > > > > 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. > > 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. > > The YANG 1.0 spec was already published. For a YANG 1.0 implementation there are no rules for how it must deal with a yang-version value other than '1'. The behavior is out of scope. Anything a YANG 1.0 tool does with 1.1, including exit right away, is compliant. > Lada > > Andy > > > > > > > > > > > > > > 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
